How agile has to kill projects
November 26, 2007 by Artem
Agile software development methods assume the significant amount of uncertainties and risks in the software development. The idea of the iterative development employed by agile methods is aimed at verifying the project direction and state frequently.
Agile risk mitigation
Agile approach at risk mitigation is to attack the most unsure items first and therefore lessen the amount of the unknown as early as possible. In a way every iteration planning is a risk analysis and mitigation planning session. Imagine a project, where supporting millions of users is something the team is not sure is possible. In this case agile methods advocate for implementing the scalability support before the majority of the features.
Such a proactive attitude towards the project risks can establish the confidence in the project success very early in the project life cycle. However, reducing the amount of unknown might also reveal the fact that the company is building a wrong product, is using a completely inappropriate technology, etc. Frequent reassessment of the project risks might also shed light upon that competitors just overtook the whole market segment.
Kill fast
Often detecting this kind of facts early helps with crafting the corrective actions. However, sometimes it clearly shows that killing the project is the most profitable decision the company can make. Seeing such a sad truth might not be the easiest experience in the lifetime, but sometimes it is the only recipe for saving a pile of company and/or customer money. The ability to fail early and kill the project before burning much time and money is one of the often overlooked strength of the agile methods.
See Also
- Agile Also Means Fall Early and Get Up - Nick Malik advocating the kill parties, "where everyone celebrates when a bad idea is killed before it consumes buckets of shareholder's cash"
Bookmark/Search this post with:
Permalink
Best of AgileSoftwaredevelopment.com
- Scrum backlog templates and examples
- Simple Product Backlog Example
- Simple Sprint Backlog Example
- Can unit testing be a waste?
- Developers Aren't Gonna Read It
- Six Features of a Good User Story - INVEST Model
- Product backlog
- Performancing Metrics Module
- How to use agile methods for the fixed price contracts
- 7 Tips for Improving the Daily Scrum
- Are you assigning your top engineers to projects?
- Professionalism = Knowledge First, Experience Last
- Top 20 Best Agile Development Books, Ever
- Video tutorial: Managing your Scrum Product Backlog with the help of a simple Excel sheet
- Meet you at XP2006!
- Video tutorial: Managing your Scrum Product Backlog with the help of a simple Excel sheet
- Five risks of solo programming
- Extreme Programming
- Video tutorial: Test Driven Development in practice
- 10 Signs That You're Not Agile
- Five steps for starting the Scrum project
- 10 Principles of Agile Project Time Management
- Destructive bonuses
Subscribe to updates
RSS feedNavigation
User login
Private blogs of the regular contributors
Recent comments
-
johnw (not verified)
-
paperdummy (not verified)
-
Ilja Preuss (not verified)
-
John Haugeland (not verified)
Comments
The software development
November 27, 2007 by Olga (not verified), 51 weeks 2 days ago
Comment id: 1387
The software development company (http://soft.belhard.com/) I'm working for has moved to Agile technology almost 2 years ago. For sure some very large project still use RUP, but the productivity and effectiveness of medium size projects increased by 22%!
I've dugg for your article)))))
Thank you, Olga. Regarding
November 27, 2007 by Artem, 51 weeks 2 days ago
Comment id: 1388
Thank you, Olga.
Regarding the topic of this post, do you now kill more projects earlier in the life cycle, than you did previously?
Valuable Software
November 28, 2007 by Brian Shannon (not verified), 51 weeks 1 day ago
Comment id: 1390
One of the principles of Agile is "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." from agilemanifesto.org. That is to say that risk aversion is, in fact, not the first concern of agile.
In the book "User Stories Applied" by Mike Cohn, he makes the argument that Agile does not focus on risk aversion, but rather on value creation. In other words, when determining which stories you will complete first during Agile development, you do NOT necessarily complete the most risky stories first, but, rather, the most valuable (to the customer and/or stakeholder) first.
From User Stories, "Agile approaches are firmly in the camp of doing the juicy bits first. This allows agile projects to avoid solving risks too far in advance and allows them to defer building infrastructural code that may not be needed. Favoring the juicy bits first makes it possible for a project to release early, when only the highest-valued functionality is available.
"But, even when going after the juicy bits first, we still need to consider risk when prioritizing stories. Many developers have a tendency to want to do the riskiest stories first. Sometimes this is appropriate but the decision must still be made by the customer. However, the customer considers input from the technical team when prioritizing the stories."
As shown above, risk should be considered, but it is not the primary attribute to be considered in prioritizing and completing stories.
That said, it is often the case that the most valuable stories will involve the most risk especially when starting a project even if risk is not a deciding factor of their value. There will need to be some infrastructure put into place and often times that infrastructure involves the risk. There is also the notion of 'spike' stories which can be used to do proof of concepts and research into the unknown.
Risk - Value
November 28, 2007 by Artem, 51 weeks 1 day ago
Comment id: 1391
Bigger amount of risk typically is associated with bigger potential benefits. I believe that decision to go first for eliminating risks or for getting some value (and potentially increasing risk for the remaining features) is to be made by Product Owner / customer. The team responsibility is to clearly explain what stories will eliminate which risks.
"Waltzing with Bears" by Tom DeMarco and Tim Lister is a good and small book for starting with risk management.
I remember 2 projects that
December 1, 2007 by Olga (not verified), 50 weeks 5 days ago
Comment id: 1395
I remember 2 projects that where killed rather early. Project managers said after: in any other technology those projects would be continued and company would loose much more money...
Software Development
Post new comment