Your company has drunk the Kool-Aid. You’re sold on the value proposition behind the Agile development methodology.
Your CTO directs Development to take training and start executing an Agile process called SAFe (Scaled Agile Framework). At first, it seems like a revolutionary change, but then reality sets in. Agile Teams consistently carry unfinished work over from Sprint to Sprint, and when it is finally delivered, quality is still suspect. You have burn-down and burn-up graphs, but your teams only complain about burn-out. You have RAG (Red, Amber, Green) Status reports that really should be called Watermelon Status reports, because everything only looks green on the outside. Under the covers it’s really screaming red and you don’t see that it’s red until it’s too late. So, what went wrong?
Like most companies you embarked on an Agile journey and you assumed that would make you agile. Organizations that believe they will become an “a”gile organization simply by implementing an “A” gile methodology are likely to be very disappointed in the resulting outcomes. “Big A” methods provide the foundation and the framework to becoming a “little a” organization, but real agility is not something that you can simply implement, it is something you continuously strive for. Ultimately, business agility is only achieved by the cultural adoption of a pragmatic “little a” philosophy.
It is common for Agile Teams to encounter obstacles with other parts of an organization while adopting “Big A” methods that limit real changes to the organization’s bottom line. While adopting “A”gile principals detailed in the Agile Manifesto are an improvement over existing Waterfall processes, the adoption of “Big A” methods alone do not result in a “little a” organization.
The Agile software development methodology focuses on the processes by which software is developed. I.E. develop software better. Transforming to an agile organization requires everyone across the organization to focus on delivering value from the customer’s perspective. I.E. deliver better software. This is not just a play on words, it is important to recognize that while Agile is the Development organization’s responsibility, business agility requires the entire organization be open to change.
Even organizations that do a good job implementing a disciplined Agile approach across the Development organization, often find that the reasons why they keep missing dates or deliver suspect quality are because of things “out of their control.” This typically manifests itself in the form of Retrospectives that have the same root causes or calls to action Sprint after Sprint. Let the finger pointing begin!
Sorry, your Agile Team is not special
Every team, in every organization, is unique. I hear this everywhere I go. After listening to what makes them special and working with the teams for a period, I always come to the same conclusion – your team is not unique. You have all the same tools, personalities, and basic struggles everyone else has. As I start to lay out a plan for helping the team achieve their agile transformation goals, I often find myself reusing the same plays that were successful elsewhere. Not because I’m a creature of habit or lazy, it’s because to someone with lots of gray hairs, its “been there, done that.”
While in between jobs I started to collect and organize my experiences into a collection of plays. The agile Playbook was born. The agile Playbook is a comprehensive compendium of strategic “plays” designed for organizations to evolve to high levels of business agility.
The soon-to-be published book walks readers through both a top-down and bottom-up approach to affect change at all levels of the organization and recognizes that the underlying culture of the organization may need to change and that takes time. Success is measured by the organization’s ability to change quickly to meet the next challenge and the organization is “built to last”.
The overall implementation process takes a “wave and spike” approach. We implement new techniques and ideas in spikes with Leading Teams. Once vetted and stabilized, we propagate the changes like gravitational waves to all remaining Lagging Teams.
The plays are designed to support the Agile Manifesto principals, eliminate waste through lean processes, and apply systems thinking by continuously measuring and assessing speed, cost, quality, and scope delivered. When all the Agile Teams in an organization have adopted a continuous improvement culture then they are special.
