Cost Justifying an Agile Migration

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.