Project money has to come from somewhere, and most likely the person who owns the budget knows very little about XP or agile methods. If that person is familiar with these programming concepts, I suspect he thinks the idea is nuts or just too risky. Asking for money from a skeptical source can be risky business. One of the best ways for a manager to do so credibly is to make sure he's speaking the sponsor's language.
Last time I talked a bit about software development projects focusing on business value to drive your projects. Devoting time and money to making software simply because somebody told you to isn't a good business reason (although it may be a good way to keep your job). In the end, if the software your team makes doesn't provide value to the business, it's not worth whatever your project sponsor paid for it -- a fact he'll eventually discover.
"Value" can mean a couple different things. Either we're talking about dollars, as in an improved bottom line, or we're talking about operational improvements that lead to dollars. As we've discussed before, when you propose a project, you should encourage your team members to try their best to attach a dollar value to each feature (or more likely each set of features) they're creating. This is the business case for the software. You should try to answer two questions for each feature:
- What need for value will this feature address (that is, which of your customer's costs will it reduce or which revenues will it increase)?
- By how much will it do that?
Of course, it's not always possible to answer these two questions, but don't assume you can't until you try. Somebody's paying for this software, and that person should know what he's getting for his money. Having this information will make it easier to get the money you need to start your XP projects.
People who pay for software development projects need answers to three questions before they'll commit their dollars:
- What new or better business capability will I get from the project?
- When?
- For how much?
Managers can't always answer these questions in detail, but I'm not sure the project sponsors want them answered specifically either. Still, managers do have to answer them in a way that balances their inability to predict the future with the requirement to predict just enough of it to get their budget. People who put a lot of money at risk aren't likely to allocate it to off-the-cuff soirees into the unknown.
Perhaps more important is that people in the organization, including managers and programmers on software development teams, need goals. There must be stakes in the ground telling everybody, "This is where we're headed. We might change direction along the way, but this is the ultimate goal as far as we know it right now."
When people who hold the purse strings tell people asking for money to answer those three questions very specifically, they're asking for almost useless information. This becomes obvious whenever managers try to do "bottom-up" estimates. They try to identify all the tasks and estimate the effort for each. You can imagine them building up the Gantt chart as they go, filling in more and more detail. The total time for the project, then, is the sum of all the tasks. The result is often an unintentional fib, which is why a very large number of software projects deliver late.
The problem is the level of detail. Very rarely can I tell someone months in advance how long a software development project will take, if I have to be accurate to the day. This is because my detailed, bottom-up estimates are probably wrong. A small estimating mistake early on can wreak havoc with our plans later. And what plan do you know about that doesn't make small estimating mistakes -- or big ones for that matter? Estimates are predictions, not promises. Imagine estimating a project for building an online store. Your (simplified) functional requirements might be:
- Allow a user to browse and buy books
- Allow a user to browse and buy music
- Allow a user to browse and buy electronics
Like most people trying to estimate things, you'll probably start with some core requirement and extrapolate from there to the rest. You might assume writing the code for browsing and buying books will take 5 units of effort (hours, days, weeks, people, whatever), and then 3 units for the other two requirements because they're both simplified by having already written code to support books. As a result, you end up with a simplified plan that looks like this:
| Task | Units |
| Browse/buy books | 5 |
| Browse/buy music | 3 |
| Browse/buy electronics | 3 |
A typical manager might say, "All right, 11 units and we're finished." But what happens if the "Browse/buy books" story takes six units instead of five? If we underestimated that story by 20 percent, we probably underestimated the others by a similar amount. The error ripples through, and the whole estimate collapses.
The more detailed our plans get, the more brittle they become. Anybody can predict anything. Whether the prediction has a small enough error margin to be useful is another matter entirely. Detailed long-term predictions usually don't. When upper-level management asks how much time you need for a project, the simple answer is you can't tell the exact number of days or weeks. If you try, there is a good chance you'll be wrong, so the information probably wouldn't be helpful anyway.
Just because you can't make accurate, detailed, long-term predictions, though, doesn't give you a free pass not to answer the three questions. You still have to answer them, but you have to answer them differently. You need to provide just enough information for project sponsors to make a reasonably informed decision.
When asked to predict the stock market, J. P. Morgan reportedly said, "It will fluctuate." Not quite what his questioner was looking for, perhaps, but honest. That's about as good as we can do with software development. There are only two specifics we can predict reliably when we start a project:
- The system we end up with has to meet a business need somebody with money is willing to pay for.
- Time, money, and patience will run out.
Time, money, and patience all slip away. The question is, how can your team produce great software that adds value before those things run out? It's better to have some working software that helps us make progress by the time those things disappear, than to have nothing and regret the experience. Sticking to the XP practices can help your teams do that. But as a manager, your inability to predict very well, or to control much, puts you in a bind. The most forthright answer to the potential project sponsor's questions goes something like this:
We're going to grow some software. We don't know how much it will cost, how long it will take, or what it will ultimately look like. But when we get there, we'll release it. We know we should try to get to that point as fast as we can, so that's what we'll do.
That's honest, but it won't fly in the real world. People with money need more information than that (especially in the post-dot-com world). The good news is that potential sponsors need just enough information to make an intelligent decision based on incomplete knowledge of the future. You can answer the three questions without trying to predict too much. The trick is to focus on goals rather than detailed plans about how to get there. Resist the urge to drill down to silly levels of detail to come up with estimates of how long something will take and how much it will cost. Those estimates are right so infrequently that they're not worth the trouble.
Instead, it's wiser to get the folks together who will be (or might be) working on the proposed project. Discuss the feature requirements for the first release. What is the bare minimum set of features the software absolutely has to have to ship the first time? Write those down somewhere. Now have the technical people on the team estimate how many iterations worth of development effort each feature will take, based on having a certain number of people on the team. High-level estimates are fine at this stage. Just have experienced people talk with each other about the effort each feature would take and write it down.
Experience is important here, because it minimizes the amount of guessing the team has to do. Every estimate is at least partially a guess, and experience or higher IQ won't eliminate all the guesswork. Experience can help reduce guesswork to a certain point, but our inability to predict the future accurately must be factored in.
Here's a slightly doctored example from the project I'm currently working on:
| Story | Estimated iterations | Assigned release |
| Preprovisioning | 2 | 1 |
| Physical management | 2 | 1 |
| Logical management | 2 | 1 |
| User administration | 1 | 1 |
| State maintenance | 2 | 1 |
| Deployment | 3 | 1 |
| External tool integration | 1 | 1 |
| Auditing | 1 | 1 |
| Monitoring | 1 | 2 |
| Total iterations | 15 | Â |
This estimate assumed a team of four developers. That level of detail was enough for us to estimate the work required to implement all of the high-level features listed. From there, we attached a dollar amount to each iteration of work, and multiplied it by the total number of iterations (15). This exercise took less than two weeks of thinking and exploring various technical things. The end result was acceptable answers to all three questions our potential customer needed us to address:
- What new or improved business capability will I get from the project? The major features you see here, give or take, based on what the team learns along the way.
- How long will it take? Roughly 15 one-week iterations, or a little less than four months.
- How much will it cost? Multiply the cost per iteration by 15.
We were also able to take this a step further. Our customer hired my company to make a software product. A brief discussion with the head of marketing told the team how many licenses he expected to sell in the first four years, and at what price. That let us do a rough calculation of when our customer would break even on its investment in our services.
We answered all three questions without going into excruciating -- and probably incorrect -- detail. We didn't have a Gantt chart, because we didn't need one. We had all the information we needed within a little more than a week.
I think the plan in the previous section is all a manager (and a team) needs to grow software, but that might be too radical for some project sponsors. A manager might be able to answer the three sponsor questions and get rewarded with a project, but sometimes that won't close the deal. A manager might need at least an initial plan that looks a little more familiar. Figure 1 shows the only Gantt chart that makes much sense.
Figure 1. Gantt chart
The rollup, shown in Figure 2, is even simpler.
Figure 2. Gantt chart rollup
Our plans need to skip to the rollup. One bold bar, two dates.
Most managers don't make Gantt charts like this. Some believe the more detailed variety are better, or more accurate, or some other positive description. I give managers a great deal of credit, though. I think most produce outrageously detailed Gantt charts because they're constrained, not because they're stupid or malicious (although some are). Somebody above them expects those detailed charts, and projects don't continue to get funded without them. This is because some people think such detailed plans are worth something.
The fact is, however, all plans are myths. They are all wrong as soon as they hit the paper. We need to start behaving that way. I think most managers are a bit suspicious of their own highly detailed plans. A friend of mine started an email to me like this:
Since I just finished a spreadsheet for my project that shows a build estimate based on A&D estimates of proposed scope for the next release (accurate to within 30 seconds based on a 6-month implementation and 60+ FTEs), I figured I'd shoot you another e-mail.
Managers wouldn't bet a month's salary on the accuracy of a highly detailed plan. Plans should be blurrier than that -- lots of statements of intent, few statements of expectations. In The Innovator's Dilemma (see Resources), Clayton Christensen says that plans should be for learning and not implementation when we're exploring ambiguous technologies and markets. That's the only way to act purposefully when working in the unknown. The same is true when we're exploring ambiguous software requirements to meet ambiguous business needs: the business needs change as we move toward them and our understanding of them increases. Being able to make plans that respect these facts assumes a big change in how management at all levels thinks about failure.
Jim Highsmith, author of Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (see Resources), says our thinking about quality is broken. We simply don't allow for being wrong, for failure, or for experimentation:
The current state of software quality management practices often is governed by the phrase, Do it right the first time. But in a complex environment, Do it right the first time is a recipe for failure. In essence, it says,
We can't be uncertain
We can't experiment
We can't learn from mistakes (because we shouldn't make any)
We can't deviate from the plan
What we need is to be willing to do it wrong the first time in order to get it right the last time.
We need to fail fast and learn from it. Plans should support that. Remember that we don't know exactly where we're going. Taking small steps and preserving simplicity, then being wrong and learning from it is the best way to explore the unknown. Make failure frequent, fast, and cheap. In his book Leading the Revolution (see Resources), Gary Hamel says that requiring everybody to be right all the time drives out imagination. This is what our plans do unless planning is more important than the plan.
XP requires managers to start projects differently, because traditional ways of thinking about and planning software projects tend not to produce the results most managers want. Once you get the money, and the project starts, things need to stay different. That's what the XP practices represent -- a different way to run projects that gives your teams a better chance of delivering software real people end up wanting when the project is over.
As I did last month, I'm going to leave next month's topic up to the readers of this column. What do you want me to write about? What's the biggest question you have about XP? What do you think is completely silly, or unwise, or unprofessional, or impossible? What's the most confusing practice? Please participate in the forum for this column. Tell me what you want me to write about. I'll survey the requests I get. If there is critical mass for something in particular, I'll write about it. If not, I'll pick something I think makes sense to write about.
- Participate in the discussion forum.
- Read The Innovator's Dilemma by Clayton M. Christensen (Harvard Business School Press, 1997) to understand why traditional business planning doesn't work for innovative products in unexplored markets.
- For more information about Jim Highsmith's thinking about agile methods in general, and his own Adaptive Software Development in particular, check out his Jolt Award-winning Adaptive Software Development: A Collaborative Approach to Managing Complex Systems (Dorset House, 2000).
- To understand why most industries need a few heretics who are willing and able to be wrong on the way to being right, read Leading the Revolution: How to Thrive in Turbulent Times by Making Innovation a Way of Life by Gary Hamel (Harvard Business School Press, 2000).
- Are you joining this column late in the game? See where it all started, with the first XP article Roy Miller co-wrote with Chris Collins, "XP distilled" (developerWorks, March 2001), and then be sure to check out the archives for this column.
- You'll find hundreds of articles about every aspect of Java programming in the developerWorks Java technology zone.
Roy W. Miller has been a software developer and technology consultant for almost ten years, first with Andersen Consulting (now Accenture) and currently with RoleModel Software, Inc. in North Carolina. He has used heavyweight methods and agile ones, including XP. He co-authored a book in the Addison-Wesley XP Series (Extreme Programming Applied: Playing to Win) and is currently writing a book about complexity, emergence, and software development (the working title is Growing Software: Exploding the Myth of Prediction and Control). Contact Roy at rmiller@rolemodelsoft.com. or roy@roywmiller.com.. You can also visit his personal Web site at www.roywmiller.com.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
