According to the Project Management Institute, in 2007 61% of all “IT” projects failed or were halted before completion. In 2008, more than 75% of all projects exceeded budgets by 30%. All too frequently, IT projects fail to meet customer or user expectations. There are many risks inherent with creation in an enterprise IT environment: that the client is not sure what they want, that requirements were not properly documented, that change-orders were requested, that desired functionality was not possible or simply that the budget was not sufficient.
- How software development can go awry
Rather than accepting these risks as part of the cost of software delivery, the Agile methodology seeks to tackle those risks head-on with an approach of iteration, review, user acceptance testing and, most importantly, communication.
In some cases the customer may know what they want but not what they need. As Henry Ford said, “if I had asked customers what they wanted, they would have said a faster horse.” The difference between what a customer wants and what they need may be substantially different and likely carries a substantially different cost as well.
In “Waterfall” practices, developers and consultants obtain all the documentation up front, because they want to make sure that the project is built just the way the customer want it. Why does this not work every time? They discussed how they wanted it done, they laid out plans; why is it taking so long?
The problem is communication; a “Waterfall” approach may get what a client wanted, but it may not always get what they needed. Also, the “Waterfall” approach is not designed for changing expectations. As Supreme Court Justice Potter Stewart once said “I can’t define it, but I’ll know it when I see it” (paraphrased). It falls on consultants and developers to find out what clients need, without taking more time or money. How do we do that?
The short answer – Agile. The long answer – ask, more and more, until the development process becomes a joint-effort between the stakeholders and the creators. Being wise comes from asking questions, while being smart comes from asking the right questions. The more the customer and their firm can be involved in software creation, the more they take ownership of the software and, most importantly, the more the software becomes what they need.
The Agile methodology has done a good job of bringing stakeholders closer to the project and allowing customer interactions with engineers to create beautiful software that matters. It is still evolving as more people can see the benefits of shorter feedback cycles and smaller batching, even moving to continuous delivery. Like Wayne Gretzky said, “a good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.”
This post is a collaboration between Max Milhan and guest contributer, Chase Doelling.
Chase is the Product Owner of Agile University at Rally Software Development, overseeing 70+ national Agile training courses with 1100+ attendees in coordination with 45 trainers. Chase is a CSM & CSPO and is obsessed with finding better ways to do everything.
You can see what he is up to at www.chasekaizen.com
Additional Reading:
Rally Software
Chase Kaizen
