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.
- I’ve had a handful of IT jobs moving from desktop support specialist, to dial up internet employee, to WISP network engineer, to doing traditional ITIL in a Financial Services company. I landed at VML over 7 years ago thinking a year or so of contract work at a Digital Marketing Agency would lead me (somewhere else) to some interesting and stable technology work at a quote unquote real technology focused company (my thought were geared towards the sort of big 3 in KC being Garmin, Cerner, Sprint).
- 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.
- So yeah, this turned into the interesting and stable job I was looking for, but as will soon become apparent, it was a road less travelled. 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. My TechOps team has grown from 6 to 20 in North America in 6 years, of which I’m responsible for managing myself and 6 engineers.
- 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 have logged into every platform on the command line (or RDP) listed here in my time at VML. Even if for 1 day, the members of Technology are often asked to become the insta-experts.
- 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.
- 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.
- 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.
- So let’s talk about Kanban now. It’s what we all came for. But allow me do an intro to it in an interesting way.
- This is my 5 year old son, Eli. He LOVES Curious George. It is the most tolerable children’s show for an adult to follow along. One particular episode exploded my brain. It will take 10 or 11 minutes or so, and I think it’s worth all of us watching for reasons which will become apparent soon. Roll it.
- This is all just what it looks like Wikipedia throws up on your screen. 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.
- 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.
- I look at this quote every day. Seriously. It should go on an inspirational poster like with an eagle flying over a mountain or a kitten hanging on for dear life.
- The visualization helps with flow focus as well. It’s easy to see that things would be simpler by following a geographic pattern instead of a 1st come 1st serve, since the completion date expectation were the same for all tasks that Bill and George’s excellent job service had.
- 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.
- 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.
- The biggest difference between a list of issues and a process such as Kanban is how they’re planned for and visually organized. Lists often imply order, but really, the order does not matter if you’re doing things in a list. They’re arbitrarily organized. For instance, look at writing out your grocery list. Imaging you just wrote down everything and just went in that order throughout the store. But then one day you decided to order them by aisle location in incrementing order. Imagine the time savings.
- 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