This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.
Extend Agility Beyond the Team with Lean Thinking and the Portfolio Kanban
Has your enterprise agile transformation stalled out? Are your teams excited to be collaborating and building working software, yet frustrated that the rest of the organization doesn’t seem to be cooperating? Well, you’re not alone. Read on to see how Lean thinking and the Portfolio Kanban can help you extend agility beyond the team.
In the 11th annual State of Agile report, the leading impediment to adopting and scaling agile was cited as “Company philosophy or culture at odds with core agile values”. The list of possible “cultural and philosophical” impediments to agile adoption and scaling is a long one. The primary evidence of this conflict, though, is when an organization fails to change the way it operates upstream of the agile development teams. When the development teams are playing by one set of rules, and the rest of the organization is playing by another, the result is lots of mismatched expectations. And even when the teams are getting better and faster locally, they may be building the wrong things, resulting in little value to the business. Many would conclude that such an agile adoption isn’t any better than “the way we used to do it”. If things don’t improve, they may be right.
What’s going on?
There’s no substitute for authentic and active executive leadership for successful agile transformation. But the degree of executive leadership’s passion for enterprise agility varies widely from one organization to the next. Regardless of the level of executive support, there are two issues that need to be addressed for agility to have any chance for success outside of the development teams. They both have to do with how an organization thinks. One is the failure to recognize that value creation begins at the earliest planning conversations – not just when the development teams start working on stories. Project/focused funding and capacity planning tend to perpetuate this error, as it’s easy to focus more on the “what” than the “why” when the budget is being allocated. Closely related is the notion that planning, development, and delivery are discrete domains. Instead of being harmonized into a continuous value stream, they remain a series of start/and/stop “process containers” that are based on different philosophical viewpoints, have different objectives, and are barely aware of each other.
So what can you do?
Effective agile teams are focused on flow, quality, and continuous improvement. Because of this, they’re also continually collaborating and validating that they’re working only on the most valuable things. You want your entire organization to be oriented to value and flow the same way your agile teams are. But it may not possible to get everybody in your company to attend training in hopes that the collective light bulb will come on. You can take an incremental approach to enterprise agility, though, by extending Lean concepts and practices outward from the teams. A tool you can use for that is a Kanban system.
A value stream is comprised of all the steps your organization takes to envision, create, and deliver value to your customers. A Kanban system is simply a “pull” system that enables a value stream to realize high throughput at high quality: High throughput, because the amount of work in process (WIP) is limited, and high quality because nothing moves to the next step until it is defect/free. A Kanban system can also be a powerful and non/threatening instrument for spreading Lean thinking throughout your organization. A Kanban system begins with understanding and mapping an existing process. In this case, we’re not too concerned with mapping out a “to/be” process. We just want to be very clear about what we’re doing, and then use the Kanban system to manage it. We use the feedback from the ongoing system to continually improve the system, addressing questions like:
“Where are the bottlenecks?” “Why does that step take so long?” “How can we fix that?” “Do we even need that step?”
The system doesn’t have to be “agilized” first. This can be a critical difference maker in getting buy/in to setting this system up and have people pay attention to it. There’s probably already a process in place for moving epics, for example, through steps like discovery, approval, etc. All you’re trying to do at the outset is understand a process so that it can be mapped and visually managed.
How does this affect the culture?
We’re all smart people, and it’s my experience that people will make good decisions when they know the truth and they aren’t coerced. One phenomenon I’ve observed is that people who passionately oppose something frequently become the most passionate proponents of that very same thing, as long there’s an atmosphere of trust and they’re allowed to make their own discoveries. This is a “do, then teach” approach. The real power comes in making sure that people understand what the board is showing. As the existing process plays out on a Kanban board, people will start talking and connecting the dots. For example, when a bottleneck becomes apparent at some process step, people will start to ask questions and propose solutions. The first solution chosen might not resolve the bottleneck, or it may just shift the bottleneck to another step. That’s OK because improvement is a continuous pursuit. People known for adamantly insisting that “everything is top priority” will see for themselves that prioritization isn’t optional. And it might become apparent that what had been called “epics” are, in fact, just traditional all/or/nothing projects by another name. In this way, a cultural change will have begun simply by exposing what’s really happening, and the impact that it is having on the business of delivering value to customers. You’ll have the opportunity to introduce concepts to lean out the workflow, like limiting work in process and to demonstrate the value of having policies for ensuring that you’re not passing latent problems down the line. You’ll attract fellow champions along the way. And when you have documented “before and after” measures of things like defect rates and cycle times, you’ll have a story that executives will want to hear. You’ll have moved the needle on creating a common culture that’s necessary for long/term agility across your enterprise.
Just the start
What I’m talking about here is introducing a Kanban system to help your program or product teams manage the flow of higher/level initiatives (epics, features) for higher throughput and higher quality. That will affect not only that particular Kanban system; it will directly affect the lead time and quality of the whole value stream. After all, the flow of value through a unified value stream is the overarching goal here. This is simply an incremental approach to reaching that goal. As flow of value becomes the guiding principle that underlies the relationship between the programs and teams, that principle and its accompanying practices can be extended further outward toward the origin of the value stream.
VersionOne Lifecycle Portfolio Kanban
If you’re using VersionOne Lifecycle Ultimate Edition, the Portfolio Kanban is there to help you visualize and manage a Kanban system. You can set up a Portfolio Kanban at any level you’ve defined (portfolio, program, product, etc.). In the Kanban, then, you can visualize and manage the flow of your portfolio items, whether epics, features, or any custom type your organization may use. Remember that portfolio items represent value – not simply “planned work”. You can filter the Portfolio Kanban board, and customize WIP limits, swim lanes, and policies. These help to enhance visibility, avoid bottlenecks, and ensure that everyone understands what needs to be done before moving a portfolio item to the next step. The cards on the board can also be customized so that the attributes that are most important to your organization are visible at a glance. By clicking on a portfolio item on the board, you have access to a specific portfolio item’s details, history, dependencies, and related items. You can also access the dashboard and scorecard that applies to that portfolio item. PlanningRooms allow you to display a Portfolio Kanban in the context of other views that help with solid decision making. Common PlanningRoom configurations include a Portfolio Kanban beside the Tree View of those Portfolio Items and side/by/side kanbans that are related to each other. The PlanningRoom below has been configured to show the Portfolio Kanban for a product, and the “downstream” Kanban for a specific release of that product.
Where to from here?
Cultural and philosophical alignment must exist for sustained agility across an enterprise, and influencing organizational culture is no small task. A Kanban system managed in a Portfolio Kanban is a powerful tool that can help introduce and broaden a Lean culture for extending agility beyond the development team. You can learn more about the Portfolio Kanban in VersionOne Lifecycle. I realize that I didn’t talk about the flow relationship between Development and Delivery here. That’s the essence of DevOps, and yes, it is absolutely part of the “unified value stream”. Here’s a helpful blog post on how VersionOne enables whole/value/stream flow with integrated agile & DevOps. And if you’d like some assistance with your agile transformation, our experienced coaches can help.