In a recent Dilbert comic strip, Pointy Haired Boss (PHB) tells Dilbert and Wally they will start using agile programming. He explains:
"[Agile programming] means no more planning and no more documentation. Just start writing code and complaining."
All of us who have made the transition from waterfall, RUP, or other gated process to agile can chuckle at this definition. As few as five years back, agile was often seen as a ‘license to hack' rather than a disciplined approach to software development. We've come a long way, but some perceptions persist. One implicit assumption made by Dilbert's PHB is that ‘going agile' is all about programming. He couldn't be more wrong. Moving to agile has effects that ripple through the entire organization, from sales to IT Operations. Some of these effects can be managed through good training. Some are more political than technical in nature, and will require, dare we say it, the delicate hand of your PHB.
What happens when teams adopt agile techniques? How will the rest of the organization react? Maybe you work in a small or idealistic organization with little or no political back-biting or infighting. If so, you are to be envied. Most of us don't live in a perfect world. We are human, and even the best of businesses have a bit of dysfunction here and there. Internal politics, infighting and turf battles will emerge. Your PHB needs to understand and be prepared for this eventuality. PHB can run, but he can't hide from the ripple effects of going agile.
There isn't enough space here to list every organizational pitfall. A lot of them can be managed through education, expectation setting, and the application of basic political know-how. Some, such as changes in funding models, interactions with IT Operations and the clash over availability of the product owner have been documented in previous journal articles. But one issue, the side effects of pull versus push project management, is less well documented but just as potentially damaging. While there are many side-effects of pull versus push, the two I want to discuss are the lack of a master project plan, and reporting status in a mixed-methodology environment.
In waterfall or other gated processes, Project Management (PM) publishes a project plan based on exhaustive up-front analysis and design. PM then ‘pushes' the tasks to the project team. "Here's the tasks, now get to it." We know agile teams don't work that way. There is no master project plan detailing all the work because planning is done just-in-time rather than up-front. The team ‘pulls' work from the backlog for each iteration. And while you might have a master iteration plan, it will be at a much higher level of abstraction than the plan created by the waterfall team.
Why does this matter?
You may not know it, but other parts of your organization use the project plan as a sales tool. If your software is externally facing, you can bet sales will schedule demos to prospects in order to keep sales on the table. Marketing will plan analyst briefings. The executive team will take the plan on the road to talk to important customers. Even if your software is strictly for internal use, your customers will schedule events and executives will make tactical decisions based on your project plan, despite how much it resembles a work of fiction. When you move from a push model to a pull model you take away this important tool. In a pure agile environment, you will never know when, or even whether a specific use case will be satisfied. When