“Is Agility really supposed to work like that?!”
Vicky, a former project manager passionate about Agility who became Scrum Master during the Agile transformation of her big organization, feels like she is living a nightmare worse than what she remembers of the traditional mode.
Her team’s sprint planning is at a dead end. The team has identified several external dependencies that all are responsibilities of different service teams working with Kanban. The redesign should go through the Product Owner of the architects’ Kanban to be prioritized. The “Kanban Master” of the clients’ central system has recently explained that her request was not conforming to the team’s entry definition. Her team needs to justify it better.
Finally, the environment access team has recently faced several production issues and even though it is in progress, Vicky’s team request has been stopped, compromising a major item of the next sprint. When she is considering a paced integration of the next release train, the pressure to deliver commitments of the last planning session between the teams is enormous, because these components are essential to unblock at least two other Scrum teams.
How is she going to get through this nightmare which, unresolved, will put a lot of negative pressure on her team until the next review in two weeks?!
What is local optimization?
Local optimization is a frequent consequence of implementing Agile methods and techniques without a general understanding of the values and principles behind them and without considering the global impact in terms of business value for the final customer.
Let me use an example mentioned above, the example of the architects’ Kanban. If there are several hundred projects in parallel in the organization, which is frequent in big businesses, the conclusion is often that it is impossible to have a full-time architect for each project.
After having realized the inefficiency of a 10% assignment per project with the help of an Agile coach, the team could be seduced by a Kanban approach. It would allow regrouping all the architects in a full-time self-organized team that would provide an “Architecture service” for specific needs of the projects.
These would be organized in a list of priorities (i. e. a backlog) by a designated person and supported by architects only if their capacity allows it. Though attractive, this solution presents the main characteristics of a local optimization.
Losing Sight of the Final Customer
Fragmenting specific work in small pieces that go into this Kanban possibly makes it very difficult to have an overview of business vision and customers’ needs. It can have a negative impact on partial solutions that are being considered, at least from the point of view of the final user.
Diminution of Global Operational Autonomy
Having optimized the work of an essential functional group around internal execution efficiency, the team has created a bottleneck for all projects working on the final customer’s needs. The focus is especially put on mastering the work processes and on growing skills for a small number of team members, to the detriment of the whole organization’s autonomy.
Additional Coordination Required
In a situation where the Kanban/Scrum teams depend that much on each other to succeed, a need for coordination and integration emerges naturally. Often, this results in “over-coordination” with a growth of operational controls, to guarantee proper functioning of the whole. The Scaled Agile Framework proposes a very seductive vision of how all this coordination could be orchestrated organization-wide. However, adoption of a model that prescriptive is often dotted with major pitfalls and offers few compelling results for the business.
Toward a Holistic View
A major difficulty for organizations with strong traditional roots comes from the way they evolve during their growth. In an effort for planning and controlling execution, using the expertise in the most efficient way as well as controlling all risks upstream, organizations have acquired structures that are often very vertical, divided by nature of work or type of expertise.
But in these organizations, value creation flows are horizontal, often crossing many functional domains to create together a product or service the customer is satisfied with. To make this dichotomy efficient, organizations have responded with an increase of processes and controls to ensure that units obtain the planned results.
From vision to discontinuity, going through funding, design, development, trials, implementation, exploitation, maintenance and evolution to name just a few, the lifecycle of a product translates into a phenomenal number of file transfers, approval, transmission of knowledge, documentation, etc.
By implanting Agile techniques without trying to adopt a more holistic view (less fragmented), we end up getting very localized benefits, not at all aligned on a business vision and a need of the final customer. It is difficult to hope for tangible gains from Agility on a global level if the transformation of local techniques is not accompanied by questioning practices presently accepted on all levels of the organization.
If we go back to Vicky, the strategy that has the best chances of success is making this nightmare visible in order to increase the awareness of those who can influence the introduction of a more durable solution. Even if it does not solve all the problems on day one, by accepting the status quo silently, Vicky is likely to harm herself as well as the organization on the long run.
Change is not magical. It is the fruit of sustained effort from people conscious that it is possible to work differently, and that ends up toppling certain organizational “truths”. Finally, if this strategy does not work, you should remember that there are other organizations around you that have gone a long way and would appreciate the true value of your talents. They might offer a more humane environment to experience Agility.
No Comment