Re: How exactly do agile methods mitigate scope creep?
- Hi again,
> My negativity is only meant to be towards the time, and only in that bothThat merely means that the original deadline was wrong. Sticking to it is ... I'm finding it hard to come by a polite term for it. This is one of the problems of waterfall. It somehow transform rough estimates into "facts", and when something doesn't meet the "facts", then _someone_else_, usually the development team, has screwed up (and not the management setting the deadline).
> approaches still don't meet the original deadline.
So what we had, for real, was a vision of a product and a rough guess that if this is what is needed, it will take us an average of 6 months to do it (maybe 5-7 months as a range). As soon as we learned that it in fact isn't all we need, then we should change the vision of the product.
> I'm just acknowledging (and embracing!) that change is inevitable,Let's start with how waterfall prepares for change. Surprise, it doesn't. It assumes that the requirements are complete and that we now should create one big architecture which meets exactly all the needs in the requirements. This leads into a vicious cycle where any change needs to be incorporated into all planned features, including the ones that haven't yet been done (== replan architecture). Unfortunately, there is rarely time for that either, so what ends up happening is that the architecture is "patched up" with the new feature and it is likely that some conflicts between the new needs and the architecture remain. Repeat this for 25% of the features, and voilá, we have spaghetti code and a messy architecture.
> and I'm trying to understand how that change is handled
> differently in an agile environment.
Add to this the fact that if a feature is dropped, the architecture is planned and implemented to support that feature, thereby increasing the complexity of getting anything done in it.
So, how _can_ we prepare for change in architecture and code? First of all, we look at things from user perspective. We start with the most important feature and develop the application to deliver exactly that. We don't build additional architecture, just the one we need (we will have a vision of the whole architecture to give us direction, but it is merely a vision to guide us). We use object oriented design techniques so that when we start adding next features, we don't have to worry so much about breaking things in other parts. We also build very high test automation coverage (both in unit/module and functional levels) so that when we add features, we can quickly verify that we didn't break the earlier functionality (even if we refactor aggressively).
Then, when we add the next functionality (and this can be either according to original plan or a new feature), we refactor the architecture to accommodate the new feature (if we did a good job with simple design and test automation, this should actually be a pretty simple thing to do).
In other words, Agile projects build the ability to change into the way of working. Even originally planned features are essentially changes to previous functionality. Changed features are not treated in any way differently, so therefore the amount of change is irrelevant for the development team. The higher the skill of the team, the more they are able to build change capability into their way of working (and note, not all Agile projects have that kind of skill, so you will likely see "Agile" projects which have trouble with this approach).
Process Development Manager, Agile Coach (CST)
Digia Plc., Finland
- Thank you Petri ... some interesting emerging ideas there.
My experience with cost/benefit analysis is that you can manipulate the figures any way you want to achieve the outcome that you want. Raising or lowering your 'cost of money discount rate' for example can make a big difference. So money-based values can be definitely manipulated.
Calculation of business value can be partly done as a money figure. For example, if having that feature means that one person can be fired, then that cost saving is a 'business value' (yeah, I know ... not a nice example ) . But most of the time 'business value' is a subjective perception that may very well vary from person to person. Such as 'I can do my job more easily' or 'I will make fewer mistakes' or 'I will have better information available to me'. So it therefore needs to be the PO's job to filter and manage and balance the various perceptions of 'business value' and come up with a decision that it is 'Mandatory', 'High Value', 'Moderate Value', 'Low Value', 'No Value' or a similar scale (maybe 'Must Have', 'Nice to Have', 'OK if you can get it', 'Don't Want'. But this is only half the story. The developers can provide the cost side in terms of time and money ... maybe even in terms of Story Points. Now there's an idea ... compare 'business value' of a feature against the story points value and somehow decide if you are getting 'value for points'
But however you do this, you are still estimating, with the essential estimating error that is always involved.
Personally, I am not into 'profound and insightful' statements really. The original story line of this was 'exactly how do agile methods mitigate scope creep'. We all know what scope creep is, even when the term is used in a non-pejorative manner. It is very simply the discovery of new or different requirements during the project activity, that were not understood or requested at the start of the project. These new or different requirements change the game plan in regard to the mix of deadline, cost, resources needed etc.
Traditionalists, following the 'plan the work and work the plan ... we refuse to learn more after the BDUF phase', see this as incompetence on the part of the original analysts, or the stupidity of the users for not knowing what they wanted at the start. They penalise this by imposing rigorous change control methods, which often take more time that the requested change itself would require. Traditionalists try to 'mitigate' this by imposing penalties for 'late delivery' or by just refusing to accept the changes, refering to the contract to support their refusal.
Agile does not 'mitigate', as in prevent, scope creep. In fact, agile encourages scope creep, admitting that it was highly improbable that the requirements as identified at the start of the project will remain constant and unchanged, and were so fully detailed as to ensure no misunderstanding whatever.
Agile handles this essential scope creep by providing a continual opportunity for adaptation and evolution of requirements. In a project with a fixed deadline, agile provides an excellent and simple way to ensure that those features that are mandatory and of the highest business value (as decided by the PO) are at least what is available by the deadline. In fact, agile goes further than that, allowing you to constantly monitor the likelihood of achieving that by the deadline, which is just as important. Of course you can do this in a traditional approach, but agile importantly includes this as an inherent embedded part of the process.
So, working within the usual and natural limits of estimating accuracy, on any day of the week the PO should be able to tell what user stories, currently known and listed in the Product Backlog, are likely to be completed by the mandatory deadline. This is the simple calculation of Project Backlog Story Points / Velocity. Nowhere in traditional pm approaches does this seem to be a required part of the process, or even a possible part of the process.
This knowledge of what is likely to be completed by the deadline can be used to stop the project if the outcomes delivered by the deadline will not fully useful. Or it enables a decision about extending the deadline. Or it allows a further review of what is likely, what is important, and if that is useful.
So, cut and slice it whatever way you will, agile provides the transparency, the ability to modify the plan, the value of discovering 'real' requirements just-in-time to develop them, the extension of knowledge about requirements, about deadlines etc. etc. What a way to go!!!!
The real problem is that most users have been burned in the past, and blame it on lack of planning, lack of rigor in determining requirements, lack of adherence to the plan, poor estimating etc., so they insist on more planning, more rigor in determining requirements, greater of adherence to the plan, more commitment to the estimates, not aware that this sows more of the very weed seeds that they have seen grow in the past.
Twenty years ago I read an article in Byte magazine (remember Byte magazine), entitled 'The Planning Ritual'. It was a good article, that essentially equated software planning with the animistic practices of voodoo religions and superstitious 'natives' (whoever they might actually be). If the crop fals, it was because you only sacrificed one chicken at the full moon before planting the crop. So next time, sacrifice two chickens ... that is a greater guarantee of success of the crop.
Date: Tue, 7 Jul 2009 06:20:40 +0000
Subject: [scrumdevelopment] Measuring business value (ex-How exactly do agile methods mitigate sc ope creep?
> Profound and Insightful it might be, but it merely opens a discussion about how to measure 'the return of the features' in the sprint.We've tried to give this a thought, but just like about everyone else, there isn't a clear answer to this.
> In a way this goes to the very foundations of what we term 'business value'? Can we monetarise 'business value'? There has been a lot of discussion in this forum about how to estimate 'business value' or how to quantify it. I do not remember anyone coming up with a way to give it a money value.
> So ... how to do the necessary Cost/Benefit Analysis of 'the cost to do the next sprint' over 'the return of the features in them'.
> And cost to whom, and return to whom, by the way?
In a recent discussion we thought a larger scheme to look at the issue. It's not really measuring the value of individual features (you need to do subjective or other value analysis on them), but at the overall value framework in product development and customer products. This is still in the thought-works, but I'll summarize our thoughts.
One of our customers is in large scale customer product market. What are the most expensive (== profit-hurting) risks that realize?
- Product releases are postponed due to buggy software or hardware
- Products need to be recalled from market to repair for some bugs or hardware malfunctions
So what they could do is look at those numbers in a larger set of projects, calculate the cost of those events, then do some analysis on what was the reason for the problems, who did them, and what was the project mode, etc. That should give them a bit of qualitative info on the issue. It would also give them an estimate of the cost of such errors, and we estimate that cost to be very large when compared to things like developer hourly wage or other costs during the project.
Assuming they do that, we can then look at the ways in which they can mitigate those risks in the most effective way. Our answers would of course be quality and developer skill, and the way to do it would be Agile. We would like to show that by investing a little more on the work itself and the people who do it, they can save lots more in the long run. I know this customer is well on their way to Agile, but they still have a lot of "low-cost thinking", which is hurting them in many many places.
So, once we get past that hurdle, we can then look at how could we best predict (and prevent) the likelyhood of a schedule overrun or a product recall? Well, if there are no known bugs, the likelyhood of a problem in the finished product is much much lower than if they have a project with a three or four digit bug count. Also, if they have a project with a very high test automation coverage, the same effect. So by measuring those things (and a few other things) they can roughly evaluate the value of doing high-quality work in the first place and maybe also evaluate project efficiency by other things than average developer hourly cost (which, as we believe, tends to have a negative impact on development quality and productivity) .
So, these thoughts don't respond to the questions directly, but may spark some new ideas.
Process Development Manager, Agile Coach (CST)
Digia Plc., Finland
Let us help with car news, reviews and more Looking for a new car this winter?