Why your customers will love agile (even if they think they hate it)
Project management methodology has never been a particularly sexy topic. While it's always been necessary to employ some kind of process to guide any non-trivial software development project, in my experience most of the team will only expend the bare minimum effort to learn and follow the process (that is, just enough to get the project manager off their back). It definitely isn't a topic that's likely to create heated discussion at the team's Friday night drinks.
Well that was true, until the advent of agile development. For some reason, whether they love it or hate it, everybody loves talking about agile. For example, Microsoft's own internal discussion list on agile development often receives dozens of posts each day, and the company isn't even a particularly big follower of agile approaches. It seems project management is sexy again.
But one of the most fascinating aspects of this is that the interest and adoption of agile approaches tends to be driven mainly by developers. Not project management types, not management and not customers. I can't offer a good explanation of why this is the case, but I do think it's great to see developers taking a front seat in driving the evolution of our discipline. Still I find it strange that the people who probably have the most to gain from the benefits of agile are often the least willing to give it a go - the customer.
In some cases this may have been brought on by a bad experience with a team that used "agile" as a synonym for "having no process at all" or "not thinking ahead". These kinds of experiences are unfortunate, but hopefully will become less common as the growing interest in agile turns into practical experience and development teams start to understand that agile projects require at least as much discipline as waterfall projects, albeit of a very different type. However in my opinion a bigger reason why many customers fear agile projects is that they are so used to being promised a fixed scope on a fixed date with a fixed budget, but agile projects will never give that promise. On an agile project the customer does not know upfront precisely what they are going to get for their money. On a traditional project, they know exactly what they are going to get. Of course, most traditional projects blow out in schedule, scope, budget or all of the above, so the customer probably won't get what they wanted at all - but at the time the deal was signed, all was crystal clear and the ultimate failure of the project was clearly someone else's fault.
Some months ago I posted about the challenges with selling customers on agile processes, particularly in competitive tender situations. This post generated some fantastic discussion in the comments, and it's not my intention to go over that same ground again. Instead I want to talk about how customers who reluctantly or accidentally end up employing an agile development team will learn to love it, provided the team knows what they are doing. This all comes from my own experience, not just as an architect on agile projects, but as a "reluctant customer" myself. As I've probably mentioned before, when I joined patterns & practices as a Product Manager (aka "customer proxy") I knew practically nothing about agile development but found myself working with an agile team. After a few weeks of bewilderment, it dawned on me how empowering this development approach was for me, "the customer". Whenever new information changed my previous assumptions on requirements or priorities, the team was completely happy to allow for this. No change request forms. No complaining. No schedule blow out. These guys, thought I, are on to something here.
Let's explore some customer realities and how agile development can help:
No matter how detailed the original requirements, some things cannot be anticipated until you see the application in action.
I've worked on projects where requirements have ranged from 500 page specs and dozens of UML diagrams, to scribbles on the backs of coasters and random conversations. While the level of detail between these extremes is obviously very different, the one thing they have in common is that neither accurately reflected what was eventually delivered. Even though the whole point of requirements analysis is to get as deep an understanding of the business needs as possible, some problems or needs will only surface with real users interacting with real functionality. In some cases these problems can be overcome with minor tweaks, in others they will require significant parts of the system to be thought about differently. Either way, the ability to identify these problems early and inject new or changed requirements into the backlog is critical to ensuring that the product that gets delivered is what the business really needs.
A lot can change in the business during the life of a software development project.
Many software projects can span two years or more, even before their schedules slip. And of course, a lot can change in two years. Competitors can launch new products. Business strategies can change. Divisions can be reorganised. Mergers and acquisitions can occur. In short, almost all the business drivers that led to the project's existence are subject to change. Projects that are unable to course-correct are either cancelled, or will be essentially useless when they are delivered.
Development cost does impact prioritisation.
Like it or not, software development estimates have a pretty high error rate. Even if requirements stay relatively stable, the complexity and rate of change of software makes estimation very difficult. Many organisations have estimation methodologies that can prove quite good for a complete project, but even then it's likely that some requirements will take twice as long as expected and others half as long. Many feature prioritisation decisions are made with an explicit awareness or implicit assumption of development cost. If the costing changes, the prioritisation may change too - for example, if feature A is cheap then it's really important, but if it turns out to be really expensive then the business may decide that features B, C, D and E are more appropriate. Agile projects allow updated costing information to be made available, and decisions made, in real-time. In a waterfall project the scoping and prioritisation decisions are generally set in stone before accurate costing is possible, and a blow-out in one feature can blow out the entire schedule.
When you've gotta ship, you've gotta ship.
Every project has a budget. While some projects are in a better position to secure additional funding than others, no project stakeholder wants to go back to their superiors and explain that the money has run out and they have nothing to show for it. Imagine needing to report one of the following possible outcomes at the time that funding for a project runs out:
- The project delivered everything we wanted, on schedule and on budget.
- The project delivered the most important functionality that we wanted, on schedule and on budget. If we decide the remaining functionality is needed, we can get this done for approximately $x more.
- The project has run out of time and money and they haven't delivered anything yet. However if we can secure $x in more funding, we should be able to get it finished.
Obviously everybody would want to go to the board with outcome 1, but if the estimates were inaccurate or the scope changes, outcome 2 will certainly look better on your performance review than outcome 3 - especially if the additional $x is not forthcoming.
So what's the bottom line? A customer working with a high quality agile development team:
- Has more chance of getting business value delivered within an allocated budget,
- Has more chance on getting what the business actually needs, not what they originally thought they wanted, and
- Is empowered to make tough decisions throughout the project, and has the current project status information to inform these decisions.
Who could ask for anything more?