2020 Update: How to use Kanban to "Lean" into IT infrastructure projects and operations

This is the rather long story of my journey with lean concepts and specifically Kanban-based methods in my IT infrastructure leadership career over the past several years. Part 1 talks about how I got started while working in an IT consulting shop. Part 2 goes into how I transferred my experience into a corporate IT leadership role and what I found there. Finally, Part 3 will discuss my third Kanban launch, this time in local government -- that part is being written and updated in near-real-time during 2020.

PART 1: The Consulting Shop

In February 2015 I started a job as the a IT Practice Director in a classic Managed Services Provider (MSP) in Columbus, Ohio. We served small/medium businesses in the region with everything from complete IT outsourcing to on-demand IT infrastructure projects. A big part of the job was leading a team of engineers as they designed, planned, and delivered IT infrastructure projects. And like most businesses in America (by number), we were small -- maybe 30 people across the whole company. We didn't have limitless employees, so we couldn't afford to create highly-specialized positions -- we all had to wear a lot of hats. For example, it wasn't reasonable for us to employ a full-time Project Manager. We could definitely have used that kind of help, but we couldn't justify the salary and, truthfully, we couldn't have kept such a person fully engaged or grow their professional skills. Plus, the extra workload from running our projects in a PMP-based manner would have increased the cost of our projects, which would have irritated our clients.

Despite lacking a formal PM, we did IT projects all the time. We migrated clients to Office 365 or other cloud systems. We upgraded servers, storage, virtualization platforms, and networks. We collaborated with outside firms, such as cabling specialists and data center providers. More importantly, we often did all those project types simultaneously and for multiple clients. In effect, we had our own little PMO (Project Management Office), but there wasn't a PM calling the shots -- just me and some IT engineers.

As you might imagine, it wasn't easy.

The Problems

When you have 20+ sizable projects going simultaneously, usually for 20+ clients, simply keeping track of what's done, not done, and coming up next at a high level can make you crazy, even if you skip tracking sub-tasks, projected hours, budgets, shifting priorities, and the heterogeneous skills of the engineers. But most importantly, we wanted to complete our projects so we could... you know... get paid.

Given our situation, we needed a way to solve the following problems:

• Know what projects (1) are being designed and sold, (2) are starting, (3) are in progress, and (4) are closing or were recently closed, and see all the projects, project phases, clients, and engineers in a unified workflow
• See where we have resource conflicts so we can design around those situations, but not constrain ourselves to the point where we create gridlock and can't adjust timelines as priorities shift
• Display all our work in a visual way that non-engineers can grasp, so we can have meaningful discussions about our work rather than spend most of our time just trying to explain what's going on to people outside the engineering team
• Utilize a system biased toward project closure and completion, not sales or project starts (it's easy to start a project; it's not easy to finish one)
• Keep our project management work to a minimum, to save us time and save clients money

We didn't arrive at our solution quickly. We went through a few phases along the way, and perhaps what we learned can help your team...

