Great post on how traditional project management techniques involving estimation at the task level needs to change when we move to an agile environment.
Often well seasoned developers don't find this too hard to do, and in my experience, are much more willing to do it at the feature level - because this allows any stakeholder to see how long a particular feature will take, not the nitty-gritty pieces of it.
Some would say that moving to agile is just a dumbing down of estimation (moving from granular task estimation to feature level). Other thoughts?
Best,
Peter Saddington
www.whitebarrel.com/blog
Discussion on:
View:
Show:
People who understand how to get things done, naturally gravitate towards a "spiral" or iterative process, because it keeps the focus on controlling what you can reasonably foresee and validating your direction with your customer. Anything and everything else is an illusion.
If you believe your business wants the illusionary waterfall estimate, enlist them as your on stage partner performing a new and better trick - the Release Plan. And quote General Dwight Eisenhower, "Plans are useless, but planning is invaluable."
BTW: Agile DOES do task planning, but only a few weeks out, at a time, in the Sprint Plan, which occurs after the coarser, long-range feature planning in the Release Plan.
If you believe your business wants the illusionary waterfall estimate, enlist them as your on stage partner performing a new and better trick - the Release Plan. And quote General Dwight Eisenhower, "Plans are useless, but planning is invaluable."
BTW: Agile DOES do task planning, but only a few weeks out, at a time, in the Sprint Plan, which occurs after the coarser, long-range feature planning in the Release Plan.
Doing the work to create the products is what takes the resources, effort, and duration. Size of the product is the biggest determinant of how much it will take to create it and must be coupled with effort and duration per size unit.
All estimates are based upon extrapolating from some presumably known reference to the target being estimated. Thus, estimates will be accurate to the extent (1) the references are suitably similar, (2) there is an appropriate sizing of reference and target that enables meaningful scaling (such as small, medium, and large), and (3) what it actually took to do the reference is known.
Estimating based on the product rather than the tasks is called ?top-down estimating.? It is widely used, especially by those who mistakenly presume their position at the top of the organization somehow imbues them with the ability to estimate top-down. Top-down estimates are notoriously incorrect, because they fail on one, two, or often all three of the above criteria. Moreover, top-down estimates almost always fail in one direction?woefully underestimated schedules and budgets, which turns out to be the primary reason why projects come in late and over-budget.
Mature agile development top-down product estimates are more accurate for three reasons. (1) They are estimating small pieces of work, which reduces the amount of variance in the reference-to-target criteria and is what bottom-up task-based estimating does too.
(2) Through trial and error, mature agile shops have learned to create similarly sized products which predictably can be created in roughly the same effort and time as prior products. This is not new, magic, or rocket science. For instance, your dentist knows very reliably how long a filling takes; and your auto mechanic knows very reliably how long an oil change takes. Both know the times are those required to do the requisite tasks; and more time will be required if additional tasks turn out to be needed.
(3) Agile uses time-boxing, which doesn?t promise to deliver the product in the allotted time but rather promises only to deliver the parts of the product that have been finished in the allotted time. Furthermore, by calling its rework ?refactoring? and declaring refactoring to be a virtue rather than rework, agile has an added way of falsely appearing to make good estimates--avoiding accurately matching actuals to estimates.
All estimates are based upon extrapolating from some presumably known reference to the target being estimated. Thus, estimates will be accurate to the extent (1) the references are suitably similar, (2) there is an appropriate sizing of reference and target that enables meaningful scaling (such as small, medium, and large), and (3) what it actually took to do the reference is known.
Estimating based on the product rather than the tasks is called ?top-down estimating.? It is widely used, especially by those who mistakenly presume their position at the top of the organization somehow imbues them with the ability to estimate top-down. Top-down estimates are notoriously incorrect, because they fail on one, two, or often all three of the above criteria. Moreover, top-down estimates almost always fail in one direction?woefully underestimated schedules and budgets, which turns out to be the primary reason why projects come in late and over-budget.
Mature agile development top-down product estimates are more accurate for three reasons. (1) They are estimating small pieces of work, which reduces the amount of variance in the reference-to-target criteria and is what bottom-up task-based estimating does too.
(2) Through trial and error, mature agile shops have learned to create similarly sized products which predictably can be created in roughly the same effort and time as prior products. This is not new, magic, or rocket science. For instance, your dentist knows very reliably how long a filling takes; and your auto mechanic knows very reliably how long an oil change takes. Both know the times are those required to do the requisite tasks; and more time will be required if additional tasks turn out to be needed.
(3) Agile uses time-boxing, which doesn?t promise to deliver the product in the allotted time but rather promises only to deliver the parts of the product that have been finished in the allotted time. Furthermore, by calling its rework ?refactoring? and declaring refactoring to be a virtue rather than rework, agile has an added way of falsely appearing to make good estimates--avoiding accurately matching actuals to estimates.
Confusing estimates with actuals is something that still plagues us.
Even if scope is rigidly controlled ( fingers, toes and eyes now firmly crossed), estimates are made when you have the least information about what you want to do. You don't have to be Einstein to realise the further on you get, the less meaningful they are.
To take your dentist analogy a bit further, while doing a filling, they notice that some of your teeth are a bit less than straight, and some what discoloured. So you come out from under with gleaming straight overbite, a big bill an you've missed your next appointment....
It's agile's (well iterative really) ability to make that sort of behaviour explicit that makes it powerful. It operates
in the real world not some fantastist's Gann chart.
In terms of manufacturing an estimate, I see no impact from choice of lifecycle.
One of the biggest failings I see is the idea that there is some best lifecycle, you should look at the project and choose a lifecycle that will help you manage it, not manage to squeeze the project into a chosen lifecycle.
Even if scope is rigidly controlled ( fingers, toes and eyes now firmly crossed), estimates are made when you have the least information about what you want to do. You don't have to be Einstein to realise the further on you get, the less meaningful they are.
To take your dentist analogy a bit further, while doing a filling, they notice that some of your teeth are a bit less than straight, and some what discoloured. So you come out from under with gleaming straight overbite, a big bill an you've missed your next appointment....
It's agile's (well iterative really) ability to make that sort of behaviour explicit that makes it powerful. It operates
in the real world not some fantastist's Gann chart.In terms of manufacturing an estimate, I see no impact from choice of lifecycle.
One of the biggest failings I see is the idea that there is some best lifecycle, you should look at the project and choose a lifecycle that will help you manage it, not manage to squeeze the project into a chosen lifecycle.
That doesn't fit into the hype and need to be close minded ... just because you're right is no need to point out that agile always meets it's budget ... but doesn't necessarily deliver anything of value. While waterfall always delivers value but doesn't necessarily meet the budget.
No one wants to hear that you've got to choose the correct method for the situation.
That sounds too much like work!
No one wants to hear that you've got to choose the correct method for the situation.
That sounds too much like work!
correct.
I'm afraid there are near as many muppets claiming your profession as there are mine now, proportionately anyway....
I'm afraid there are near as many muppets claiming your profession as there are mine now, proportionately anyway....
We've been trying to switch to Agile at our company. The biggest problem that I can see is that executive management still wants a reasonable estimate of when the product wil be ready for delivery, and at what cost. Why? They need to figure out how much they can charge for the product based on customer benefit, when that revenue will be available for budgetary reasons, and whether we should just forget about it if the cost outweighs the revenue.
I think Agile is great for some projects. The Chrome browser is a good example. I imagine that it was probably an Agile project. Early on, it was very bare bones and no frills. Since then, it has grown quite a bit, due in great part to user feedback.
This is what Agile is all about and it works great when building a product that the customer can use for free. LOTS of people will try it when they don't have to pay anything, and they'll give suggestions for improvement.
Unfortunately, we still charge for our software and while we've tried to have customer reps on planning and review boards, they don't want to invest any time unless they're certain they'll buy, and even then very little of their time is provided. So we're limited to our own experiences and maybe some customer Q&A results, but we wind up building a fairly feature-rich product in 1.0. In some cases, we've built features that are never used. We're working to minimize that through more customer involvement. But in the end, we have to do things the traditional route so that the company can plan for the results. The "try it for free" model hasn't yet made it here.
I think Agile is great for some projects. The Chrome browser is a good example. I imagine that it was probably an Agile project. Early on, it was very bare bones and no frills. Since then, it has grown quite a bit, due in great part to user feedback.
This is what Agile is all about and it works great when building a product that the customer can use for free. LOTS of people will try it when they don't have to pay anything, and they'll give suggestions for improvement.
Unfortunately, we still charge for our software and while we've tried to have customer reps on planning and review boards, they don't want to invest any time unless they're certain they'll buy, and even then very little of their time is provided. So we're limited to our own experiences and maybe some customer Q&A results, but we wind up building a fairly feature-rich product in 1.0. In some cases, we've built features that are never used. We're working to minimize that through more customer involvement. But in the end, we have to do things the traditional route so that the company can plan for the results. The "try it for free" model hasn't yet made it here.
and a dose of reality.
That fixed cost they want before they start is a fiction.
It's either based on wild ass guesses, or through spending so much effort making an accurate estimate you've all but done the work anyway without a budget based on teh need.
Worse still what eally happens is someone see a revenue and them massages the estimates to make it appear viable.
I've lost count of the number of times I was asked to change my estimates so a project could be afforded.
That fixed cost they want before they start is a fiction.
It's either based on wild ass guesses, or through spending so much effort making an accurate estimate you've all but done the work anyway without a budget based on teh need.
Worse still what eally happens is someone see a revenue and them massages the estimates to make it appear viable.
I've lost count of the number of times I was asked to change my estimates so a project could be afforded.
Wow Rick, your strong bias toward an agile estimating approach is clearly evident, but I wouldn't recommend throwing the baby out with the bath water just yet.
One of the issues my organization deals with is setting and managing expectations for project delivery, and we've been adopting SCRUM and other agile development techniques for a while. This has made the developers happy, but we continue to struggle with delivering applications our customers want within a timeframe they can accept.
Products need to be delivered - period. The vagaries of scope, schedule, cost, and quality have to be managed one way or another, and high quality project managers have done a great job of leading projects to successful outcomes that please both the development teams AND the customer. Unfortunately the high quality PM's that can accomplish these feats of strength and agility are relatively few and far between, leaving the miserable masses to struggle through ambiguous requirements, unrealistic schedules, laughable budgets, and ultimately no way to predict or control the quality of the product.
A good PM can adjust their tools to meet the needs of the customer and the development team. I personally feel that traditional project management approaches will work fine with a spiral development model. I was doing project management 20 years ago and successfully developing with a spiral model (or incremental if you wish) - I just made each turn of the spiral another phase of the project with a customer checkpoint (for scope, budget, and schedule negotiations) at the end of each phase. I set the expectation and managed it - pretty basic stuff.
Good article, and I'm sure it will provoke more thought in the PM community.
One of the issues my organization deals with is setting and managing expectations for project delivery, and we've been adopting SCRUM and other agile development techniques for a while. This has made the developers happy, but we continue to struggle with delivering applications our customers want within a timeframe they can accept.
Products need to be delivered - period. The vagaries of scope, schedule, cost, and quality have to be managed one way or another, and high quality project managers have done a great job of leading projects to successful outcomes that please both the development teams AND the customer. Unfortunately the high quality PM's that can accomplish these feats of strength and agility are relatively few and far between, leaving the miserable masses to struggle through ambiguous requirements, unrealistic schedules, laughable budgets, and ultimately no way to predict or control the quality of the product.
A good PM can adjust their tools to meet the needs of the customer and the development team. I personally feel that traditional project management approaches will work fine with a spiral development model. I was doing project management 20 years ago and successfully developing with a spiral model (or incremental if you wish) - I just made each turn of the spiral another phase of the project with a customer checkpoint (for scope, budget, and schedule negotiations) at the end of each phase. I set the expectation and managed it - pretty basic stuff.
Good article, and I'm sure it will provoke more thought in the PM community.
Hello pfarrjam,
I was surprised to see your statement "we've been adopting SCRUM and other agile development techniques for a while. This has made the developers happy, but we continue to struggle with delivering applications our customers want within a timeframe they can accept."
Can you elaborate on this statement?
What I have seen in my experience is that agile practices still take the same amount of time to finish the actual work but surely makes my customers happy. They see that they can "play" with the product and provide actual feedback earlier in the process. They didn't have to wait until the UAT at the end. Now they have more control over the product that we are building. Moreover, we are delivering actual working product every iteration; that make us capable of delivering the initial increment of the product if they want to.
Well, that's my experience. Please tell me your circumstance where your customer was not happy with agile practices.
Curious!
Manoj
http://theguidingstar.com/
I was surprised to see your statement "we've been adopting SCRUM and other agile development techniques for a while. This has made the developers happy, but we continue to struggle with delivering applications our customers want within a timeframe they can accept."
Can you elaborate on this statement?
What I have seen in my experience is that agile practices still take the same amount of time to finish the actual work but surely makes my customers happy. They see that they can "play" with the product and provide actual feedback earlier in the process. They didn't have to wait until the UAT at the end. Now they have more control over the product that we are building. Moreover, we are delivering actual working product every iteration; that make us capable of delivering the initial increment of the product if they want to.
Well, that's my experience. Please tell me your circumstance where your customer was not happy with agile practices.
Curious!
Manoj
http://theguidingstar.com/
I propose an Agile- methodology. That's Agile minus the daily 2 to 3 hour status meeting and the prep and follow-up time that incurs.
dependant on lifecycle, just a change in what you are estimating.
It's an informed guess based on known information +/- a guess on contingency.
All agile does is theoretically increase the amount of information you have before guessing by narrowing the scope of the task and starting with a more defined requirement.
I've seen them be stupidly wrong in every lifecycle.
It's the foolish desire to confuse estimate with actual twhen aiming at a randomly dodging target that is the real problem.
It's an informed guess based on known information +/- a guess on contingency.
All agile does is theoretically increase the amount of information you have before guessing by narrowing the scope of the task and starting with a more defined requirement.
I've seen them be stupidly wrong in every lifecycle.
It's the foolish desire to confuse estimate with actual twhen aiming at a randomly dodging target that is the real problem.
We should start calling you Robin Hood.
Estimation is not budgeting. And has only the most rudimentary relationship to implementation methods (Agile version = Est. x F1 & Waterfall = Est. x F2 & RAD = Est x F3).
Bottom line folks ... there is a 5 times (that's 500%) variation depending on who you have doing the work.
Estimations are W.A.G.s up until the time that the team is assigned. Then they become guesses.
And until you know exactly what you are going to deliver and how they are at best 50-100% off! (that's after detailed design in Waterfall and after delivery in Agile for those of you who haven't figured it out yet.)
Waterfall delivers what's asked for with a budget variation. Agile delivers on budget with a delivery variation. Pick the one that meets the situation and go with it.
Stop pretending you get something for nothing!
Estimation is not budgeting. And has only the most rudimentary relationship to implementation methods (Agile version = Est. x F1 & Waterfall = Est. x F2 & RAD = Est x F3).
Bottom line folks ... there is a 5 times (that's 500%) variation depending on who you have doing the work.
Estimations are W.A.G.s up until the time that the team is assigned. Then they become guesses.
And until you know exactly what you are going to deliver and how they are at best 50-100% off! (that's after detailed design in Waterfall and after delivery in Agile for those of you who haven't figured it out yet.)
Waterfall delivers what's asked for with a budget variation. Agile delivers on budget with a delivery variation. Pick the one that meets the situation and go with it.
Stop pretending you get something for nothing!
Well put.
You always know when our industry has once again meandered off the path of reason.
!This is the best way...."
Stop listening at the first .
Initial assumption incorrect, rest of piece irrelevant bollocks, usually designed to sell something to a lose well at golf person at a Gartner coffee group.
You always know when our industry has once again meandered off the path of reason.
!This is the best way...."
Stop listening at the first .
Initial assumption incorrect, rest of piece irrelevant bollocks, usually designed to sell something to a lose well at golf person at a Gartner coffee group.
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
