First there was “frequent informal conversations between business people and programmers about what the computer could do.” The result: Useful systems that worked, onto which programmers and their business counterparts added enhancements that gradually accumulated into large systems that worked.
Then came formal methodologies — structured, sequential steps that completely specified a system’s design, functionality, and user interface before programmers wrote the first line of code … in a word, waterfall. It was more elegant, which caused most experts to ignore its 70%+ failure rate for a decade or two.
In 2001, via the Agile Manifesto, we rediscovered the value of frequent informal conversations, only now, in self-defense, we call it a methodology: Agile. It’s actually a family of methodologies, but let’s not quibble. Also not to quibble: Yours truly described much the same thing in this space two years before that, for all the thanks I get.
But never mind all that. Patting myself on the back makes my shoulder hurt, and oversimplifying Agile this much does it a disservice.
There are those who think they’re practicing Agile when all they’re doing is flailing away at a problem. They’re fooling themselves, trying to fool everyone else, or both. Agile requires just as much discipline as waterfall, just a different sort of discipline.
Waterfall projects start with a complete specification, with “complete” defined as “what we’re going to build no matter what the business actually needs.”
Then someone has a good idea and such bad manners that they share it, suggesting the team add the idea to the specification. In retaliation, all good project managers excoriate these miscreants, calling them, to their faces, creeps.
Scope creeps.
Well-run waterfall projects have a way to deal with scope creeps — the change-control committee. It’s a gauntlet all good ideas that happen at the wrong time must run. The committee reviews proposed scope changes to determine which ones provide enough value to warrant a change in the project plan.
Let’s be honest. It’s control-oriented bureaucracy. Control is necessary because after all, we can’t trust the creeps who want to change our scope to have the good judgment God gave rice.
Agile teams, in contrast, expect a steady flow of good ideas. Agile also recognizes that project teams … more accurately, release teams … have a fixed bandwidth, unless, of course, the business changes the team size.
Rather than pretend good ideas are really bad ideas, the business people who actually use the system add the good ideas to the good-idea queue (called the “backlog”). The team estimates how much effort will be required to code each good idea, and the business people decide which good ideas the team should work on, and in what order.
It’s called Agile because it really is agile, in the sense that when new ideas arise and new business situations change priorities, project (sorry, release) teams can change their priorities just as fast.
And it’s just as disciplined as having a change committee review proposed scope changes, assuming, that is, that the release team can be trusted to make reasonably accurate estimates and that the “system owners” … the business people who use the system to help get work done … are appropriate judges of what’s more important than what.
In case the point isn’t clear: They’d better be and if they aren’t it’s time to replace them, and to fix the hiring process so such irresponsible people aren’t put in positions of responsibility any more.
To be fair, in businesses that have devolved into rival organizational siloes (most of them), Agile priority setting will only be accurate for within-silo decisions, because for the most part release teams and the software they support will be focused inside one organizational silo.
Also, like it or not, siloes are more often a constraint than a problem, which is to say siloes are something to deal with — they aren’t something that ever gets fixed.
Fortunately, there’s a simple way for the company’s top leadership to set priorities across siloes, and that’s to adjust the size of the release teams to reflect the company’s overall business priorities.
Of course, this takes discipline too, in the form of an executive leadership team that provides executive leadership — that thinks in terms of the enterprise’s overall priorities and not just how to jockey for position so their silo gets its fair share or more.
If your company has an ELT like this it can achieve organizational agility.
If it doesn’t, the best you can hope for is that the executive who sits at the top of the silo you live in is adept at jockeying for position.
* * *
Sixteen years ago in KJR I revealed a leadership secret I’d used for years – never carry a pager.
Speaking of leaders, in 2003, KJR divided the leadership world into Steven Spielberg and Roger Ebert. Here’s why you need to be Steven Spielberg.
And in 2007, an object lesson in why organizational listening is among the most important leadership skills.
You speak/write as though there were only 2 methods of software design: waterfall and agile. I don’t like either. I prefer top down structured design and stepwise enhancement implementation. To make sure that my designers met users needs, I had them write the user’s manual first. Then I had them prototype the entire project using the most convenient tools. When the users liked what they could see in the prototype, only then would we commit to building the real stuff. It always worked. I just don’t have a name for it.