You’re familiar with Scrum, right? I’d guess yes considering that The Scrum Alliance has over 400,000 members, and of those, most are successfully using it in their organizations.
But, it isn’t the only way to build software in an agile way—seriously! Have you heard of Kanban?
For a little background information, it was originally applied to lean manufacturing as a way to visualize the input and output of work as it flowed through a factory. This visualization was presented on a board known as a—wait for it—Kanban. More recently and more pertinent to you, it’s been adopted as a method for managing software development.
First outlined by neurologist David J. Anderson, it’s a way of organizing software development and planning that allows you to uncover process problems and consistently deliver valuable improvements in your product—which I know, sounds ideal. Simply put, at any point in time, you can see where work (represented by cards) is in the process of development.
How it Works
The basic Kanban board uses six columns that show where each piece of work is in the product development cycle. A rough sample of what it looks like is below.
View this Kanban board example on Trello.
Column 1: Backlog
The Backlog column should contain a prioritized list of ideas, bugs, or business needs. The card doesn’t have to have a ton of detail yet, but it should have enough information that your team members understand why it’s important.
Column 2: Planning
In this column, a product manager will fill out a specification for the feature by meeting with business stakeholders, engineers, and designers. When it’s ready, he or she will move it to the “Ready for Engineering” column.
Column 3: Ready for Engineering
At this stage, all cards should have detailed specifications. While you may still have questions about technical details, the business requirements should be clear.
Column 4: In Progress
You can move a card over to “In Progress” at any time. This self-driven “pull” system builds a culture of personal accountability and curiosity.
Column 5: Testing
When you have completed work on the card, move it to “Testing” where another engineer (or someone on the QA team) will pick it up.
Column 6: Deployed
Another defining feature is that work should be delivered continually to a staging or production environment. This column allows anyone on the team to see what work has been released recently.
The Advantages and Tradeoffs
When you’re deciding between Kanban and a more common methodology like Scrum or Waterfall, keep these benefits and challenges in mind:
Benefit: Improves Collaboration
In some development teams I’ve worked with, engineers were specialists. Each team would have a couple frontend engineers and backend engineers. This meant that work was often blocked because an engineer was busy with something else.
Kanban, on the other hand, limits work in progress and discourages blockages. Each team member can only work on one item at a time, and anyone who isn’t busy can pull work from the top of the “Ready for Engineering” column. This encourages engineering generalists and collaboration among team members.
Boost the Benefit: Don’t Let Things Pass Before They’re Ready
Kanban only works when you wait to move cards along to the next column until they’re completely finished. (Bonus: This greatly minimizes defects.)
Challenge: Discourages Time to Reflect
By default, there are no time-boxed sprints with clear goals, date targets, and release cycles. Instead, think of each card as an independent piece of work that can be completed and released at any time.
With this continuous stream of work, there’s no “wait until the next sprint” option. You need to continually check the board, pull the next item, and move completed items downstream. Unless you build in time for retrospectives and standups it might be hard for team members to keep up with how they’re doing.
Get Around It: Borrow What Works From Scrum
I’ve used daily standups and retrospectives with Kanban and found that they add value. If there are regular meetings or patterns that work for your team, don’t change them to dogmatically adhere to Kanban. Budget time to talk about the priorities and how they’ve changed so that everyone knows what’s happening in the product development cycle.
Benefit: Increases Transparency
Each developer must take the initiative to move a card to the “In Progress” column. Meaning, at any given time, the team’s manager can take a look at who’s busy, who isn’t busy, and how long any piece of work has been ongoing.
When production slows down or stops, Kanban allows you to see exactly why. Whether it’s because the business team hasn’t prioritized items in the backlog, the product team hasn’t finished spec, the dev team is moving more slowly than expected, or the QA team has been unable to test something; the bottlenecks are obvious.
Boost the Benefit: Allow Progress to Be Public
One of the advantages is that Kanban is very visual. Even non-technical team members can look at a Kanban board and tell where pieces of work are in the process. Use this to your advantage and allow the team’s accomplishments to shine by putting your board up in a public place.
Challenge: Doesn’t Allow for Long-Term Planning
Worrying about deadlines and estimates is not the most productive use of your time, so you may appreciate that Kanban is more about day-to-day output. That said, it alone does not provide a system for building a long-term plan. This can cause you to work on projects sporadically rather than focusing on one thing for a long time. It’s tough to spend a day on Project A then a day on Project B then switch back to Project A.
Get Around It: Use it When Your Priorities Will Likely Change
Each column in your board is independent of the others, so team members can move things around at any time. This can annoy developers in a Scrum setting (where estimates for the sprint are made upfront), but Kanban thrives in this kind of quickly changing environment.
Everyone wants to be more productice, but it can be hard to try something new if you’re not even sure where to start. I’ve found Kanban to be helpful and hope you’ll also find it useful for your personal workflow (or even for your whole team!).
Tweet me if you decide to give it a shot!