Management can get the feeling of losing control when their enterprise adopts agile and starts deploying self-organizing teams. Procedures, review boards and consultation bodies can become superfluous when switching to an agile approach, but they may not realize that, says Marcel Heijmans. Trying to regain control with additional planning can make things worse, causing "death by planning".
Marcel Heijmans, an independent software engineer operating under the name Mnemonics, will give the presentation death by planning at the Agile and Software Architecture Symposium 2014; a 1 day conference in the Netherlands where software architects, developers, requirements engineers and information analysts meet to share knowledge about software architecture.
InfoQ interviewed Marcel about planning agile projects, scaling agile, the role of architecture in agile adoption and practices for enterprises that want to do smaller and more frequent deliveries.
InfoQ: Your talk is titled "death by planning". Can you elaborate what you mean with that?
Marcel: "Death by Planning" is a Project Management Anti-Pattern, which describes the problems that are caused by excessive planning for software projects. Detailed planning is an appropriate activity for deterministic processes that scale linearly. When processes show a more stochastic behavior, the complexity of a detailed planning will rise rapidly. Many software projects contain unknowns and chaotic activities by their very nature.
InfoQ: How does planning in agile differ from planning in waterfall projects?
Marcel: A "Project" is confined by fixed period and fixed costs and/or fixed scope The waterfall method provides a structure to plan and control these parameters. I consider an "Agile Project" as a contradiction in terms. If you relax the definition of "Planning", you could consider prioritizing the Product Backlog as planning. Of course the Sprint (in Scrum) is a classic planning activity, since the Sprint is confined by both time and scope. The rationale is that the period of a Sprint is small enough that detailed planning is useful.
InfoQ: You consider software development to be engineering. What are the implications of that?
Marcel: Engineering is the problem solving part that precedes manufacturing and is hard to plan. Fortunately in many areas engineering is a small portion of the total amount of work that needs to be executed with great precision but only once. When the complete software development process is engineering then utilizing detailed planning for the software development process is less suitable.
InfoQ: What is your view on adopting agile in enterprises. Can you scale agile, and if so how can you do it?
Marcel: Enterprises embrace Agile because of the successes it accomplishes. Many aspects of Agile (Scrum) are easily incorporated in Enterprises. The few essential ones that aren't, are easily overlooked. However the "User Feedback" part (and the corresponding PO role) is really hard for big organizations. Ironically this part is the main contributor of the acclaimed successes. Moreover scaling the easily incorporated aspects of Agile, such as creating teams, working in iterations, daily standup and Sprint review, is possible and there are many frameworks available for that. However the viability of scaling the "User Feedback" loop that determines product readiness is inversely dependent on the consensus culture of the corresponding organization.
InfoQ: What can be the role of architecture related to planning when an enterprise is adopting agile?
Marcel: The Engineering nature of software development, combined with the inherent complexity of big organizations and the inability of enterprises to implement Agile in a consistent manner, causes a sense of unpredictability. When management feels out of control it will reach to the "standard" management tool of planning to regain control. However detailed planning is not suitable instrument for engineering activities and hence the role of the architect is to provide technical solutions to the problems at hand. Having said this, not all problems are best solved architectural solutions.
InfoQ: From your experience do you have suggested practices for enterprises that want to do smaller and more frequent deliveries?
Marcel: Many enterprises maintain Release calendars with a low Release frequency after adopting Agile. This approach creates a perfect breeding ground for excessive planning by management. The complexity of the system landscape and the corresponding dependable chains between those systems are the main reason for Release problems. In conjunction with the inability to technically Release more often. Using "Planning" to synchronize a dozen of Release calendars of dependent systems is a huge feat (waste of time).
Applying a mechanism similar to the "Feature Toggle" described by Fowler, decouples the Release dependency between provider and consumer. Hence reducing the complexity of the Release at the expense of a minor extra effort (building the "Feature Toggle").
Another enabling practice is to provide automated deployments. I found that providing the tools that enable more reliable and automated Releases will result in a higher Release frequency. Although the dependency between the systems remain, higher Release frequencies reduce the pressure on Release calendar synchronization.