Friday, April 3, 2015

How We're Crushing Technical Debt

How it all started

Year after year we'd been placing things on our yearly goals that just weren't getting done.  And the list kept growing.  That left us feeling like we weren't accomplishing anything at the end of the year during review time.  Huge morale killer.  It's not like were weren't busting our asses all year; we were always busy.  We just never made time with everything else going on to work on reaching our goals.  We were too busy fighting fires, or we never had the focus for what was next in line.

This year we decided to change that pattern.  After a bit of trial and error, we came up with a system that has been paying dividends.  With this new workflow we've paid down more technical debt in the past three months than we've done in probably the past two years.

How did we do this?  We stopped trying to do everything and let some stuff fall on the floor.

Evolution begins

A few years back we started using KanBan.  Specifically, we're using the SaaS solution from LeanKit.  If you're new to KanBan, The LeanKit folks have a write up you can read here.  When we adopted KanBan, we saw an instant improvement in our workflow.  It was amazing.  Things were getting done, you could see what everyone was working on, and you got a good sense of the team's accomplishments at the end of the week when we moved all of the completed cards into the archive.  We felt like we'd made a breakthrough, and we had.  Our work was organized and throughput was high.

But what we noticed over time, is that all we had managed to do was move our inbox workflow to KanBan (which was good for tracking), but we weren't making any real progress on knocking out the items on our backlog.  We were just treading water and dealing with requests as they were coming in.

Then, late last year, a few of us started brainstorming about how to solve the backlog issue.  What we decided to do is split up the team.

The next stage

We started by splitting the team in half into two new teams: Systems Support and Tech Debt.  Turns out this ratio worked for us, but if it hadn't we could have easily rebalanced the team members.  The Systems Support team takes care of all of the normal day care and feeding.  That's dealing with systems issues, processing new support requests, etc.  The Tech Debt team pulls its work from a new KanBan board we created that contains all of our backlog items.  The new workflow for the Tech Debt team blends the KanBan and Scrum methodologies into something that works for us.  Here are a few screenshots to show our board layout:

Tech Debt Team Product Backlog Board
The Product Backlog holds our work that has not yet started.  The Tech Debt team pulls all new work from the Prioritized Backlog column, which is groomed routinely by senior leaders and management.  Because of this constant grooming, at any time a member of the Tech Debt team is able to go this location and pull in the next highest priority item.  The Not Yet Prioritized column is normally empty, but as new requests or ideas emerge, they go here for sorting.

Tech Debt Team Work In Progress Board
The Work In Progress board is used on a daily basis.  New items that have been pulled from the Product Backlog board are placed into the Sprint Backlog column and then broken up by he team into individual tasks that are needed to accomplish the overall goal.  Each of those tasks are taken by a team member one at a time, worked through to completion or to a blocked state, and then eventually moved to the completed column.

Every Monday, we hold a demo session with the Tech Debt team, the Systems Support team, and  middle management to share what we've done.  Once each item is accepted by the whole team, it's moved to the Accepted by PO column where management uses the data for reporting and then archives it.

A few things we learned along the way

You might find that it's not possible to split up your team so you can get started.   If that's the case, try and peel off one person first.  Have that person focus on automating or delegating some of your team's work.  Enough so that you can free up a second person, and then maybe another.  It depends on your team's size and dynamics.  Once you feel like your team is sized appropriately, get to work on knocking out the technical debt.

When prioritizing items in our backlog, our default ordering routine is to sort things by the importance to the business, then importance to other teams, and lastly the importance to our team. We typically place the needs of other teams in front of our own.   There are exceptions, but it's our general rule.

We have many items towards the bottom of the backlog that will likely never be completed due to the fact that they aren't big problems, and other new required work will get bumped up in front of them.  That's okay.  We want to work on what's most important to the whole IT system.  We figure that if those items at the bottom become important enough, they will bubble up to the top.

We have also discovered psychological benefits to the new system.  Before, we had so much context switching going on that our heads were spinning.  Priorities were always changing and the team never had a clear feeling of what to do next.  Now, since the backlog is an ordered list that is routinely groomed, there is rarely a question of what is the most important thing to do.  It's liberating.

1 comment:

  1. Nice article, I may have to appropriate that for my team.