This topic is leading somewhere. It may take a few posts to fully get there.
First, let me say that in my personal opinion (and Peter Drucker's and many others'), business is not mainly about money. Money is a measure, but it is not why we run the race. Business is about delivery satisfaction to your customers. You do that, then you meet the very real constraints of making money (for employees, for shareholders, for suppliers, etc).
Nonetheless...money is a very clear indicator. And some people get very fuzzy when they start to describe "why are we doing this project". So I am, with some hesitancy, going to suggest that we ask 'em: "Ok, we are spending very real money to develop this new product. I need to know how important it is." Perhaps "I" is one of the developers, who gets much more motivated when the project is important.
So, let's take a simple case (so the math is easy for me). These details:
Project length: 1 year
Project Team people costs (all in): $800,000
Other project costs: $200,000
Total project costs: $1,000,000
So, we are investing $1 million. What do we get back?
I will suggest that the first release of any project should always bring a high multiple over the costs. In fact, one way of picking projects is only to do those that bring the highest multiple over their costs.
When I was in MBA school, we learned about the CAPM (Capital Asset Pricing Model). I don't think it has changed much, at least for purposes of this discussion. The basic idea is Net Present Value (or Internal Rate of Return) of cash flows. To make this example simpler, let's say that the lowest multiple for active projects for this company is 5. Thus, we want the NPV of the project to be $5 million.
Side note: If you feel you must get into all the heady stuff around the CAPM, start here: http://en.wikipedia.org/wiki/Capital_asset_pricing_model My suggestion is that most business decisions can (and must) be made with much less precision. Bond trading might be an exception.
So, the Product Owner says: "I can't put money on the benefits this new project will give." You say: "Fine. Understand that it is difficult to be precise. But let's do a sniff test to see if we're wasting our time on a low priority item. If you think about all the benefits, do you feel comfortable telling everyone, including our managers, that the implicit benefits of this project, taken together, are worth at least $5 million in NPV?"
This is an order of magnitude swag, but I hope it knocks down a few projects that are being done "for other reasons than business value" I'll say diplomatically.
Does this help a little? Your comments are welcome. You might want to tweak some of my assumptions (cost of project team, return multiple, etc). Easy to do in a spreadsheet.
Wednesday, February 13, 2008
Friday, February 8, 2008
The Nokia Test (2): Working Software
The second line in the Nokia Test says: Software must be tested and working by the end of each iteration.
This is the second of three items that confirm that the team (project) is "iterative". Then there is a series of small tests (within the Nokia Test) for whether the team is really doing Scrum (in Nokia's opinion).
Why this second line (element)? As with almost everything in Agile, there are many good answers to that question. I will highlight three.
1. We can get better feedback. Only by having the software tested and working, can the Product Owner and the Stakeholders give the best feedback. And we want short, small, fast feedback: "Yes, it's what I said, but now that I see it, it's not what I want." When it works, and they put it together with everything else that is working so far, then they can lift their eyes up from the weeds, and start to see if a real customer product is starting to emerge (be formed). Sometimes this allows them to creatively discover other visions for the product (or improvements to the vision of the product).
Arguably, one could get feedback without being fully tested. I am not particularly impressed by that argument, but I'll leave it for now. But my next reason for this line in the Nokia Test addresses that argument.
2. Working (fully tested) software is the primary measure of progress. This is straight from the Agile Principles that were agreed when the Agile Manifesto was written.
And why is that important or right? Well, before that, many were measuring progress by how much paper was churned out, or how many detailed tasks were done, or by the dev team saying "We're 63.2% done". None of these were ever very reliable (at least in my experience and that of many others). Certainly they had minimal meaning to a business side person who had to manage the risk of delivery by a specific date.
OK, so what does it really mean to have working, fully-tested software? Well, each team must define at some level of detail what "done" means. A company, at a slightly higher level, might also have a standard definition of done (with perhaps some wiggle room for special cases).
That definition of done would typically include (or at least address) things like:
* coded (duh!)
* automated unit tests built, in the configuration management system, run, fully passed
* refactored (anything that needs to be refactored has been: code, design, arch) Note: some refactoring might also occur after some things below.
* put into the integrated build and a new (QA?) environment (the new story does not break other things, etc.)
* automated functional tests built, in the CM syetm, reviewed by business guys, fully passed per a QA person
* other testing done (more variable by effort...eg, some performance or exploratory testing)
* business side testing and review (maybe by the Product Owner...full thumbs up)
* fully documented (any docs that need to change because of this story have been changed and reviewed and are perfect)
* no outstanding bugs (or none of any consequence)
If a story passes the above criteria, then a business person (in most projects) can assume a fairly clear and small amount of additional effort to take that story or feature live. This knowledge can be very powerful and give the Product Owner the courage to identify more early releases.
3. Working and fully tested software is necessary to know (meaningfully) the team's velocity. (Velocity is really a later element in the Nokia Test, but this line in the test is setting up the team to have a meaningful velocity.) Velocity is useful in many ways, but I'll just explain it with the family vacation metaphor. When the kids in the back seat ask "when will we be there?", if I know we are going 60 mph (our velocity), and it's 180 miles to go, even I can give a pretty accurate answer. Good enough to make mission critical decisions like whether to pull over for a potty break. And, as it turns out, good enough for most real business decisions. And, as it turns out, giving us about as info with as much quality as we can get.
This is the second of three items that confirm that the team (project) is "iterative". Then there is a series of small tests (within the Nokia Test) for whether the team is really doing Scrum (in Nokia's opinion).
Why this second line (element)? As with almost everything in Agile, there are many good answers to that question. I will highlight three.
1. We can get better feedback. Only by having the software tested and working, can the Product Owner and the Stakeholders give the best feedback. And we want short, small, fast feedback: "Yes, it's what I said, but now that I see it, it's not what I want." When it works, and they put it together with everything else that is working so far, then they can lift their eyes up from the weeds, and start to see if a real customer product is starting to emerge (be formed). Sometimes this allows them to creatively discover other visions for the product (or improvements to the vision of the product).
Arguably, one could get feedback without being fully tested. I am not particularly impressed by that argument, but I'll leave it for now. But my next reason for this line in the Nokia Test addresses that argument.
2. Working (fully tested) software is the primary measure of progress. This is straight from the Agile Principles that were agreed when the Agile Manifesto was written.
And why is that important or right? Well, before that, many were measuring progress by how much paper was churned out, or how many detailed tasks were done, or by the dev team saying "We're 63.2% done". None of these were ever very reliable (at least in my experience and that of many others). Certainly they had minimal meaning to a business side person who had to manage the risk of delivery by a specific date.
OK, so what does it really mean to have working, fully-tested software? Well, each team must define at some level of detail what "done" means. A company, at a slightly higher level, might also have a standard definition of done (with perhaps some wiggle room for special cases).
That definition of done would typically include (or at least address) things like:
* coded (duh!)
* automated unit tests built, in the configuration management system, run, fully passed
* refactored (anything that needs to be refactored has been: code, design, arch) Note: some refactoring might also occur after some things below.
* put into the integrated build and a new (QA?) environment (the new story does not break other things, etc.)
* automated functional tests built, in the CM syetm, reviewed by business guys, fully passed per a QA person
* other testing done (more variable by effort...eg, some performance or exploratory testing)
* business side testing and review (maybe by the Product Owner...full thumbs up)
* fully documented (any docs that need to change because of this story have been changed and reviewed and are perfect)
* no outstanding bugs (or none of any consequence)
If a story passes the above criteria, then a business person (in most projects) can assume a fairly clear and small amount of additional effort to take that story or feature live. This knowledge can be very powerful and give the Product Owner the courage to identify more early releases.
3. Working and fully tested software is necessary to know (meaningfully) the team's velocity. (Velocity is really a later element in the Nokia Test, but this line in the test is setting up the team to have a meaningful velocity.) Velocity is useful in many ways, but I'll just explain it with the family vacation metaphor. When the kids in the back seat ask "when will we be there?", if I know we are going 60 mph (our velocity), and it's 180 miles to go, even I can give a pretty accurate answer. Good enough to make mission critical decisions like whether to pull over for a potty break. And, as it turns out, good enough for most real business decisions. And, as it turns out, giving us about as info with as much quality as we can get.
Subscribe to:
Posts (Atom)
