For me Agile is a sort of branded common sense, the programming equivalent of bottled mineral water. I did a scrum course, and the summary is basically "do small bits of work at a time, get feedback on whether it's the right thing". Perhaps also "keep track of the tasks and think about which ones matter", and "communicate and be accountable". All of which are the kind of advice that people get in school, yet don't follow, so maybe it's not entirely crazy to rehash.
But that doesn't sell any courses, and isn't nearly enough to fill out a paperback sized book. So we end up with a bunch of stories about waterfall projects that went wrong somewhere in the FBI or Obamacare, which is not to say they're bad examples, just that perhaps the real question is how a project that tries to break itself down into manageable chunks fails to do so.
We also get planning poker type things, or prescriptions about how often the team needs a standup, or the need for a PO and a SM, and various too-specific things that aren't going to fit every team.
Interesting analogy. Bottled mineral water companies have sold you the fear of drinking tap water, with a product which is orders of magnitude more expensive than tap water, and nearly always with in one-use plastic bottles to boot. (Though I reuse them to hold tap water.)
Agile companies sell the fear that You're Doing It Wrong.
What resonated most with me from the satirical piece was:
> If you ever see a software product with a copyright date before, say, 2001, it is a work of fiction, placed by The Great Cunningham to test our faith.
I've read accounts of the 1980s-ish days at MS, Apple, VisiCalc, and other software companies.
So far I have yet to read one which used waterfall.
Modern Agile proponents seem to define Agile as "not-waterfall", so I guess Wozniac's Integer BASIC in the 1970s was developed using Agile methods. /s
While true, I also know there's the Dark Matter of software development - most of the internal software development at large (non-software) companies never sees the light of day.
(XP's famous use in the failed Chrysler Comprehensive Compensation System is one exception. The Edsel also had some innovative features.)
Anyway, that's all to say there's a 25 year period (including popular interpretations of DOD-STD-2167A) where risk-averse managers with no software development management experience might have heard about waterfall and said "gimme some of that."
My working assumption is that that's the target audience of the expensive Agile consultants. 'Cause at least that makes some sense.
> In the early 1990s, Ken Schwaber used what would become scrum at his company, Advanced Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna developed a similar approach at Easel Corporation, referring to it using the single word Scrum.[16]
> Sutherland and Schwaber worked together to integrate their ideas into a single framework, scrum. They tested scrum and continually improved it, leading to their 1995 paper,[17] contributions to the Manifesto for Agile Software Development in 2001,[18] and the worldwide spread and use of scrum since 2002.
(I verified that with a Google Book snippet for that 1995 publication, which says: "More recently, a refined approach to the SCRUM process has been applied by Sutherland to Smalltalk development and Schwaber to Delphi development. The SCRUM approach is used at leading edge software companies with significant success.)
You can see both Sutherland and Schwaber are signatories to the Manifesto.
I think it's unlikely they would be signatories if the Manifesto was not aligned with principles of scrum.
The Scrum way of doing Agile is mostly fine, especially as the people who created Scrum define it. The problems with Scrum that I have seen are mostly the result of expedient training. Scrum is a victim of its own success in that way.
Scrum jargon combined with a recipe-based application of Scrum makes things worse. Some Scrum jargon is counterproductive on the face of it. "Sprints" imply working faster. "Product owner" is often a debased form of product management. There is a normal English word for everything in Scrum.
There is a very concrete advantage over conventional pre-Agile project management as applied to software development projects: If you do a critical path analysis, you need to at least guess at who will do which task in order to do "resource leveling" to make sure people are not over-scheduled. This is tedious, even if you have software that partly automates resource leveling. Then, a few weeks later, the project has encountered some previously unknown issues and you have to do it all again, or, worse, you stop updating the schedule.
Iterative planning and on-demand task assignment foregos the precise estimation of pre-Agile approaches, but those estimates were wrong anyway because software implementation tasks are too often unique and hard to predict.
Agile "boot camp" courses do not teach this, and the consequences of this and related differences from previous approaches. The downside there is that Agile practitioners can't defend Agile from skeptics, and they try to take Agile where it should not go.
"Planning poker" and "Agile metrics," which sounds to me like "diet snacks," are the result of not knowing why pre-Agile project management sucked for software. The SAFe elaboration of Agile is the sum of all these horrors. There is enough to warn people about to fill at least a slim trade paperback.
11 comments
[ 3.0 ms ] story [ 37.6 ms ] threadBut that doesn't sell any courses, and isn't nearly enough to fill out a paperback sized book. So we end up with a bunch of stories about waterfall projects that went wrong somewhere in the FBI or Obamacare, which is not to say they're bad examples, just that perhaps the real question is how a project that tries to break itself down into manageable chunks fails to do so.
We also get planning poker type things, or prescriptions about how often the team needs a standup, or the need for a PO and a SM, and various too-specific things that aren't going to fit every team.
Agile companies sell the fear that You're Doing It Wrong.
What resonated most with me from the satirical piece was:
> If you ever see a software product with a copyright date before, say, 2001, it is a work of fiction, placed by The Great Cunningham to test our faith.
I've read accounts of the 1980s-ish days at MS, Apple, VisiCalc, and other software companies.
So far I have yet to read one which used waterfall.
Modern Agile proponents seem to define Agile as "not-waterfall", so I guess Wozniac's Integer BASIC in the 1970s was developed using Agile methods. /s
> I've read accounts of the 1980s-ish days at MS, Apple, VisiCalc, and other software companies. > So far I have yet to read one which used waterfall.
Indeed, even the Royce paper everyone cites to describe waterfall doesn't even use waterfall.
(XP's famous use in the failed Chrysler Comprehensive Compensation System is one exception. The Edsel also had some innovative features.)
Anyway, that's all to say there's a 25 year period (including popular interpretations of DOD-STD-2167A) where risk-averse managers with no software development management experience might have heard about waterfall and said "gimme some of that."
My working assumption is that that's the target audience of the expensive Agile consultants. 'Cause at least that makes some sense.
> In the early 1990s, Ken Schwaber used what would become scrum at his company, Advanced Development Methods; while Jeff Sutherland, John Scumniotales and Jeff McKenna developed a similar approach at Easel Corporation, referring to it using the single word Scrum.[16]
> Sutherland and Schwaber worked together to integrate their ideas into a single framework, scrum. They tested scrum and continually improved it, leading to their 1995 paper,[17] contributions to the Manifesto for Agile Software Development in 2001,[18] and the worldwide spread and use of scrum since 2002.
(I verified that with a Google Book snippet for that 1995 publication, which says: "More recently, a refined approach to the SCRUM process has been applied by Sutherland to Smalltalk development and Schwaber to Delphi development. The SCRUM approach is used at leading edge software companies with significant success.)
You can see both Sutherland and Schwaber are signatories to the Manifesto.
I think it's unlikely they would be signatories if the Manifesto was not aligned with principles of scrum.
Scrum jargon combined with a recipe-based application of Scrum makes things worse. Some Scrum jargon is counterproductive on the face of it. "Sprints" imply working faster. "Product owner" is often a debased form of product management. There is a normal English word for everything in Scrum.
Iterative planning and on-demand task assignment foregos the precise estimation of pre-Agile approaches, but those estimates were wrong anyway because software implementation tasks are too often unique and hard to predict.
Agile "boot camp" courses do not teach this, and the consequences of this and related differences from previous approaches. The downside there is that Agile practitioners can't defend Agile from skeptics, and they try to take Agile where it should not go.
"Planning poker" and "Agile metrics," which sounds to me like "diet snacks," are the result of not knowing why pre-Agile project management sucked for software. The SAFe elaboration of Agile is the sum of all these horrors. There is enough to warn people about to fill at least a slim trade paperback.