Agile need not deliver business value early

Agile methodologies are gaining higher acceptance in the software development community day by day. Agile methodologies show their superiority over waterfall methodologies of software development but in the excitement of having found a better way to develop software, Agilists have started emphasizing that the Agile Methodologies can deliver business value early. The promise of early business value delivery, though a very seducing argument in the favor of Agile, needlessly burdens the software development teams to deliver something that they were never trained for. Using early business value delivery argument in the sales process, you can create an expectation so that the software development team's performance will be measured by the business value they deliver with their software. Agile methodologies or any other software development methodology, for that matter would play a marginal or insignificant role in the early delivery of business value. Agile Methodologies should not be advertised as a new faster way to business value delivery with software.

The most software development efforts, where Agile methodologies are applied, are initiated in response to solve a business problem. Cost savings, increased efficiency or higher revenue by effective use of software are among the several important factors that justify the money and time invested in software development, and not too uncommon pains and frustrations faced during the software development process. The gap between the date when the customer notices the business value of software and the actual delivery date of working software can be long. Only customer might stay on to witness the real business value of software while the software development team would have moved over to other assignments.

Business value: Difficult to measure

The business value of software is not a well defined term. Business case for software development is often poorly constructed and involves some elements of guess work that makes measurement of business value hard even when the software has been delivered and gone live. A good indicator of the early delivery of business value could be, how quickly customer can earn back the investments made in the software development. Though this is done rarely and almost never when a project is yet to start, Agilist wrongly preach customers and the software development teams that delivering good quality working software and delivering business value is the same thing.

Limited success of Waterfall

Agile movement has its foundations in solving the decades old problem of limited success of waterfall methodologies. In waterfall projects, software development teams encountered steady stream of requirement change and invited criticism for the late delivery of software. Software development teams were also blamed for poor engineering of software leading to surfacing of bugs and performance problems when the software was put in to production. Should we now over promise and set expectations about business value?


Software professionals are not business experts

It is hard to find good business experts among software development professionals except for few gifted people who can boast of having expertise both in software development and business domain. Professionals, especially those in software services industry, work on software development assignments in several business domains in a year. This job rotation leaves professional little time to invest in mastering the business of a customer and understand the business value of software in depth.

During pre Agile days, the software developers and architects interfaced with the business experts through business analysts. Notwithstanding the various efforts to simplify the communication between business and software developers, software community did not succeed in eliminating the person who sits between the business and the technology. In Agile methodologies, such as Scrum, the Product Owner, masks development team against the detailed discussion taking place during the discovery and the prioritization of the business requirements.

Agile methodologies claiming to deliver business value early put Agile software development teams in a difficult situation to deliver something, which they at their best have limited understanding of and are unqualified to measure. As a matter of fact, customers never expected software development teams to deliver business value and never blamed them for failure to do so. Of course, customers always and rightly expected development teams to deliver good quality working software on time. Agile methodologies have demonstrated their superiority over waterfall methodologies in delivering good quality software and therefore Agile methodologies can lead to higher customer satisfaction.

Business value of a waterfall product

The business value of software has been difficult to measure even for business experts let alone software development team whether using agile or waterfall methodology. The choice of a methodology will insignificantly impact the delivery of business value.

Few years back I came across a VAX Basic application at a retail chain which was in use for almost ten years. Daily sales figures from different stores were consolidated using the batch processing capabilities of the VAX Basic script. In terms of its usefulness, not only this VAX Basic application had paid back several times the amount invested in its development, it also withstood the challenges posed by business growth in past ten years. Though this application was written poorly and gradually became difficult to maintain due to the scarce VAX Basic skills, it was extremely valuable for business since a critical part of the business remained happily dependent upon it for several years. After a long wait of ten years, we can credit the programmer and the methodology used by him, for delivering the best business value.

Deliver good software on time and nothing more

Now the question comes why Agilists claim that Agile can deliver business value early despite of the fact that the customers never expected software development teams to do so and the software development teams are rarely capable of understanding the business value of software. The answers lie partly in the fact that the word Agile is being used increasingly in the sales pitch where there is a tendency to overpromise and partly in the poor definition of the word business value. Poor definition of business value can set expectations that might be open to free interpretation.

Business value of software can only be measured by business people who understand the business problem that is being solved using software. Many times the business value of software can not be measured in advance. Agilist claim that they can deliver business value early while in reality at its best the Agile methodologies can deliver working software early.

Conclusion

I would like to conclude by saying that the Agile Methodologies should not claim that any Agile software development process will deliver business value early, because it creates unrealistic expectations about the performance of software development teams. Agile methodologies should emphasize the timely delivery of quality software, shorter feedback cycles and room to accommodate change. Sales people can highlight the elimination of wasteful features by customer feedback and short delivery cycles, as strong points favoring Agile. These arguments are compelling enough for the customers to choose an Agile methodology for software development. In the early delivery of business value, timely delivery of quality software plays a role but timely delivery of quality software is hardly sufficient to deliver the business value early.

Comments (3)

  1. Machiel Groeneveld - Reply

    October 30, 2007 at 11:36 am

    I agree that we should be careful not to overpromise. The agile principle people are refering to is 'continuous delivery
    of valuable software'. The term business value is actually very broad and always up to the customer. An important part of agile software development is the discovery of what is actually valuable. The best way to do that is trying to improve the business process in small steps. One nice example is the roller skate example from Martin Fowler. I see it no so much as a promise, but a way of collaborating with the business.

    http://en.wikipedia.org/wiki/Business_value

    http://martinfowler.com/bliki/RollerSkateImplementation.html

  2. luuk dijkhuis - Reply

    October 31, 2007 at 11:37 am

    Quite true indeed. Nevertheless the opportunity to get earlier ROI (or possibly a better P&L rate) by rapidly bringing usable results to production is easily overlooked in an environment where traditional development reigns. It might still be a factor that merits explicit mention, even if it is not boastfully labeled "the business value".

  3. [...] with the customer can deliver the best value. This also forced me to think about my earlier blog on business value delivery with Agile. An agile team can comment on business value if they understand the domain and they have access to [...]

Add a Comment