Kanban to catch a quick-moving situation

Question

We have a brownfield project which was recently struck by disaster (many people leaving for unrelated reasons, too many new customers, much too large backlog for much to few people, etc.). Management support is still fine. Thank bob the product owner (decades of knowledge) is still here. The devs have seen some glimpses of DevOps benefits from a very nicely-received DevOps colleague who is doing practical work as well as evangelisation, so there is no resistance on that front, either.

At the moment, we are bringing in new people from all over the place (i.e., split across different cities and even countries, though all speak the same language), and getting the know-how under control etc. We are also focusing a lot on automation before starting actual development again, because everybody saw what happens when we don't. Also, we have bundled everybody together - devs, ops, testers, to make use of every last bit of knowledge and avoid future silos. So it is a very dynamic situation.

My main objectives are:

• Get people to work instead of panicking, i.e., give the individual devs focus.
• Shield devs and ops from panicked management and stakeholders.
• Make it more transparent for stakeholders to see what is happening with their tasks/epics, to reduce panicked zero-warning status calls.

Most people, as well as me, are used to Scrum (or more likely Zombie-Scrum or Scrum-But ;) ), but I believe it is too early to do proper Scrum here. So I will likely implement Kanban (in Jira).

What are your best practices here?

• One column per person/pair? Or rather one column per stage for the tasks (i.e., "in development", "in testing" etc.)? I think I'd prefer the first, because it very clearly shows whether a person/pair has their hands full - we could use a full column really well for telling a manager to go away. Also, we have quite diverse roles in the team (i.e., a DevOps expert who will be focusing on the CI/CD pipeline and such; or the testers).
• In the usual Scrum process, the P.O. would not be part of the actual sprint board, but do his good work in the backlog. Would you propose to give a column to the P.O. so he can focus on fleshing out a few task at a time? This would put the P.O. well inside the team, which I would like. Is it a good idea? (Yes, I am aware that Kanban does not actually label those roles, but I hope you see what I mean...).
• Alternatively to the previous: I believe The IT Sceptic had an article about having two boards - one focused on the stakeholder epics, the other on the actual short-term tasks. Do you have experience with that? Would that help in this situation, in your experience?

These may seem like three distinct questions, but are, in my mind one: how to structure the Kanban board - around people, or around tasks?

Answer 1

We are a product development shop - and in fact we build a Kanban tool (SwiftKanban), in addition to others. We have a lot of experience with Kanban and DevOps and separate boards for epic/ story detailing vs. dev/ ps tracking. Our DevOps setup is still being fully automated and being gradually fleshed out. We've been on this journey since 2010-11 - and we have achieved significant business benefits exactly of the kind you are looking for.

We started with a single Kanban board, but with 2 separate swim lanes for the product manager and the dev team - see below -

Planning Lane for the Product Owner

Dev Lane for the main dev activity

Since we had a single team doing development as well as maintenance/ customer related work, as also refactoring work, we also had a few other lanes to help them visualize their overall workload -

Over the last 6 years, we have evolved, as have our dev/ engineering practices. While we never used Scrum - and don't have sprints, we do production releases every 4-6 weeks, we deploy to an internal staging server (which we use as our internal production server, where we use our product for dev as well as other functions such as marketing, sales, support, implementation services, etc.) every week or less, and we have a single workflow between Dev and Ops as you will see below.

From that separate planning lane, we have evolved to a full upstream Kanban board - which is our roadmap planning board, where we track Themes, Epics and Stories - and lay out stories in up to 4 releases out. We did this as we gradually figured out just how much work needs to get done to identify and detail the work to be done as well as to get stakeholder alignment so everyone agrees that we are working on the right stuff.

Roadmap Planning Board

Stories from this board get pulled to the Dev board. Internal and customer reported defects are directly added to this board's Ready queue.

Dev Board

As you can tell, the Product Owner (Product Manager) is responsible for the Roadmap board, while the Sr. Dev Manager is responsible for the Dev Board. While Dev team members deply to Staging server, the Ops team ensures they have the right CI/ CD environment to do that. After Dev/ Validation, it is the Ops Team's job to deploy to production once sufficient valuable work has been completed (typically 4-6 weeks).

Both boards are accessible to all senior stakeholders as well as CEO, Sales and Marketing so everyone can track what is going on and what is prioritized for upcoming releases.

At the same time, we ensure we follow some of the recommended Kanban cadences, including the Daily Standup Meeting, the Weekly Replenishment Meeting (where fine-tuning of the story/ defect prioritization takes place) as well as Release Retrospective and a Quarterly Strategy Review Meeting.

The Kanban boards and cadences ensure that everyone is aware and aligned; and if there are conflicts, they are resolved during one of these meetings (other than the Daily Standup).

Besides key Kanban practices - including a reasonably strict adherence to WIP Limits - we have also, of course, invested heavily in engineering practices to enable a true continuous delivery/ deployment environment - and that journey still continues. We are a Test Driven Dev shop and developers are responsible for JUnits, Functional Automation, and Peer Review. Our code repository is Subversion and integration/ deployment is orchestrated using Jenkins. Subversion is integrated with our Kanban tool so all work at each stage is also updated on the card as well (via comments on the card).

Overall, to answer some of your questions more specifically,

1. Yes, it makes a lot of sense to provide a separate board to the product owner and another to the dev/ ops teams and link cards across them as needed.
2. And it makes sense to organize the board by tasks/ workflow stages rather than people as that gives you greater flexibility with using cross-functional folks in different stages of the workflow.
3. Most importantly, it lets you easily visualize and measure which workflow stages might be bottlenecks (rather than which people - which would typically be inaccurate) and what tweaks you might need to make to improve your flow and throughput and reduce lead time.

All the best with your transition to Kanban! If you need any more help with respect to Kanban, I strongly recommend reading David Anderson's book on the Kanban Method as well as refer to our comprehensive Kanban guide.

Hope this helps.

Answer 2

The beauty of a kanban board is that it lets you see what everyone on the team is working on; if work is related, it should be on a common board (in my opinion). However, one way to deal with specialization of teams is to use swimlanes, particularly if the tasks have common phases.

Take a simple board for example, with a To Do pile, a Doing pile, and a Done pile. Create a swimlane for each of your subteams, and and limit their WIP accordingly; this allows for common visibility with some independence.

I think two boards makes sense when the phases are more complex; if you have to have a pipeline between teams for some things (i.e, you need QA review after the devs do their code before an item is done for epics), but not for others (fixes), then two different boards with different phases makes sense. However, you have to deal with the complication of shifting between boards.