Agile/software engineering practices broadly suffer a lot from the fact that not only is selling software a business model, selling Agile is also a business model, and when you buy Agile consulting it's impossible to disentangle whether it's being sold to you because it works or because it makes that person money. They don't even know because it's their job and they convinced themselves of its usefulness.
It can still be evaluated on the merits but IMO this greatly pollutes the speed at which software devs as a broadly conceived community can come to consensus understanding of this.
Also I think the comparison to lean manufacturing has always been very shallow. I get the metaphor, I just don't think that human resources in engineering can be optimized like manufacturing processes. This quote is the best part of the article:
> "You’d never hear anyone say, 'We help mechanical engineers be agile. That would be silly. And I mean that in the worst possible sense of the word".
As for the rest of it, I'm not dying to hear what the person who invented Agile thinks we should do next lol.
Absolutely. And, having done some agile consulting long ago, I'd say it's more pernicious than that.
The people who truly want to make deep change in pursuit of deep improvement are a small segment of the market. Worse, they don't need a lot of help. In the aughts, I had a few clients who really got it after 3 months of focused work, and then they were off and running.
But a large company that only wants to talk about change and maybe make some 5% improvements if they aren't too hard? That can be milked forever. Well, I can't, because I care about results. But consultants who either don't care or don't notice? They're golden.
I've seen several director types get promotions promising to get faster and more reliable work out of existing engineers by implementing this new religion... Agile.
The results were always predictable. Layering more meetings and stress on people who already have too much work to do, doesn't help things. But, you're still vice president.
> I'm not dying to hear what the person who invented Agile thinks we should do next
Agile has plenty of good ideas.
The problem is the almost religious following and, as you mention, the whole industry that has sprung up around it.
Even the initiators said that it was supposed to be a rough framework, to be adapted to your individual circumstances and teams. It was also a (much needed) counterpoint to the then prevalent waterfall model.
Now we have consultants, people strictly following something they read in a book or learned in a course, adhering to strict structure of meetings/processes, and even a big association with a single software product, Jira. ("You are doing it wrong!")
When you step back, a lot of the ideas make sense, and many teams will even implement similar workflows without having ever heard about "Agile".
> ... it was supposed to be a rough framework, to be adapted to your individual circumstances and teams.
> Now we have consultants, people strictly following something they read in a book or learned in a course, adhering to strict structure of meetings/processes, and even a big association with a single software product, Jira. ("You are doing it wrong!")
Yeah. Part of agile is that your process is an adjustible parameter. If you're doing it with a rigid process - any rigid process - then you are not actually doing agile.
When you have a large program team with mixed experience levels who don't fully understand fundamental principles, sometimes the only way to keep your sanity is to force everyone to strictly follow a defined agile methodology (LeSS or SAFe or whatever). That isn't optimal, but if you have to deliver working software right now you can't wait around to figure out an optimal process for your unique circumstances. Pick something good enough and move forward, then improve as you go
Agile doesn't ask you to figure out the "optimal process", it asks you to learn. One of the key things I've seen missed in almost every attempt at Agile/DevOps/whatever is the retrospective or the learning component.
The team/organization has to become a learning organization. That means a number of things, but the critical one here is learning from past failures and successes and incorporating that feedback into their model (ideally continuously, but in Scrums it'd be the end-of-sprint retrospective). You start down a path, and you find it's difficult. You don't press on just because it's the one you selected, that's the way of idiots. You examine the hardships you're facing, and you address them.
Absolutely. To my mind, the one vital agile practice is the weekly retrospective where the team looks at how things went, thinks a bit, and decides to try something in following weeks. Everything else is just tools people can try applying to solve the problem of the week.
I remember someone giving a lecture on software engineering methodologies who gave a pretty good summary by saying that "The methods are there to help your brain, not to replace your brain."
Haha, this was hilarious to read, mainly because, on some occasions, I've been a cowboy, at least in the context of this post. I like to think it worked pretty well, since, for what we were trying to do, the processes were fighting against us, so I just... did what I considered right technically, regardless of tickets and sprints and who's team should do what.
Whether it was right, I'm not sure, but people have been happy with my work, so that allowed me a bit of leeway.
There really is no methodology called "Agile". There are things like Scrum, SAFE, AUP, XP, etc. Some of those may or may not mandate things like "sprints", but the essence of agile (the Agile Manifesto) doesn't even mention the term "sprint".
The closest it gets to that is where it say:
We follow these principles:
<snip>
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
> > "You’d never hear anyone say, 'We help mechanical engineers be agile. That would be silly. And I mean that in the worst possible sense of the word".
This quote is silly.
To me, agile is just good engineering practice, applied to software. Of course mechanical engineers apply its principles, and have for decades before the term Agile was coined.
And as such, this practice is far older than software.
The Apollo space programme is my favourite example: the ultimate goal remained fixed (man/moon/before end of decade), but all steps of the way were discovered and redefined over the programme's course.
Mission objectives were changed depending on what was learned, often even in flight.
This was a very nice and agile (and sensible) approach, regardless of what it was called.
You're just offering your own special definition of "agile", that of course doesn't fit anyone else's definition, and especially any agile consultant's.
Of course, even more ironically, it doesn't fit the original agile manifesto:
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
> You're just offering your own special definition of "agile",
I'm not so sure.
What's the official definition? Don't give me the manifesto, that's just an implementation of common sense in development, as applied to software.
As a trained mechanical engineer (maybe that's why the quote about mechanical engineers irked me especially), the agile manifesto just reads like good engineering practice to me.
And indeed the signatories of the manifesto expected to start a huge discussion on what agility meant for any particular team or product, and how to best live up to its principles.
> of course [it doesn't fit]
That was uncalled for.
> and especially any agile consultant's.
I'm (something akin to) an agile consultant though :-)
Also, just to point out: maybe my definition of Agile diverges from canon. That's OK. I don't care to follow the canon, I care to do right by those who I've been asked to support.
> Of course, even more ironically, it doesn't fit the original agile manifesto:
> > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
I'm not sure how you came to that conclusion.
How is "welcome changing requirements" a bad fit for "changed the mission objectives (as new information emerged)". Clearly the [competitive advantage/likelihood of success] was increased? In fact the entire programme was shaped such that change was explicit part of the plan.
I've stared at this quote for a while now, and I still can't see the contradiction.
Which bothers me much, much less than selling things like CMMI/PSP certifications or EUP/RUP which are done purely for paper pushing and selling the paper value.
Agile is an improvement on waterfall and you don't need to be certified to do it.
> Also I think the comparison to lean manufacturing has always been very shallow. I get the metaphor, I just don't think that human resources in engineering can be optimized like manufacturing processes.
Agile and Lean are empirical process controls, they are based on the same concepts. Ken Schwaber explains all this on the first chapter of his book "Agile Software Development with SCRUM":
Defined process control: same inputs always result in same output (manufacturing widgets on a production line).
Empirical process control: same inputs not always result in same output.
Schwaber conceived SCRUM (and was among the founders of Agile) after realizing software development required an empirical process control: give 2 dev teams same specs, 2 different apps will come out (they might do the same thing, but in different ways)
It can still be evaluated on the merits but IMO this greatly pollutes the speed at which software devs as a broadly conceived community can come to consensus understanding of this.
Also I think the comparison to lean manufacturing has always been very shallow. I get the metaphor, I just don't think that human resources in engineering can be optimized like manufacturing processes. This quote is the best part of the article:
> "You’d never hear anyone say, 'We help mechanical engineers be agile. That would be silly. And I mean that in the worst possible sense of the word".
As for the rest of it, I'm not dying to hear what the person who invented Agile thinks we should do next lol.