Couples Therapy for Business and Agile Software Development

Agile software development practices and businesses have been trying to get along for a few years now. In some environments, they're able to find common ground, work together to solve each other's problems, and otherwise form a healthy relationship. In others, they can't even seem to have a conversation without squabbling.

After considering their commonalities and their differences, I propose a form of Couple's Therapy to resolve the differences.

Different Perspectives
It's important to start by recognizing that both the agile developer and the business manager have different perspectives, but that neither party is wrong.

Business managers need to plan: to write budgets, make business plans, and even put out release schedules. These are natural parts of running a business, and they're valuable in their own right. A business that doesn't make budgets and plans isn't likely to have the necessary resources, to meet their client's or market's timelines and is a business that's likely to fail.

On the other hand, an agile developer knows that requirements are almost always unclear, always changing, and that, in fact, the users don't really know what they want. They know the cost of implementation is, at best, a guess, and that the best way to manage this is through some kind of process that balances the constants needed to accomplish goals with the dynamism and need for change that makes agile processes so successful. To manage through constant course-correction rather than trying to predict the future with up-front detailed planning.

These perspectives can seem at odds. An agile developer is wont to say things like, "We don't know when it'll be done" and "I can't tell you what features will make it into that release". These statements can be disturbing to a business manager who is unfamiliar with agile processes or with software development in general.

On the other hand, business managers might say things like, "I need a committed release schedule" or "If you don't tell me how long this will take, I can't make a budget or get resources for this project!" These statements can be disturbing to an agile developer who hasn't learned how to interact with business.

Common Ground
Although these viewpoints focus on different things, there's far more common ground than some people realize. Most business managers have seen or heard enough about software development to know that it's unpredictable, and that software projects are hard to deliver "on time, on budget". A good manager also knows that plans are meant to be changed, that priorities shift constantly, and that nothing can be set in stone.

On the other hand, Agile teams know that they need to have resources, and that resources tend to come from budgets. They have planning metaphors, even if those aren't always the metaphors to which businesses have been accustomed.

Both businesses and agile teams desire successful project completion. Both need to react to change on a regular basis. Both thrive on up-to-date information. Both desire to understand the pace of development, and to make sure that the right features are built in the software at a reasonable cost. These commonalities are more fundamental and more important than the differences.

Working Together
So, having realized that both parties have different, valid perspectives, how can they find ways to work together?

Agile teams can help business to plan, to budget by estimating desired features, working on release plans and otherwise helping the business to understand how long it will take to develop software. As long as both parties understand that plans are subject to change, this planning activity can be valuable.

Agile developers and coaches can also help businesses to understand the positive aspects of agile development: the support of change, the emphasis on delivering value early and frequently and on delivering value through software rather than other artifacts.

Businesses, on the other hand, can accept that up-front detailed requirements and planning for software development is rarely as effective as everyone might desire. That many projects fail, and the ones that do are the ones that refuse to deal with the realities inherent in software development. Business managers can encourage 'up to date' information instead of encouraging an up-front plan that never changes.

Both businesses and developers need to keep the other up-to-date regularly on the factors that affect planning: team velocity, changes in scope, timeline and priorities. Keeping the flow of information open, honest, and frequent is just as important in a business relationship as it is in a personal relationship.

The two teams can then work together on adjusting plans, estimates and schedules based on updated information. This kind of collaboration is possible and normal when agile software development and businesses form and sustain a lasting relationship.