This talk continues to be one of my favorites to give and I just keep getting the chance to present it. I will continue to submit it because it’s just a fun one. The Slides have been uploaded to SlideShare and my notes are mostly included here.
I’m happy to further the discussions about Kanban if you want to reach out to me on twitter (there’s link to my twitter profile at the bottom of the page).
Here are all the links to the items I discussed in the presentation:
- The Phoenix Project – this is the book that initially kicked off the original Kanban processes that our team started using to stop fighting fires and start solving problems.
- The DevOps Handbook
- Lean Enterprise – this is the one that pushed me to create this deck and presentation. It really changed my worldview on how to start making my team more efficient.
- Continuous Delivery
And the other blogs/links:
Slide notes posted below.
Thanks again to everyone who attended!
- A Kanban board. Most people with Agile or Scrum experience of any kind are going to recognize the basic concept of what a board is with sticky notes attached to it. Each note represents a corresponding issue. But a true Kanban process can be so much more than just tracking a handful of issues. Exercises around prioritization, planning, and execution can make a huge difference in how useful this board becomes to your team.
- Using the techniques and processes we’ll go over today, I’m going to show you how a team of 7 Technology Operations Engineers (including myself in this list) doubled the resolved ticket output. I’ll also go over what we have to continually work on to maintain that productivity, and the steps we’re taking to improve what we do even more.
- Why? Because VML isn’t a product company, we’re a client services company. Which means every client can potentially their own tech teams and backgrounds to the table.
- I aged 30 years in like 5 years at the company before we started doing things the right way.
Site Reliability efforts, New project builds, maintenance efforts, migration work, it all came in, and many overlapped for various periods of time. As we took on each new project that grew in scale and complexity, it felt like joining a new startup every 6 months within the organization. The TechOps team I’m on has grown from 6 to 20 in North America in 7-8 years, of which I’m responsible for managing myself and 6 engineers.
- Open office plan is synonymous for “constant interruption”. As a technologist, work requires chunks of time to complete work. As a manager, dealing with the interruptible is crucial. I have to find a balance with all the above considerations.
- Philosophy and description of the mechanics of a rescue attempt doesn’t interest a person in a burning building, they just want out.
People don’t ask for the background, credentials, methodologies of the firefighters and ask for an explanation of what and how they’re going to do it when their house is on fire. But they also might get mad afterwards when a fireman breaks down their door with an ax. It’s the fact that their house was burning that made them mad.
We could figure out the best plan, but we needed a firehose or a ladder to help us and organization get out.
Around 2013, I started following professional technologists on twitter, reading technology books every week, and learning about processes and ways to work in a fast-paced environment. My direct supervisor has a Masters and a philosophy background, so we talk and process through each of our major bottlenecks.
- “The Phoenix Project” while helpful for a future state road map, most immediately introduced to us to one particular practical solution, Kanban
I know, it’s got a bazillion definitions and it’s either the bane of existence or the savior of all mankind. DevOps was just a buzzword that turned into an industry term. Jez Humble, Gene Kim, et. Al. created a movement, a philosophy, but that didn’t help us solve our immediate issue.
- Anybody can look these items up for sure. But know that these methods are highly based in a scientific rigor requiring constant self-evaluation and continuous improvement.
- In order to see the sum total of work in the backlog, in process, and completed, it’s important to actually “SEE” this work. Our brains are excellent at pulling patterns from visual cues.
- Our first Kanban board, where we had standup every day. This was critical to understanding the current work state in the system and how the work flowed through the system.
What did we visualize here? People were going to their “favorite” engineers directly whenever they wanted something done, thus piling up the tickets on their backlog.
- Visualization helps with identifying column constraints, and what potential WIP limits should be. Which gets me to my next point.
- In Kanban methods, often times, nothing else is as important as the work you are doing right now. And when you have two people, and two stacks of cards, it makes sense for your WIP to be right around 2 instead of 1.
- By visualizing things like “buffer time” between teams, backlogs start to become apparent and can be identified as opportunities for improvement. Any time spent on any effort that isn’t the bottleneck is a wasted effort. The best efforts for improvement should be spent on areas identified as the next major problem. But in order to justify that, sometimes you need a pretty chart to show to upper middle management (and honestly, lower middle management like myself included in there).
- It’s important to recognize when new constraints are injected into the system, and how to quickly identify them, and adjust accordingly. The constraint of bad weather was not anticipated and the outset of their planning, but they recognized, adjusted (and after some freaking out), still made their goal with the same resources as they had in place before the changes.
- I know that Kanban is designed to deal with a great quantity of unknown work, but that doesn’t mean that you should stop resourcing and forecasting activities. Prepare for the natural ebbs and flows that come with unplanned work.
- There’s an overhead associated with switching tasks, which is why the focus on completion is so important. Just like travel time between two tasks can eat into the time meant to complete the work, switching between two complex mental tasks can mean 15-20 minutes of effort just to get in the correct mindset. If you switch to 1 new task every hour in your job, you could be spending 2 hours every day just ramping your mind up to the next task at hand. And goodness forbid if you have 16-20 tasks in a day, half of your time would be spent dealing with context switching overhead.
- If it’s good enough for the American Psychological Association, it’s good enough for me.
- That’s right, it’s literally making us dumber.
- Sandwiches are important. What else is important (especially to the people you work for)? Lettuce. The green stuff. Money. And prioritization should take into consideration things like how much revenue certain tasks bring to the table and prioritize those. For instance, let’s say I have 3 clients. 1 is forecasted to reserve 3 people, 1 is forecasted to reserve 1 person, and 1 is forecasted to reserve 0.5 of an engineer. Guess which one gets priority? It doesn’t matter if the work is less interesting or not bleeding edge, exciting stuff. It still has to get done. So you have to deliver value.
- I know, money, right. There are some real tangible impacts to choosing the “wrong” thing to work on. Since Kanban is so focused on the completion of work, if you’ve started and subsequently spent your time working on a particular issue, you are essentially betting with your time/money (salary) with the decisions you make to work on something. Cost of Delay helps us assign monetary or financial impact value to tasks.
- Task A for example might be a regulatory issue that may cost 250k per week it’s not implemented, but it takes multiple resources multiple weeks to completed
Task B might be a new feature that would prevent collecting of 100k every week it’s not released, but it takes one resource just 1 week to finish it
When you split that resource across two tasks and it doubles the amount of time to complete task B, you end up costing extra when it would have cheaper either way picking one and starting it. So when you bet your paycheck, it’s better to go all in on something when choosing at get it done. Better to have 1 person/team/group mad as opposed to all of them.
Yeah, trying to do both things at once, cost the most amount of money because it delayed the completion of both tasks, and there were penalties associated with not completing each task in a time frame.
- Start today, right now, using whatever methods you can
Physical cards/post-its, a wall/whiteboard
Many other COTS products
Sources: http://kanbanblog.com/explained/GettingStarted.html and http://www.everydaykanban.com/what-is-kanban/
- You need to write it down, draw it out – where work comes from, how it goes through the system, and when it’s “complete” or out of your systems.
- When we first started making these changes, people got kind of upset – we had one guy ask why his ticket was sitting in unassigned status for so long when it had previously been assigned to someone. When I said “it’s basically a lie that as soon as a ticket comes in, someone starts working on it right away”. Whereas previously it would sit and fest when assigned to someone, and the person creating the ticket would get mad at that individual, now we call out “this is not being worked on until something else is done, someone becomes available, or you can convince me or another ticket holder that your work is more important”
- I’d recommend writing out your process and display it in person in your office if you need to, or even just making sure it’s in a documentation repository where as many people as possible can see it. For example, on our team page, there’s an area specifically dedicated to “how we work” that went over the prioritization mechanism.
- If there’s not a formal mechanism by which to educate on the processes and training people around you, make sure you build time into your other regular routines to support it.
- Remembers the kitten poster and eagle poster. FIND OUT WHERE THE BOTTLENECKS ARE. If you’re getting yelled at by your boss, figure out what their expectations are and what’s not being met. Try to explain how finishing nothing is not as good as finishing any single thing and moving onto the next item to work to completion.
- You’ve got to be able to measure the progress you’re making somehow, it doesn’t have to be ticket output, but something that is measurable. Then you can make the necessary adjustments to continually improve.
- All this to reap the spoils of your hard work done right.
- George Buys a Kite/Train of Light
Conferences presented at:
- Nebraska.Code 2017 (WORKSHOP)
- Detroit.Code 2017 (Session)
- Prairie.Code 2017 (WORKSHOP + Session)
- Scenic City Summit 2018
- NDC Minnesota 2019