BrainsLink

Linking the left brain and the right brain

Process Misalignment Is a Leading Cause of Agile Failure

Transitions from traditional software development approaches to agile ones fail occasionally. None of us who try to faithfully practice agile development like to admit it, but it’s true. I’d like to explore one of the key contributors to those failures — process misalignment.

Here’s an example of how this happens.

Let’s say the business stakeholders have a process they follow faithfully. For example, they meet every Monday morning to go over important open items and take corrective actions as needed. They either make decisions during the meeting or assign someone to resolve the issues offline.

This scenario is quite common across corporate America and it generally works well. The software development teams escalate issues to the business and they receive responses the following Monday. With waterfall development, waiting a few days on average for a response is normal and not disruptive. Project managers simply build these lead times into their schedules. (There is usually a procedure for handling urgent requests but it’s often cumbersome and its use is discouraged.)

Now the company decides to switch from waterfall to Scrum as the software development approach. Everyone agrees that going agile is a good idea. The new Scrum process is implemented but the existing business process isn’t changed. Those weekly meetings remain the venue where tactical decisions are made.

We have a process misalignment.

Agile developers generally need answers to their questions on the same day. They can’t wait until a Monday business meeting takes place. The business process and the development process are misaligned.

In this example, the root issue is that the software development team may be empowered and self-organized but the business team is not. In particular, the Product Owner doesn’t have the authority to make decisions. He is merely a pipeline connecting the Monday business meeting to the development team.

The point is that if you want your software team to be agile — I mean truly responsive and energized — the business stakeholders must be equally agile. Processes, attitudes and rules have to be aligned. It seems obvious but it’s often ignored.

photo credit: ant.photos via photopin cc

Updated: December 3, 2012 — 9:40 pm
© Damicon 2014 Frontier Theme