Classic Project Management Solutions (that didn't work)

To get started with our "lite" project management approach, I turned to everyone's favorite sortable-text-in-a-grid solution: Microsoft Excel. It's a great place to get started because you can list everything you're doing and create more and more cells with various data fields you want to track with each row of data. With automated formatting, you can even color cells and text depending on the contents, making the whole thing easier to grok at a glance.

This went along fine for several revisions and a few months. At one point it jumped from Excel to Google Sheets (to make it shareable and simultaneously editable by the whole team). But the job of maintaining it almost always fell to me. So the more detail we added, the harder it was to maintain.

During this period I also tried using a cloud-hosted project management tool I'd used a few times in the past (and still use intermittently today): Smartsheet. These cloud-hosted and shareable spreadsheets / project management docs can be simple or complex, private or shared, and it has nice Gantt-style visualizations with dependencies between tasks. It's Microsoft Project for a fraction of the cost and with a lot more collaborative capabilities.

I ended up using Smartsheet on a big multi-phased project that was hard to manage, but for tracking all our projects it was even harder to manage than Excel. I liked it, but this was a tool that needed at least a part-time PM, and we just didn't have that available.

By the fall of 2015, project work was picking up and the need to track our tasks individually and as a team was getting urgent. Excel had failed. Smartsheet had failed. Asana didn't take off, either. And Basecamp, while useful for a lot of collaborative work (and I love it dearly to this day for the right situations), just wasn't designed for multi-project organization and visualization. We were getting bogged down with resource conflicts. Project delivery was slowing as the load went up. I needed a new tool, but more importantly, I needed some new methods.

Agile... Scrum... Sprints... Lean...

As an avid reader of IT industry blogs and news, I was well aware of the popularity of current software development methods and buzzwords like Agile and Scrum. I had even introduced the idea of "sprints" during 2015, but lacking other methods, and because our projects were infrastructure-focused rather than software-based, it just didn't take hold. Meanwhile, the literature in the field on these new models was focused almost exclusively on software development -- which didn't speak to our problems very well.

I started looking around for books on project management using new Agile-ish methods, especially in IT infrastructure contexts. I found some books on Amazon, then turned to my Safari Bookshelf subscription to review some of the best examples in detail. That's when I found The Phoenix Project.

While Phoenix was not a how-to book, I found it a cracking-good read. It's a (nerdy) novel telling the story of how a DevOps model of work was brought into a fictional corporation's IT department, and how that transformed (and saved) the business. It rang true to my career experience and it thematically addressed the problems we were experiencing.

Welcome to Kanban

Featured at the center of Phoenix was the application of Kanban, a decades-old Japanese manufacturing operations model, and the theory of constraints. These mental and operational models revitalized the fictional company's IT function, which was mired in competing demands and resource conflicts. I knew I needed to take this to the next step: learn more about Kanban and try out some tools.

I downloaded a few more books via Safari and looked them over, but the turning point was finding a succinct how-to manual from LeanKit (now a part of Planview) called the Kanban Roadmap." This Roadmap explained how to get Kanban started with your team in simple, direct terms, including terminology, processes, etc. With the "Roadmap" in hand, I ordered lots of Post-It notes, a big whiteboard, and spent several hours creating project/task sticky notes from our projects spreadsheet, just transferring each line item onto the sticky notes.

Our very first Kanban board looked like this:

The new board mapped out our project steps from left to right, covering all our major phases:

1. Sales opportunities (once they exited from Microsoft Dynamics CRM)
2. Sales engineering and proposal development
3. Sales completion
4. Project preparation, setup, scheduling
5. Project delivery: Work in Process (WIP)
6. Project wrap-up and closure

Each sticky note was a project for a client. Colors designated project types. Flags were attached to projects when an engineer was assigned.

We then proceeded to hold weekly stand-up meetings at the board and track project movement, discuss roadblocks, rearrange sticky notes as needed, and more. We did not use the daily stand-up recommended for software teams, mostly because the engineers weren't consistently in the office and it felt like too much of a commitment.

Stuff We Learned

Visualizing all the work and making it "public" in the company was a wild ride at first, and we learned things about our unwritten processes:

• It became clear Sales and Engineering didn't see eye-to-eye when it came to whether something was "sold" or not. We also didn't always agree on when developing a formal quote was necessary. After a lot of conversation, we set new standards for each phase of the sales process, and that sped up sales qualification and our quoting. Simply visualizing the steps in the process forced us to qualify what each process step really meant to all the players involved.
• Many projects routinely got stuck in various ways. Some stall-outs were self-inflicted, but a lot were caused by schedules and preferences of clients. We could now "see" when projects got stuck, which allowed us to apply appropriate force to "unstick" them. We couldn't stop the detours, but we definitely shortened them.
• We struggled too hard to move projects from "sold" to "started" because we lacked a standard process for kicking off projects and setting dates. We were pleased when a sale was made, but didn't immediately schedule the work because we were still "busy" delivering previously-sold projects. Seeing this let us shrink the gap between "sold" and "delivered."
• Executives and sales folks could now easily see what was on the board at any time. Honestly, everyone was shocked at how many clients, projects, engineers, and other activities were in flight at one time -- a first glance was overwhelming and actually gave the team a lot of pride in our ability to handle so much with so little. The Kanban visualization gave us shared context and, despite the flurry of sticky notes, we calmed down individually and as a team. We were finally in control.
• Kanban is definitely biased toward project completion, which is what we -- and our clients -- wanted. At every step, we were collectively working to move project "cards" (sticky notes) from left to right. A common question emerged from our discussions: "What will it take to move this card to the right?"

Going Digital: Kanban on LeanKit

While it was fun and even useful to do our Kanban projects board with sticky notes and markers on a whiteboard, we realized this had one huge down-side: you couldn't see or edit the board if you weren't standing in front of it. Want to look up or update something from your desk, or from a client site, or from home? Too bad. This made the board less accurate because we really only updated it weekly. It was also a bit of a pain to edit the sticky notes (you often had to make new ones), and if you ever wanted to edit the lanes on the board (which we did a couple times), it was a major undertaking. So once the team had gotten the "Kanban culture" going, we decided to make the board electronic. We wanted it to be cloud-hosted, web-based, with simultaneous content editing, and ideally with some mobile apps.

I tried out several Kanban-based online tools available at the time (2015), but after each trial I kept drifting back to LeanKit, the source of the "Kanban Roadmap." LeanKit turned out to be the best option, so I converted our physical board contents to LeanKit, shared it with the team, and we were off to the races. We still had weekly meetings, but they were faster because the board was updated all week long, as the need struck, from any location. Very quickly I also started making adjustments to the lanes on the board -- something I'd avoided with the physical board because it was such a pain.

In an early edition of our LeanKit board, the central part looked like this:

We were pretty happy with the results. Our Kanban-based workflow visualization system was very visual, simple, and shared. It kept us focused on moving our work forward (to the right). We could see where things were working, where work was stuck, when we had conflicts, or when engineers needed more work. For us, at our size, but with the complexity of our work and the lack of a dedicated PM, it's was a "just right" solution.

One important process change developed later: we stopped our weekly whole-team meetings. Instead, we did individual engineer meetings on a weekly basis, reviewing status, next steps, and solving problems. The LeanKit board was still visible to everyone, and sometimes project cards jump from engineer to engineer, but we definitely made the review process more personalized. This might not work for every team, but for us the engineers tended to work either as solo practitioners on projects, or as mini-PMs pulling in other technical resources as needed.

Results

Once we dumped the Excel spreadsheets and other tracking methods and went visual with Kanban, things changed for our teams and our customers. We were better able to ensure each customer was getting their project in roughly-estimated timeframes -- we stopped pushing off projects by months and instead delayed perhaps a week or two or even a few days as our cycle times came down between project inception and completion. As workflow went up, incoming cashflow both increased and smoothed out. Everyone was more satisfied -- sales, the engineers, the customers -- because we could finally speak intelligently about what was going one, with whom, and when.

I had no idea Post-It Notes -- whether physical or virtual -- could be so powerful.

PART 2: Corporate IT Operations

After my first success with Kanban, I moved on to an internal corporate gig, leading a similar IT infrastructure team comprised of help desk techs and engineers of various stripes, covering all IT operations and delivering IT projects for over 1,000 employees across 16 cities in a $2B home builder. And when I arrived, the team and its projects were a mess.

Your Job: Get Work Flowing

The CIO was very clear before I was hired and repeated to me in the opening days of my time as the IT Director: the infrastructure team had good people on it -- smart, hard-working, loyal -- but they couldn't finish a project to save their lives. They were responsive and attentive to requests from all over the company and they could devise novel solutions to problems, but team managers had failed to keep the work moving or even provide reliable insights into when anything would be done. So lots of stuff was started, but nothing was finished, despite all the good intentions. (Added to the mix was a bad manager who was fired, followed by a good manager who only stayed 3 months before leaving. The team had been through the ringer.)

Very quickly I spotted the problems, falling back on my Phoenix Project readings and my experience developing Kanban-based methods at my last job: they had a monster spreadsheet of project work and operations work, all of it considered to be Work In Progress (WIP). They had a WIP logjam and everything was moving forward at a microsopic pace. Technical debt was piling up. Projects were conflicting for resources. And the highest-priority work was determined with a decibel meter -- the loudest, most politically important people got their work done first. (Sound familiar, anyone?)

Fresh off the Kanban success above, I brought Lean and Kanban ideas to the team. We mapped out our most common processes. We took down some framed internal marketing photos to clear a big wall space. We put up a whiteboard and I collected markers, sticky notes, and more. We even setup a webcam where a remote team member could join our meetings and see the board.

Let's Get Physical. Again.

Like my prior experience, we started with a physical Kanban board, even though I knew we would go digital at some point. Why bother doing a physical board?

Some Kanban practitioners swear by the physical board, and I understand why. It creates a physical space for team discussions and interactions around the work that's flowing through the team. It allows regular repetition of Kanban ideas and methods, like focusing on flow, controlling WIP, breaking through blockers, keeping all work visualized, and so on. It's faster and easier to reinforce these ideas as a team, and it's less threatening to new participants than "you did this wrong" comments in a software tool where the discussions are faceless and context-less and can be taken very negatively. And it makes work both visible and "public," especially if it's up in a hallway or other widely-used space. (Ours was in a hallway right next to the kitchen -- perfect for catching almost anyone in the department.)

Co-Creation of Meaning

As recommended by any Kanban promoter, the structure of the board -- both initially and over time -- was driven by the team in regular discussions. We collectively named the phases that work passed through; we defined the rules governing how work items (cards, stickies) slipped across the board from left to right; we defined what went onto the cards; we tried -- but never quite succeeded -- at controlling the "size" of each card, in terms of hours of work involved. Participation -- around the physical board -- meant the entire team owned the structure, the content, and the rules. And it created opportunities for everyone to demonstrate leadership from any level -- a key Kanban concept.

For as long as the physical board existed, we generally had daily standups to review work in progress and next steps, review bottlenecks, roadblocks, and so forth. It really helped the team build a clean culture of work. We started to complete projects. And we had a smart way to "negotiate" with the CIO and other leaders in the company for resources and more time to complete projects. We suddenly had the power of "no" when responding to new requests -- because that "no" was backed up with a visual representation of why we can't handle the new requests.

From "No" to "Not Now" to Shared Prioritization

However, we didn't really tell the CIO "no" to new requests. We weren't crazy! Our new-found ability to articulate what was going and point out the work we were finally getting done meant we could engage in a more realistic, adult conversation about workloads and priorities. We tried saying "No" early on, but then started to say "Not Now" or "Not Yet" to all the incoming requests. Then the conversations shifted, and I learned a huge lesson.

With the Kanban board underlying our workflow, we realized we could actually say "Yes" to anything that came our way, so long as everyone understood there were consequences to the affirmation. Namely: If we said Yes to Project X, that means Project W isn't going to be done on time, or maybe at all. "Yes" on X means "No" or "Not Yet" on W -- even if Project W is already in flight.

Now the conversations with the CIO and other leaders were thoughtful discussions about priorities. We shared the duties of re-prioritization. This helped me understand the business' priorities in a much more visceral way. Over time I was able to prioritize work in ways that aligned with business goals, so the number of times the CIO or others would come along and reshape work deadlines was limited, because the team was way ahead of them. It still happened, just less.

In the end every re-prioritization idea could be considered, and with the Kanban board in place, we could have intelligent discussions about what moves ahead, what moves back, and whether we simply needed to add to the team to sustain higher throughput rates.

A Jump to LeanKit. And a mistake.

After a while we wanted some cloud-hosted app benefits for our Kanban board, in part because we had a remote team member, and because it was easier to have "discussions" and updates on each card if it was electronic. So I moved the team and board to LeanKit (as I had before). This worked great for about a year, and we made a variety of structure changes on the board along the way.

However, one of the changes I now regard as a bit of a mistake was the creation of board sections reserved for each team member. It was basically a board-within-a-board design. LeanKit was powerful enough to enable this, but it isolated each engineer's work too much, and created built-in friction points between the engineers -- no one wanted their project "stolen" by someone else so cards moved to John's sub-section were seemingly invisible to Sally. If a card was blocked for some reason, that wasn't the team's problem to solve, that was the solo engineer's problem.

Additionally, the board-within-a-board design exposed a staff problem. One team member was... clearly not performing at the same level as everyone else. Visually breaking up the board allowed me, as manager, to see the work throughput problem for that one person, but board design also showed the low performance to everyone else. Resentments grew and fractured the team. To this day I wonder whether I should have left all the work together in the Kanban structure, with all the resources and tasks jumbled together.

Next Up: Trello

As the renewal date for LeanKit came up, I began thinking about the things I didn't like about LeanKit. Back then it was slow to use and wasn't developing very quickly as an app or platform. It encouraged the team to over-complicate our board designs a bit. It made handling things like attachments and card-focused discussions clunky. It just took too much time to do simple things. And I started to wonder whether all the structural and data analysis power of LeanKit was wasted on us -- the team was relatively small, we didn't have to integrate with anyone or anything else, and the business wasn't sophisticated enough to demand things like burndown rates, cycle time calculations, and so forth.

So I looked around. I tried out some newer tools. Only one seemed to fit most of the bill: Trello. While not a Kanban-focused tool, it has enough similarities to what we needed (cards, columns for work phases, assignments to team members, etc.), but it did away with a lot of the structural features in LeanKit. The best thing about it, however, was the fact that it was fast, Fast, FAST to make updates on cards, have conversations in cards, attach documents, and more. Plus, it was under active development because Atlassian had bought the platform just a year or two before and they wanted to build it out for more subscription revenue.

After some testing and the team kicking the tires, we made the leap. I manually transferred all the active cards, and our Kanban world continued, but this time with a simpler, faster tool that functionally did less than LeanKit, but fit our team culture and real-world requirements better.

Lesson Learned: Everyone Juggles Multiple "Customers"

I thought when I moved back from a multi-customer consulting shop to an in-house IT management role, things would be a bit simpler. Keep your boss happy, and everybody's happy! Not true at all. Because keeping the boss happy still means keeping lots and lots of "customers" happy, even if they don't cut you a check for each project.

Kanban allowed both kinds of teams -- consultants and direct employees -- to put all the work on the board, see it at a glance, move work around as priorities change, know when things are really done, and communicate clearly with all the customers, users, stakeholders, leaders, or whatever else you may call them.

PART 3: Prepare for Government!

[More coming soon! Here in 2020 I'm launching a Kanban practice in IT operations once again -- this time in local government. Imagine Leslie Knope from Parks and Rec with a Kanban board.]

Recommended Reading

• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win -- The book that continues to catch fire in IT shops around the world. Written as a very readable novel, it tells the story of company that went from IT dysfunction bad enough to put the company out of business to market-leading process development by following Lean / Kanban ideas, the theory of constraints, and more. Highly recommended.
• Making Work Visible: Exposing Time Theft to Optimize Work & Flow -- This is a practical book for new Kanban practitioners that explains why you need this approach, then goes into lots of pragmatic advice on how to actually make this a reality with your workloads and teams. It gets to the point and has plenty of visuals.
• Kanban Roadmap -- This free downloadable guide from Planview LeanKit is great for getting your team started with Kanban methods. It has step-by-step recommendations for getting started and helps me every time I've started to roll out Kanban ideas to new teams.
• Using Kanban in IT Operations -- Another free downloadable guide from Planview LeanKit addresses the use of Kanban in IT operations groups generally. I've not found the specific recommendations in her directly applicable in my smaller teams, but I get the sense this would work very well in larger IT operations groups.
• Free downloads from Kanban University -- Each of the free downloads are for different situations, and many are written with software development in mind, but you may find something useful in here. Kanban University also offers live classes, conferences, and certifications, if you're interested.

Recommended Videos

• Eric Brechner: Agile Project Manage with Kanban (at Microsoft) -- A long talk about using Kanban for project management (from a software perspective). Bonus: It's delivered via a live Kanban board. [1 hour]
• Eric Brechner: Agile Project Management with Kanban (at Google) -- same presentation as above, but the audience questions are different, so you get a unique talk that emphasizes different points. [1 hour]
• The Agile Coach: What is Kanban? -- Atlassian has a video series, as well as a nicely-done website, on Agile topics, including Kanban methods. This is the first Kanban explanation. [5 min]
• The Agile Coach: What is a Kanban Board? -- Details on boards. [6 min]
• The Agile Coach: Kanban WIP Limits -- Details on WIP and limiting it. [6 min]
• The Agile Coach: What are Kanban Cards? -- Details on cards. [5 min]
• Dominica Degrandis - How we used Kanban in Operations to Get Things Done -- Real-world example of how Kanban ideas and methods were brought to a large IT operations group and transformed their workflows and job satisfaction. Presentation from a conference in 2014. [30 min]