What is Agile Decision Making?
28 April 2005
by Michael Mah, Senior Consultant, Cutter Consortium
Imagine facing a tight deadline in a competitive market, and having to design and build an ambitious amount of functionality with a set team.
What if it took you or your team weeks to come up with a reliable project estimate? What if, at the same time, an ambitious deadline and an impatient boss were haunting you for a fast answer?
If you’re not agile in your decision making, the de facto tendency as one of my clients has described, is to slip into a cumbersome and heavy “accounting exercise.” All the team leads would make a mad dash for the Excel spreadsheet, where they’d valiantly attempt to tally a series of wild guesses of the effort-hours to design, build, and test the features that marketing or the customer was requesting. Often, the requirements were “fuzzy.”
Most folks say that it typically takes two weeks or more to run through this process; that’s too long. What’s worse, after coming up with the person-hours to do all this work, they’d cram the total into the budgeted hours available within the deadline. When it turns out that double the number of person-hours are needed compared to the half that are available, it’s then perceived to be the manager’s fault that bad news is about to come in one of the following forms: 1) cut function, 2) extend the date, or 3) take on all that’s being asked within the deadline with no changes to the scope.
Without the agility to be able to run something like a “war-game” simulation, I can tell you this: the common tendency for stressed-out managers is to overcommit their teams. Why? Because, if they don’t feel they have adequate reasons to say “no,” they feel compelled to say “yes” in order to demonstrate goodwill. I’ve heard some managers say that they have to act like team players, give their best shot, and show that they have a loyal “can-do” attitude.
All of this sounds reasonable, except for that it doesn’t work. If you overcommit a team with, say, twice the amount they can build in too tight a deadline, it can sabotage even the best of teams, whether they’re super-agile, CMM Level 5, or if they fly top-gun fighter jets in their spare time. As my friend Ed Yourdon, fellow Cutter Senior Consultant and author of the book Death March once said, if you severely underestimate your next project, it doesn’t matter what processes you use, what tools you have, or even what programmers you assign to the job. You are still in deep trouble. Two other ways that this plays out is when you underestimate the complexity of a project or overestimate the productivity you can achieve. It’s a disaster when all three of these things occur at once, as they often do.
And that’s not the worst news. One of the things that I do for a living is collect productivity data on finished projects. Seriously. As part of that research, my colleagues and I discovered a fact that seems totally counterintuitive: teams that shoot for the moon are less productive. That’s right — you heard it here. We might think that a team that’s overreaching is more productive, but data shows that it’s not. In fact, because of the chaos and design/build churn that comes from people working frenetically, we actually find that bugs are dramatically higher — easily at 2x and 4x the industry norms. It takes time to test them out, and when the deadline comes, they either have to ship with higher bugs or cut function. Cutting function late introduces more bugs. Often, the date is slipped as well. This ain’t high productivity in action, folks.
My point is that we need to help our managers become as agile as they possibly can, because in the absence of management agility when it comes to deciding on dates, scope, staff, and deadlines, we have the scenario I described above. There are better ways to do this than the old Excel “accounting exercise.” Techniques exist to classify desired features into “complexity bins.” Many managers often are able to map the desired features into software sizing estimates, decomposing the features into requirements, technical design elements, modules, C++ objects, methods, or Java classes, to name a few.
Based on a team’s productivity, you can then more reliably estimate schedule and effort, and if the estimates are not in alignment with the constraints posed by the deadline, then meaningful negotiations on project scope can now take place since the features have been mapped to the required software work. Many agile management teams do this in minutes or hours with a computer, and escape the drudgery of taking weeks using effort-based spreadsheets.
This is not to denigrate ambitious attempts by managers who love Excel — it’s just that spreadsheets are linear tools in a nonlinear world. For example, with a spreadsheet, it’s possible to cut the schedule in half by doubling the people. We all know this doesn’t happen in the real world. Data shows that, at best, doubling staff might cut the time by 20%, but defects often climb by a factor of 4x to 6x because of team communication complexity. Testing is hell when you throw a crowd at an IT project.
So, to summarize. It often isn’t enough just to have agile programmers and testers. Managers can and must be agile too. On the other hand, poor decisions without management agility can have disastrous consequences. When this happens, we risk the travesty of driving even an agile team off a cliff because of bad steering decisions. I submit that if managers are agile, along with agile developers, then the resultant productivity is nearly impossible to beat.
— Michael Mah, Senior Consultant, Cutter Consortium
© 2005 Cutter Consortium. All rights reserved. Comments/suggestions to webmaster@cutter.com.
