By Colleen Johnson, ImagineX Consulting Adaptive Agile Practice Director
As a community, when we talk about applying agile practices, engineering is typically where we start. Engineering is often viewed as the bottleneck in the customer delivery flow and is a very expensive part of the overall process. It makes sense that we look to this part of our organizations to optimize efficiencies first. Unfortunately, this is only one small part of the overall system at play. Leveraging what we know about systems thinking, we cannot optimize only one part of a system without feeling its effects elsewhere.
Something that we find in many “Agile Organizations” is that engineering has changed their practices to be more iterative, incremental and collaborative but the rest of the business is stuck in legacy practices like annual roadmap planning, individual resource allocation and marketing driven deadlines.
As engineering gets faster the rest of the company feels more and more pressure to define work faster and launch to customers more frequently. What does it take to make the WHOLE organization truly agile?
I had the opportunity to experience this first hand with an organization that had slowly transitioned its engineering teams from Scrum to Kanban. We moved from scrum to address internal frustrations around missed sprint commitments and what felt like constant heroics during the last few days of every sprint to get it over the finish line.
Our release trains felt like small water fall cycles and often required a hardening period that was as long as the development one. We were growing quickly, but both morale and quality were low. Our move to Kanban helped us even out the flow of work, easily reprioritize items, and accurately forecast delivery dates.
And Engineering got faster.
Unfortunately, this is where many of our transformation projects stop. Product was under new pressure to define work faster. There was a visible gap in the time it took to go through the product steering process. By the time new features were identified and defined, engineering had been idle for some time.
On the opposite end of the process, engineering was now deploying features faster and more frequently than before. Marketing couldn’t prepare collateral or gather launch materials with enough lead time so features now piled up waiting to be released. We could see that we had only optimized one part of the system.
We decided to leverage the successes that we had implementing the Kanban method at the team level and expanded to the enterprise level. We defined our value stream from idea to delivery and made all of the work in progress visible. We discussed, documented and tracked our workflow policies. We reduced the amount work in progress to optimize the flow. We did daily stand ups by product line and with the executive team. And we measured EVERYTHING.
What we got surprised us and delighted us. We got the visibility, predictability and flexibility that agile promised us. Here’s how:
VISIBILITY came to us through our Enterprise Kanban board. This board was a physical board that tracked work at the Epic level and was in a high traffic area of the business. The board showed us the status of the work in progress, how long it had left, what was on-deck next, and also which options were discarded.
This provided us with greater accountability and transparency. In this organization (and many others) new feature ideas could be brought to the table by any employee. The ability to see where your idea, suggestion or favorite feature ended up is valuable information even if it never makes it past the commit point.
Everyone had the chance to provide input at the appropriate time and we got rid of decisions being made behind closed doors with an incomplete picture.
PREDICTABILITY is something that is highly desired by every organization and accurately hitting your delivery dates with a Kanban system is easier than you think. It requires a critical change to how most of us work in that it requires you to limit your work in progress (aka WIP). We were able to leverage lead time data at the team and enterprise level to accurately predict when work would move from one phase to the next and ultimately to the customer.
This not only made the customers happy but it also made everyone involved in the process, from discovery to delivery, happier too. The ability to forecast when something would be complete allowed us to plan when to start certain activities so were able to reduce wait time and bottlenecks.
FLEXIBILITY was something that we struggled with through most of my time with this company. We spent so much time making plans about what to make, we didn’t have capacity to actually make them. And when the plans changed were paralyzed by the pain of adjusting plans to pivot to something new.
The demands of businesses, customers, and markets will always change. Our Enterprise Kanban system gave us the ability to weigh our options and continuously adjust our commitments. The ability to be adaptable and change your mind quickly to respond to customers is what true agility looks like.
We were able to get rid of months of planning cycles every year that produced roadmaps that were out of date before they could be published.
Kanban gave us tangible success in our engineering delivery practices but that was only one part of the system. Optimizing one part of any system without regard for the effect on the other components will always result in imbalance. When we were able to step back and see the system as one whole that could benefit from all of the same Kanban principles we were able to be a business that was truly agile from beginning to end. It increased the number of features we delivered to customers, decreased our lead time and allowed us to be more responsive to customer feedback- with happier teams across the whole organization.
For more information, view the webinar on End to End Kanban.