Cost Justifying an Agile Migration

Posted by Shane Hastie on May 05, 2009

Sections

Process & Practices,

Enterprise Architecture

Topics

Agile ,

Governance ,

Adopting Agile ,

Agile in the Enterprise

Tags

Remuneration and Incentives ,

Adoption ,

Management ,

Introducing Agile

 As companies are experimenting with and examining Agile methods, the cry from the executive suite is “show me the money”;  changing a large organisation’s approach to delivering software is akin to turning an oil tanker – possible but it takes both time and energy.   Management need to be convinced that the change will deliver on one of the two fundamental strategic objectives that drive every organisation – reducing cost or increasing revenue.

In a 2008 article Scott Ambler addresses the motivation behind the cost-justification question, and points to a number of sources which show that

• Agile approaches are more successful than traditional techniques
• Agile teams are more productive than traditional teams
• Agile projects produce higher quality products than traditional approaches
• Business stakeholders are more satisfied with the outcome of Agile projects
• Agile projects cost less than traditional development projects

Ambler provides the raw data for the results cited in another article available here.

A lengthy LinkedIn discussion on the topic in the Agile Alliance group   raises a number of points:

• Measuring knowledge worker productivity is hard at the best of times
• Because it doesn’t make sense to do exactly the same project twice in two different methodologies a direct comparison is effectively impossible
• The value of early feedback is most often found in costs saved from mistakes not made
• Agile projects tend to foster innovation which results in better products which more effectively meet the business needs, and “blow the competitors away”

One contributor to the thread (Steve Gordon) stated:

Along the lines of measurement driving behavior is the issue that the behavior of knowledge workers under agile is more different in kind than in quantity.

Agile can be expected to drive discovery of requirement improvements much earlier and faster than under more traditional approaches (due to feedback on working artifacts early and often, and being open to change). Improving the requirements improves the value of what being produced.

Just measuring raw productivity will totally miss this important effect of agile. Even if raw productivity were to go down a bit (especially during the transition), if what is being produced is more useful and relevant due to frequent concrete feedback, the value delivered to customers can be expected to be much greater.

But, then how to measure the value delivered to your customers? I would think that your customers would know better than anybody else. It also depends on the market. In truly captive markets, quantity delivered might be more important than relevance or quality. In some markets, innovations blow your competitors away much more effectively than more check boxes on feature comparison charts.

Interestingly CNN recognises that Agile is having an impact on management approaches to software development as reported in their article on “50 Who Matter Now – people, products, trends and ideas that are transforming the world of business”:

Agile teams work very quickly -- sometimes in as little as a week -- to create small chunks of code. Once a component is finished, additional features are added, with the process repeating indefinitely. Agile also has a reputation for enabling managers to deliver products on time and under budget, which helps explain why it has become a methodology of choice at companies like Google and Lockheed Martin.

Will this endorsement encourage or discourage the takeup of Agile practices in businesses today?

Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand

1. Back to top

   Those numbers are misleading

   by Bashar AL-Jamal

   I have had the opportunity to go over the data you have presented as well as many other Stats that is trying to sell Agile as a cost cutting methodology.
   
   
   
   While I am not disputing the authenticity on those stats, what I disputing is the fact that when reviewed in proper context, you will quickly realize that these results are built on narrow scope and unqualified assumptions.
   
   
   
   What is the really the measurement of "Quality"?
   
   
   
   Ambler shares this pie chart as if Quality is something universally defined!
   
   
   
   
   Is by Quality we mean:
   
   
   
   having no "bugs"?
   
   Performs well in production?
   
   the cost of maintenance is less?
   
   the code is reusable?
   
   the code is usable?
   
   it passes the unit tests all the time?
   
   etc.
   
   
   
   
   
   Same thing could be said about "Productivity" what does that mean? For each organization the definition differs because they have different factors/metrics that shape what Productivity is.
   
   
   
   Agile reduces cost (overall) when it comes to small size projects that have small team. Normally the scope is limited and defined. Yes in those cases it reduces cost, but what kind of cost does it reduce?
   
   
   
   The cost of debugged line of code per hour. If this is your measurement of cost then it will fall apart once you take this to macro scale enterprise projects that run for years and involve hundreds of developers.
   
   
   
   We now hear of Scrum of Scrums as an effective way to manager Enterprise scale development.
   From my experience at ADP Canada (www.adp.ca) rough figures have shown us that that if you compare cost/hr of an Agile vs other methodology, Agile does cost more (do not freak out this is not bad!). Also, the Project Management involvement is much more extensive because it extends almost throughout the whole development lifecycle. The logistics of a Scrum of Scrums is not as simple as it seems when you hit the ground.
   
   
   
   But, what I also noticed that we can get earlier to production ready code with higher level of confidence. So here is your balance!
   
   
   
   Agile does not necessarily reduce "Cost", but it sure does increase "Value"
   
   
   
   So to say "Agile drives the cost of development down" is the wrong statement to make because it is inherently inaccurate, unqualified, and it actually will fire back in the context of long running projects. Simply put you loose credibility.
   
   
   
   Therefore, if you measure cost on the basis of missed business delivery window or meeting a critical time to market then we start to see that Agile can reliably in a repeatable and reproducible manner allow to hit your strategic business windows.
   
   
   
   The true value of Agile is a Reliable, Reproducible, and Repeatable Value delivery not Cost reduction. Consistency is a strategic metric that allows Business to compete.
   
   
   
   
   Regarding Quality:
   
   
   
   
   
   Code Quality is improved when using Agile methodologies like TDD, pair programming etc...
   
   But System Quality is not. Agile have nothing to address Enterprise Systems Complexity. Let me use an analogy here from my view as a Systems Architect:
   
   
   
   Mathematical logic asserts that 1 + 1 = 2 always.
   
   
   
   In enterprise processes the assertion is a bit different: 1 + 1 results in a maximum of 2 but by no means is this is guaranteed.
   
   
   
   So if we consider a System is a collection of Lego blocks where a block is the production ready feature.
   
   
   
   Does the fact that each component is better "Quality" result in a System of Better "Quality"?
   
   
   
   Agile still does not have a tool to address the quality of long running, long living systems because it offers no methodology for Systems Design and it is not intended to do that.
   
   
   
   In conclusion, Agile should be promoted using Value increase not Cost reduction. Same thing holds true for SOA.

   Reply

• Older >