Deliver More, Stress Less with Kanban
•Download as PPTX, PDF•
0 likes•2,536 views
Talk given at Confoo16: Too many teams are working themselves to the bone day after day with no relief in sight. Too often, this unsustainable pace becomes permanent and work continues to pile on top of everything that's already in progress. Julia will share how Kanban helped teams at TBS and F5 Networks deliver more, reduce stress and tame the craziness of the new normal. Learn concepts you can adapt and apply to your context to make the everyday better!
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Deliver More, Stress Less with Kanban
Similar to Deliver More, Stress Less with Kanban (20)
Recently uploaded
Recently uploaded (15)
Deliver More, Stress Less with Kanban
- 1. Deliver More, Stress Less with Kanban Julia Wester Improvement Coach, LeanKit www.leankit.com @everydaykanban everydaykanban.com
- 4. Discovery was the first step @everydaykanban
- 5. Over time, we learn to value starting more than finishing and we get in our own way. The Kanban Method taught me to stop starting, start finishing. @everydaykanban
- 6. @everydaykanban Four Core Principles 1. Start with what you do now 2. Agree to pursue incremental, evolutionary change 3. Respect the current condition 4. Encourage acts of leadership… at all levels
- 7. @everydaykanban Five Habits For Success 1. Visualize the workflow 2. Limit work in progress 3. Manage flow 4. Make process policies explicit 5. Improve collaboratively (using models & the scientific method)
- 9. @everydaykanban 1 Visualize the work – it helps everyone
- 10. @everydaykanban 2 Expedite Intangible Fixed Date Standard Classify work by Cost of Delay
- 11. @everydaykanban How long will it take? Joe has a task that takes one day to complete. Assume he spends all of his time on his tasks, no interruptions. • If he focuses only on that task today when is the earliest he will deliver value? • If he divides his focus between two tasks equally, when is the earliest he would complete one task? • If he divides his focus between five tasks equally, when is the earliest he would complete one task?
- 12. @everydaykanban 3 Constrain work to permit focus AK JW start Focus / commitment end Whether it is a standalone piece of work… or an entire project.
- 13. @everydaykanban 4 Set explicit policies about starting work On Deck Doing Review Done 5 3 3 A A A A A A A A A AA A
- 15. @everydaykanban Specialization and small team size led to a focus on cross- training to remove bottlenecks. JonoHey-sketchplanations.com Commit to Cross-Training5
- 16. @everydaykanban Things we agreed NOT to do
- 18. @everydaykanban Make all work the same size
- 20. @everydaykanban Have time-consuming planning meetings
- 21. At first I was skeptical, but over time I realized that this was the only way to go. I felt like I had a much higher confidence level in what would be delivered, when. And that helped me better set expectations. @everydaykanban Stacie Buckley, Director of Business Operations, NBA.com, Turner Sports (2012)
- 22. @everydaykanban Our team’s journey was incremental, but transformative. The team began to be viewed as a good example for others to model.
- 23. • Start with a problem • Respect the past • Experiment using the scientific method • Learn from any outcome • Start the cycle all over again @everydaykanban
- 24. @everydaykanban
- 25. www.leankit.com Julia Wester | @everydaykanban | everydaykanban.com
Editor's Notes
- Lead in with my story. In 2009, I started in my first management role. I had been at Turner Broadcasting System in Atlanta for 9 years as a web developer and I was going to manage the team that worked on NBA.com – the league had signed a contract with Turner Sports to deliver their website and other digital interests. One thing that I loved as a developer was thinking of what I needed to do as solving code puzzles. I realized that as a manager, I was swapping those code puzzles for people and process puzzles. The first problem that quickly presented itself was our inability to get work completed. When I stepped back to take a look at the problem, I saw a group of dedicated people who were working their butts off, but, unfortunately not finishing anything. On top of that, the business units we worked with, at Turner and the league itself, was losing confidence in the team.
- Fortunately, I didn’t fall into the trap of immediately assume my team members were incompetent or lazy. I didn’t say “we just need buckle down and get it done” or try to bribe people by saying “if we can turn this around and meet this deadline, we will have a team party!” As one of my favorite tweets I’ve ever read said “No one ever says to a road ‘you could fit more cars in if you just worked a little harder!” On the other hand, just hiring more people isn’t always an option so I couldn’t give into the argument of “we just need more people!” As manager, it was definitely my job to figure this out. I could see that the team had significant skill in their area of expertise. So, what was wrong? I took the skills and mindset I had used as a developer to solve programmatic puzzles and applied them to the current situation to find a solution to the team’s inability to deliver.
- We needed to tame the chaos but first we needed to do a bit of discovery. Discovery showed: Business Stakeholder’s Perceptions: Unsure of the status/progress on work that was started. What progress they did see was very slow. Delivery Team’s Reasons were: Too much demand for urgent, late breaking work. High number of emergencies = no flexibility Team is overworked and stressed, not getting anywhere. Constant battle between emergencies, day-to-day/maintenance work and project work. High number of stakeholders that request work so prioritization wasn’t clear. Solicit audience responses on what has prevented you from finishing work.
- My husband also worked at TBS, in the same department, and had some insight into the struggles my team was dealing with. He had heard about this method called Kanban and suggested I read up on it. Looking back, this was a pivotal moment in my career. There’s no magic fairy dust or silver bullets. Instead what I found was a elegantly simple way of facing your reality, surfacing your barriers, and doing small experiments in a way that avoids significant resistance. The biggest light bulb moment was when I realized that organizations have taught us over time with their actions that starting something has significant value, usually more so than finishing things. The kicker is that we know this isn’t right! The most important thing I gleaned from the Kanban Method was how to structure my work to start less at one time and finish more over time. When I learned about Kanban, I thought it would be a good thing to try out on my team because it wasn’t very prescriptive and could overlay onto any existing process. I didn’t have to buy a bunch of crap and get buy in from my whole organization. I could start where I was and go from there. Another reason is that we didn’t have to plan in large time increments and that worked well for our organization because priorities shifted often. So, I’m going to talk a little bit about Kanban as a method and then describe my team’s journey in implementing many of the concepts. So, what is Kanban?
- It starts with four core principles, or ways of thinking. The first three principles were chosen specifically to avoid emotional resistance to change – David J Anderson Start with what you do now. You can overlay Kanban properties on top of your existing workflow or process to bring your issues to light so that you can introduce positive change over time. This makes it very easy to begin a Kanban implementation as you do not have to make sweeping changes. Start where you are. Agree to pursue incremental, evolutionary changes. When you start where you are, you will implement a series of small changes that will build on preceding changes. You may know where you want to be but you won’t yet know the exact steps you’re going to get there. Sweeping changes are discouraged because they generally encounter increased resistance due to fear or uncertainty Respect the current condition. Realize that there may be value in the existing process, roles, responsibilities, & titles. The thing people hate the most is when new people come in and make sweeping changes. It is important to have an understanding of why things are the way they are – what value did they bring. Do they still bring that value or is it time to change them? If you don’t respect the current condition you may alienate people before you really get started. Encourage acts of leadership at all levels. You don’t need to be a team lead or an executive to be a leader. Some of the best leadership comes from everyday acts from people on the front line of their respective teams. Everyone needs to be fostering a mindset of continual improvement (kaizen) to reach your optimal performance as a team/department/company. This can’t be a management level activity.
- While there are no prescriptive actions one must take, David Anderson found that there are five core properties that are consistently observed in successful implementations of the Kanban method (source: DJA – Kanban book). Visualize the workflow. The goal of Kanban is to make positive change to optimize the flow of work through the system. Only after understanding how the workflow currently functions can you aspire to improve it by making the correct adjustments. Making changes before you understand your workflow is putting the proverbial cart before the horse and can cause you to make choices that are, at best, unhelpful and, at worst, harmful Limit Work in Progress (WIP). Work-in-progress at each step in the workflow is limited and new work is “pulled” into the next step when there is available capacity in that step. These constraints, called WIP limits, will quickly illuminate problem areas in your flow so you can identify and resolve them. Limiting WIP is the cornerstone of Kanban because one of the major sources of stalled progress is doing too much at one time. Manage the flow. The whole point of implementing a Kanban system is to create positive change. Before you can create that change you have to know what to change. You figure that out by looking at how value is currently flowing through the system, analyzing problem areas in which value flow is stalled and defining, then implementing, changes. Then, you repeat the cycle to see what effect your changes had on the system. Make process policies explicit Without an explicit understanding of how things work and how work is actually done in your team, any discussion of problems tends to be emotional, anecdotal and subjective (AKA a knee-jerk reaction). When everyone really understands what you are doing now and what your goals are, then you can begin to make decisions regarding change that will move you in a positive direction Improve collaboratively When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus. The Kanban method suggests that a scientific approach is used to implement continuous, incremental and evolutionary changes.
- Every journey is taken one step at a time. And, consistent with what I learned about Kanban, I aimed to make our steps small and evolutionary. I knew I wanted to be better as a team, a delivery organization, but I didn’t map out every step I was going to take to get there. I picked one tangible, achievable step and implemented it. Once I could measure the value of that step, I looked at our new reality and chose the next tangible, achievable step. I’m going to share the high level steps we took in our improvement journey:
- I began using a virtual Kanban board to visualize all of the work flowing through the system just as the blue Kanban book suggested. I didn’t make any other changes such as constraining how much could be in progress at a time. I just made columns showing our workflow and cards represented items of work. I let them be handled as they always had been and started to gather data. How much work was in each step at a time? How many items were in progress for a given person at a time? Now, its not to say that I can’t get this information from reports in a bug tracking system without visualization like this, but having the visualization gives you a deeper level of understanding of that data. Your brain can activate and visually see bulges and bottlenecks in your workflow and when something looks wrong – like Johnny has 15 things going on at one time. I wanted people to be able to see all of the work they had on a single board so they could see the whole of it in one place and better manage it. In addition, we started to provide a more consumable way for people to get status on what was going on, reducing interruptions.
- One of the first problems we started noticing was that we kept getting interrupted by lots of emergencies, but we couldn’t really explain what “lots” meant. So, the first real change we implemented was classifying the team’s work into 4 different classes of service based on cost of delay. Standard was normal. If I did it today, I’d get value tomorrow. Intangible was ongoing work that wasn’t immediately time sensitive, but was necessary to do or would eventually become emergent. Fixed Date work was work that had a significant cost to us if it wasn’t done by a specific date. Expedite work was work whose cost of not doing it (the cost of delay) was MORE than the cost of stopping everything else. This class of work represented the firefighting we were doing. Anyone requesting a piece of work could assign the classification. Not overly policed, but expedites should be questioned and stand up to scrutiny. An overwhelming majority of work should be standard. This is the default class. We were able to show that during on February we had 14 expedite tickets for a team of 8 people. I was able to share that information with our business owners and explain how this was impacting our ability to deliver the items they were waiting on. This type of visibility allows discussions to happen in which solutions can be born.
- Before I get to the next tip I have a brain teaser. I tested this on my 10 year old to make sure it made sense 5 days, 2 days, 1 day. Now, you may think that its not realistic for someone to work on one thing and one thing only. In fact, I’ve found that the workers themselves are the ones that have the biggest problem with narrowing down focus to one thing at a time – not managers or customers. But, you need to realize the value cost to splitting your focus. I’m not even going to call it multi-tasking. We can’t really efficiently do that as humans. It’s a serial process. When you take on more than one commitment, you’re making a judgement call that starting both is worth having both of them take longer. That’s may be fine, as long as you understand the trade-off you’re making and find it acceptable. If you have an emergency and you have to interrupt what you’re doing, its much better, logistically, to stop and focus on that emergency, then pick back up the thing you were previously working on (thus the expedite class of service). If it is truly an expedite, it should be worth stopping other things in flight.
- So, as we saw in the exercise, focus allows us to get things done faster and limiting WIP allows focus. There were three ways I constrained work in progress in the team: 1. I unassign the backlog! Mental overhead is passively stressful. If something is not yet the priority, I don’t want them spending mental capacity on it that should be used for something that is a priority. 2. Next I put WIP limits on relevant steps in the workflow, but I didn’t immediately enforce them. I wanted to start paying attention to the ebb and tide of the work through our flow. Then we started to discuss enforcement of WIP limits which led to prioritization and conversations about slack time. FYI, slack time is not a waste, it’s a valuable way to allow learning, improvement and innovation – all of the things most people say they don’t have time to do. Investing in the future is important and allocating people to 100% capacity is not an effective way to ensure the future looks like you desire it to. 3. I also constrained work at a higher level. Previously we would say Johnny will be 20% focused on day-to-day work and 80% focused on Project X. My observation is that we are bad at realizing how long we work on something and reality never matched the expectation. I also observed that these unrealistic expectations created a lot of stress for the worker who often felt pulled in multiple directions. I strived to get rid of that mental conflict by changing our model. I started with a pool of people who, by default, worked the day-to-day queue. When a project emerged, we created a project team by pulling the people with the needed skills from the pool and had them focus on the project for the duration of the project - with some rare exceptions for extreme specialization. This forced our business partners to understand that there was a limit to how much could realistically be done if we wanted everything to be done well and it forced them to “live within their means/budget” and properly prioritize their requests. This last step was one of the most transformative steps we took.
- We wanted a board that the team could go to and pick up the most important thing to work on without having to attend a status meeting or look at excel spreadsheets. In order to do that, we had to make that visible on our board. So, I established a weekly business prioritization meeting in which I met with the Director of Business Operations. Together we worked to prioritize the next most important things that should be started. We pulled them into an “On Deck” column and stack ranked them so the most important item was on top. This column, we decided, was our line of commitment. When an item entered the On Deck column, that meant we promised to do it, and do it soon. We only pulled enough into the on deck column to make it through to the next meeting. We also established that we could talk in between meetings to add more if needed – or even to make changes in rare situations. The cadence was often enough that we didn’t have to worry about our priorities massively shifting between meetings a majority of the time. I’m not going to say that never happened, but if it happened a lot, it would be an indicator that we needed to plan fewer items more often. Now that we had these policies established we communicated them to the team. Now, the team knew that, when they had capacity, they could pull a card from the top of the On Deck column and be confident that it was the right thing to do. I can hear someone thinking, my team has specialists. Not everyone can do every card! Well, that was true for our team as well. The general rule was, pull the top-most card that you can handle. In a specialist situation, you may need to adjust the WIP in certain columns to allow for your level of specialization. Specialization is not something you can completely avoid. Some people will always be better than others in certain things, but you can try to reduce its impact. That takes us to the next step…
- Commitment to cross-training. A lot of places say that they support learning, but really doing it means management must support the time and materials needed from both the learner and the teacher. We made a team agreement that everyone had to be learning at least one thing. Yes, it did take time from the experts to help cross-train the newbies. But, this effort more than paid for itself rather quickly. Smaller tasks could be handed off to non-experts who might have more availability and allowed our experts to focus on the truly difficult items that were deserving of their expertise. I didn’t know it at the time, but I was working to build T-shaped people.
- T-shaped people are a mix of specialist in one area and generalist in a few. When you put a lot of T-shaped people next to each other, you get quite an overlap in that first level or two of skills in many areas, allowing you to accomplish quite a lot. Only when you get to the really tricky work does an item then have to wait for that one person or two who can do it. Now, if we think back to pulling items from the On Deck column, the number of items that you can “handle” can easily grow. Many times it is better for someone in training on a concept to pick something up and work on it than it is to wait for the expert. They may be able to finish it before the expert would have time to get to it even if it takes them a bit longer and they are solidifying their skills to boot, which has exponential value for the team and the customers you serve – internal or external.
- When taking these steps there were some realizations of how we wanted to act and we came up with some agreements of things we would NOT do. The first was…
- Estimate everything. We didn’t estimate work unless the result would help make a decision. Instead, we started looking at historical data to inform forecasting. But, because priorities changed often we didn’t commit to any dates until the work was started.
- We didn’t worry as much about the size of each card, in that every card did not have to be the same size. This doesn’t mean we don’t want to break down work into small achievable pieces that could be delivered quickly. That’s a good concept regardless of your methodology. But, we didn’t stress and waste time carving items so they fit into the same size boxes. We did measure cycle time of our work and we could look at that cycle time against various filters if we needed to get a granular view of that data.
- We didn’t assign work before it was ready to be started. We thought that doing so would make work take longer and reduce how much cross-training was going on because people would inevitably start on it because its in the back of their mind stressing them out. Better yet, we would avoid doing assignments when at all possible. We would allow the team to pull work when they had time to focus on it and complete it.
- Finally, the team was free to meet about the work whenever they needed but we didn’t have long prioritization and planning meetings with the full team. I replenished the on deck queue weekly with the director of business operations. The team knew that if they pulled the top card, they would be working on the most important thing because we made that policy explicit.
- We took these changes incrementally so people wouldn’t feel too much churn at one time. Some we could have probably done faster but we successfully avoided a lot of change resistance in the path we took. A good measure of success is a quote from a person who was essentially our proxy to the voice of the business. She said {quote}.
- This sentiment started to be heard across our organization. Soon we were looked at as an example to others and I found myself in meetings with other managers explaining how our system worked and giving talks at work to project managers and other groups. I felt that the changes we made allowed us to be realistic about our promises and then execute on them, while keeping a cool head. Its amazing how this, which we like to think everyone does, can really differentiate you from the pack.
- So, that’s my team’s journey. Your journey will look different, but hopefully achieve similar or better results. Here are some things to keep in mind when getting started…
- Look at your environment and judge what’s best. There is no right or wrong way. I started small and I wanted to gauge the impact of each change. Define a problem. All changes should be done for a reason – reaching a goal. If you can’t clearly define the problem, you’re not ready for change. Consider the OODA loop: Orient, observe, decide, act. I like PDCA as well, but it fails to clearly state that before you plan, you need to observe. Don’t confuse activity with progress. Without a goal you’ are blindly flailing around. Occasionally you might hit a good result, but its in spite of what you did, not because of it.