Project Management – Page 27 – IS Survivor Publishing

Why Agile is agile

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.

Happy birthday, Opportunity

Here’s something to celebrate: Saturday, NASA’s Opportunity rover celebrated the tenth anniversary of it’s landing on Mars and it’s still going strong, even though its planned mission life was only three months.

This isn’t a fluke. Cassini, an international collaboration managed by NASA that originated in 1982, launched in 1997, entered orbit around Saturn in 2004, and completed its planned mission in 2008. It’s still going strong.

Then there are the two Voyager probes, the Curiosity rover, the Chandra orbiting X-ray observatory … what’s interesting about NASA projects is that these sorts of spectacular successes have become ordinary.

Unlike, say, the Department of Health and Human Services (HHS), whose most noteworthy large-scale projects in the same span of years — those would be Medicare Plan D and Healthcare.gov — were, shall we say, challenged.

As pointed out in this space when Healthcare.gov’s problems became newsworthy, using Healthcare.gov, and for that matter challenged state exchanges like Minnesota’s MNSure, as evidence that “government can’t do anything right,” is just plain ridiculous. If that was the case, NASA’s string of successes would have been a string of failures, NASA being a part of the federal government and all.

Were we to conclude that the Department of Health and Human Services should never be entrusted with a large-scale project, we’d at least have a sample size of two on our side. But even then, other than the joy we all experience when we’re able to point our fingers at someone else to say, “Aren’t they just awful?” there’s nothing interesting about a conclusion like this.

It gets interesting when we ask what the difference is between NASA and HHS. There are two. The first is that, following two embarrassing missions to Mars that failed, NASA decided to find out what it was doing wrong, and to fix it. It commissioned an in-depth investigation and took the results seriously.

Following Medicare Plan D and Healthcare.gov, the investigation, if that’s the proper term, came from a Congressional committee. Even if we eschew (gesundheit!) the easy, snide comment, there’s still an obvious contrast to be drawn: NASA’s investigation was led by experts in managing large programs. Congressional investigations are run by elected representatives, whose nearest equivalent of a large program is a re-election campaign.

So that’s the first difference. The second, and more important one, is that NASA is in the big projects business. Big projects … missions … are what NASA does for a living.

HHS is, in contrast, in the operations business, and it’s actually quite good at it. For example, Medicare’s administrative overhead is either one or six percent of total expenditures, depending on whether the metric includes the administrative overhead of the private contractors the Medicare program uses. For comparison, the Affordable Care Act establishes a ceiling of 18% for health insurers, a restriction that created quite a stir in the industry.

The point being that HHS isn’t in the large projects business, so it shouldn’t be all that surprising that it isn’t very good at them.

We can go deeper than that. The leadership, management, and cultural traits that make an organization good at operations are in many respects antithetical to those that make an organization good at project management.

Operations is about keeping things the same. Think of a factory and you get the picture: the job is to do the same thing over and over again, in very much the same way, so as to minimize variation and incremental cost while maximizing throughput.

Operations planning is all about matching capacity and staffing to anticipated demand. It’s a day-to-day thing.

Projects are about making things different. Project planning is all about figuring out what the tasks are to change things or build something new, how they have to be sequenced, who is best equipped to take each one on, and how long they should be expected to take.

Operations tasks, that is, are known because they’re repeated over and over again. Each project task is, in contrast, in some respect unique. They’d better be, because each one would have already been done by someone else. The project should use that result instead of creating an identical copy.

Operations never finishes. No matter what gets done today, we’ll do more of it tomorrow. Projects, by definition, are supposed to end.

I am oversimplifying. NASA is also in the operations business. Otherwise there wouldn’t be anyone around to receive all the data its successful missions keep sending back to Earth.

Interestingly enough, it doesn’t describe things that way. Its operations are considered part of the mission, and while missions may be extended, they’re never considered eternal.

There’s always an end date.