Scrum Agile Project Management

End to End Kanban for the Whole Organization

If shorter release cycle could be considered as a success for Agile software development teams, they might be considered as an issue if the other parts of the organization are not ready to handle this. In this article, Colleen Johnson shares an experience where the successes achieved implementing the Kanban method at the team level were leveraged to expand them to the enterprise level.

Author: Colleen Johnson, ImagineX Consulting, http://imaginexconsulting.com/

As a community, when we talk about applying agile practices, engineering is typically where we start. Engineering is often viewed as the bottle neck 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.

End to End Kanban for the Whole Organization

What 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 and 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 not only showed us the status of work in progress, how long it had left and what was on-deck next but also showed us what 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.

About the Author

Colleen Johnson is the Practice Director of Adaptive Agile at ImagineX Consulting. Colleen applies a systems thinking approach to aligning agile methodologies across the enterprise and works with clients to apply the right cultural and context-driven practices to create sustainable agility. She is an expert in Lean/Kanban methods of software delivery and advocates for LeanStartup principles using scientific methods of customer-centered discovery.

She is active in the agile community locally as a member of Agile Denver Board of Directors and Chairwoman of the 2016 & 2017 Mile High Agile Conference and nationally as a member of the Agile Uprising Board of Directors.  She is the co-founder of ScatterSpoke.com, a free tool for more effective team retrospectives. In her free time, she enjoys running and yoga as well as camping and hiking with her two kids.