Download to read offline
Uploaded byJulia Wester
Taming the Chaos: Beyond the Quick Wins
The document discusses the limitations of shallow Kanban implementations, identifying key indicators of this state and emphasizing the need for continuous improvement and teamwork. It provides strategies for deeper engagement, such as building cross-team relationships, focusing on customer value flow, and instituting regular feedback mechanisms. The author encourages tracking progress and offers resources for further exploration of Kanban practices.
Taming the Chaos: Beyond the Quick Wins
- 1. @everydaykanban Taming the Chaos: Beyondthe Quick Wins Julia Wester Consultant at LeanKit @everydaykanban
- 2.
- 3.
- 4. ARE YOU INTHE SHALLOWS? Four indicators of a shallow kanban implementation @everydaykanban
- 5. @everydaykanban You have aview of reality, even if scary1
- 6. @everydaykanban Focus is onindividuals, isolated teams2
- 7. @everydaykanban WIP Limits, if theyexist, are to relieve overburdening 3
- 8. @everydaykanban No Focus onContinuous Improvement4
- 9. @everydaykanban Key: Don’t stopmoving forward
- 10.
- 11. ENTERING THE DEEP Tips fordiving deeper to discover hidden business value @everydaykanban
- 12. Think like asystem, not an isolated team @everydaykanban
- 13. @everydaykanban 1 Build Relationshipswith Other Teams
- 14.
- 15. @everydaykanban Ensure Metrics Fosterthe Right Stuff3
- 16. @everydaykanban Focus on flowof customer value
- 17. @everydaykanban Optimize the Boardfor Teamwork1
- 18. @everydaykanban Use “Pull” toManage Flow2
- 19. @everydaykanban Limit WIP toFind Problems3
- 20.
- 21.
- 22. @everydaykanban Make Feedback aHabit via Cadences1 Every day Every 1-2 weeks Every month
- 23. @everydaykanban Cast a WideFeedback Net2
- 24. @everydaykanban Rub A LittleScience On It3
- 25.
- 26.
- 27. @everydaykanban E-mail julia@leankit.com with Subject:Kanban to get: • This awesome slide deck! • A Kanban roadmap e-book to help you dive into the deep
- 28.
Editor's Notes
- #3 Once upon a time there was a team. The team already used visualization and WIP limits, but the WIP limits weren't based on any math. They were just guesses based on what that team could accomplish (not any of the teams they depended on). They knew things were getting stopped up at one point in the process, but they didn't know what to do about it besides yell at the other two teams involved. This team was wading in the shallows of Kanban and process improvement. First, let me clarify that taking small, evolutionary steps towards a goal is something Lean coaches counsel people to do all the time. Sometimes the best (and maybe even only) way too get started is to implement a very thin layer of something good.
- #4 In certain cases, trying to make too big of a change to your current process - like implementing a full-fledged, deep kanban implementation - could cause you to crash and burn in what I call “the pit of despair.” (show pic of J-Curve) No one wants that to happen. “This would have denied these businesses significant improvements and the workforce genuine relief from challenging circumstances.” (http://www.djaa.com/tolerance-3-are-we-doing-kanban-or-not)
- #5 So, we know shallow kanban implementations happens, and we know they are not necessarily bad. But, what exactly is a shallow kanban implementation comprised of? There are 4 indicators you often see…
- #6 The first characteristic is that you have a visualization of your work. That deserves congratulations! You are probably already experiencing some level of improved conditions like less status reporting and being able to show the board to support challenging conversations. The key is that this is the first time you can really see the magnitude of your entire work demand. It may not be a pretty picture, but it shows reality.
- #7 The second characteristic relates to scope: The work being visualized on your Kanban board is that of an individual person or that of an individual team. If you are one of the few orgs that visualizes work across multiple teams early on, there isn’t a focus on improving how to work across team lines. You’re still trying to get your own team’s house in order first.
- #8 The third characteristic concerns WIP limits. WIP stands for work-in-process. IF you limit WIP in a shallow implementation, it usually serves to provide relief from overburdening individual people rather than to foster any deeper flow of work through your system.
- #9 The fourth and final characteristic is that we often have abandoned feedback. We say we seek out feedback, but that search rarely translates into actionable outcomes. Occasional improvements do happen, of course, but there is no continual focus.
- #10 If you’re in a shallow implementation, don’t dismay! The key is to ensure that you don’t let stagnation set in. There’s this concept called entropy that really helps us understand the insidious nature of the status quo. Entropy says that everything is in a constant state of decay. This means there’s no standing still. You have to work to stay in place. Improvement isn’t free. Its not something someone does for you. It’s not a management-only activity. If you want better outcomes, you have to work to make it happen. Not once, but over and over and over again. You can never be complacent. That’s why we’re here today… to give you ideas for taking those next leaps forward.
- #11 Let’s check in on our team in the story. When we last left, they needed to find their way past the current conflicts to get to deeper understanding of their process and why their results weren’t as stellar as they really wanted. After a lot of frustration, the conversation started to right itself when the folks doing the queue replenishment asked what the bottleneck was in the process and what it’s throughput was. Then they asked if there were any apps or services that didn't have to go through that step. Once armed with this deeper information, they ended up limiting the number of items in the system that would EVER have to go through that step, but they allowed in a few more of the other types of work items. Essentially they were subordinating everything to the bottleneck. You could have said their decision filter (explain) was “will this worsen the bottleneck?” Now they were starting to think about FLOW! They were finding their way to deeper Kanban waters.
- #12 Fortunately you’re here and can learn from experiences of teams like the one in our story. You can avoid at least some of the frustrations previous teams have gone through by embracing some core Lean/Kanban concepts. So, I want to take the rest of the time to introduce three key concepts and give you some tangible steps for each that you can take to make progress towards achieving the elusive results you’re looking for.
- #13 Key concept #1 is: Think like a system rather than an isolated team. You’re here because you know about, or are at least intrigued by, DevOps. This movement is an exercise in beginning to think like a system. Why is that important … Here are some tips to get started:
- #14 Identify which teams impacts your team’s ability to get work done & vice versa. (DevOps itself was born by an exercise in realizing that Dev and Ops impacted each other. Start there but keep widening your view. Who else impacts each other? How do you impact each other?) One of the most important things to do is to build strong, reciprocal relationships with teams you rely on and those that rely on you. The easiest place to start may be to find the teams who need things from you and ask how you can best help... then progress to the ones you need things from. Your street cred from dealing with the teams who need something from you will hopefully provide some social capital you can spend with the teams you need something from! Send team ambassadors to each other’s team meetings or standups. Figure out what each can do to visualize emerging issues and best manage dependencies.
- #15 Visualize key cross-team information like: Handoffs of work from one team to another Information about work items that can give downstream teams a heads up on potential issues that are coming their way.
- #16 Check your metrics to ensure what you’re measured by doesn’t drive you to take actions that help you, but hurt others.
- #17 The next core concept is to focus on the flow of CUSTOMER VALUE. Initially, Kanban helps relieve overburdening for the people through visualization and some basic WIP limits. So, now you may feel like you can breathe and consider what’s next. What’s next is to shift focus away from teams or team members to a focus on flow of work through your system. (Ideally valuable work - but that’s a whole ‘nother talk!) Here’s a question to put you in the right frame of mind for embracing flow: Do you think it's more important to always be busy or to finish important things? Pro tip: The latter is usually the right answer :) Where we get into trouble is thinking that ensuring everyone is super busy will result in the speedy delivery we’re looking for. Unfortunately, that’s wrong almost all the time in our lines of work. So, let’s change how we visualize our work to encourage focus on the right thing -- smooth, quick journey for a piece of valuable/important work from start to finish.
- #18 Update your visualization to focus on the work, not the people. What does this mean specifically? Some examples: Move away from any lanes or columns named by person. Focus on what happens to the work instead. (show side by side: before and after) Card types (or colors of cards) represent an aspect of the work - category of work, risk factor, etc. The next thing we have a tendency to do is focus on how to improve the active time we spend on a piece of work. However, data shows that, before there’s a focus on flow, most of the time in the lifecycle of a piece of work is spent in a waiting state, not an active working state. So, next steps would be to: Implementing a pull system and stop pushing work down the line In essence, we want to stop pushing work onto people’s laps when they’re not ready to take it. One of the most telling things about depth of kanban maturity is if you have a full-fledged, end-to-end pull system. Begin to implement a pull system by adding buffers for managing flow and signaling pull That means we need to limit what we start! Starting work isn’t necessarily the best use of our time if there’s no one there to receive it: Add WIP limits to constrain how much work gets started If you don’t have any WIP limits, start! WIP limits make us focus so that we finish what we start. If we start too much, we are constantly moving between multiple pieces of work, making each take much longer. That’s exactly the opposite of what we said we usually want! Sometimes constraints, like WIP, are our friend. If you have per-person WIP limits, start limiting work for the overall “Doing” section of the board. How much can the whole team have in progress at one time? You don’t have to start out knowing how much work should be in each workflow step at one time, but at least start by limiting how much can be in progress in total. Choose a limit that you will hit sometimes, but not all the time. If you never hit your WIP limit, it’s not doing its job to encourage you to improve If you always hit your WIP limit you’re likely to either start ignoring them or remove them completely.
- #19 The next thing we have a tendency to do is focus on how to improve the active time we spend on a piece of work. However, data shows that, before there’s a focus on flow, most of the time in the lifecycle of a piece of work is spent in a waiting state, not an active working state. So, next steps would be to: Implementing a pull system and stop pushing work down the line In essence, we want to stop pushing work onto people’s laps when they’re not ready to take it. One of the most telling things about depth of kanban maturity is if you have a full-fledged, end-to-end pull system. Begin to implement a pull system by adding buffers for managing flow and signaling pull Go ahead and define create policies for how you will handle emergencies before you have the emergency! These may override normal process and operate differently.
- #20 That means we need to limit what we start! If you don’t have any WIP limits, start! WIP limits make us focus so that we finish what we start. If we start too much, we are constantly moving between multiple pieces of work, making each take much longer. That’s exactly the opposite of what we said we usually want! Sometimes constraints, like WIP, are our friend. If you have per-person WIP limits, start limiting work for the overall “Doing” section of the board. How much can the whole team have in progress at one time? You don’t have to start out knowing how much work should be in each workflow step at one time, but at least start by limiting how much can be in progress in total. Choose a limit that you will hit sometimes, but not all the time. If you never hit your WIP limit, it’s not doing its job to encourage you to improve If you always hit your WIP limit you’re likely to either start ignoring them or remove them completely.
- #22 Constantly assessing and improving conditions to enable better flow
- #23 Establish a habit of improving using cadences. This helps ensure the continual part. Specific feedback events to hold on a consistent cadence: Kanban Standups (multiple times per week, if not daily) goal is to move work to the right Invite people from upstream and downstream teams Retrospectives (bi-weekly as a cadence, can do adhoc if a big problem emerges) goal is to determine most impactful impediments and design experiments Don’t forget to consider feedback from other teams when designing experiments. Ops Reviews (monthly): goal is to reflect on the past month as well as trends over time. Key metrics (speed to complete work; # and pattern of unexpected problems; etc.) How you improved the flow of value for the organization since the last review. (small or large. Inside your team or the cross-team impacts).
- #24 Get input from all as many people as possible Don’t just have the team talk together, solicit feedback from everyone impacted by the team. Teams that are dependent on your work, teams that asked for the work, actual customers outside of the organization. Spread a wide net.
- #25 Stay focused on outcomes Don’t let feedback fall into a black hole. Participating in any type of feedback loop should feel useful. Ask yourself often if your feedback mechanisms are just there to tick a box or if they are actually providing value to both those giving feedback and those receiving it. To ensure it provides value, feedback sessions should be facilitated to ensure the focus is on actionable outcomes. One of my favorite tips from an agile coach was that the end result of each retrospective should be an experiment. As gratifying as it might feel in the moment, just venting doesn’t provide long-term value. It can actually worsen morale. It doesn’t have to be large, but if you don’t end with an idea of some kind of better way to move forward, and an idea of how it will be implemented (or a mandate to design the experiment), what was the result of your feedback session? Promote everyone to the status of “flow scientist.” Everyone is responsible for continuous improvement. It is not a management activity!
- #26 2 min
- #27 3 min
- #28 1 min