In this series by organizational problem-solving expert Johanna Rothman, uncover the mystery behind agile project management. What is it? How does it apply to your workplace each day? Why should you be looking for technology candidates with agile experience? See how separating decisions, prioritizing projects and tackling one thing at a time produces a smoother, more ‘agile’ process in tech. __________________________________________________________________________________ Part 3 in Dice's Agile Series In the first two articles, we covered the basics of agile and then how tech teams identify and manage workload in agile. In this article we discuss the project management tool Kanban, and how it helps agile teams solve problems. To get projects accomplished, there is an ongoing conversation between the team and the product owner. The team always tackles the next item on the list. Daily standup meetings ensure a smooth flowing process. When there are problems making the iterations work, teams often turn to a Japanese management tool called Kanban. What the heck is Kanban? Kanban is a Japanese word for "card." It's a way of pulling work through the system. It allows you to schedule when the work flows through the team. You can think of it as deeper version of the Scrum board. Sometimes developers over-produce features. They proceed too fast for the testers. Some teams cannot produce all the work they commit to. If you have ever made a to-do list on Monday and gotten to Friday and wondered, "Where did the week go? I still have all my to-dos!" you understand the problem. 
That's where Kanban comes in. It helps teams see where they overproduce and so they can fix bottlenecks. Kanban is a series of queues that describes the team’s workflow in more detail than a Scrum board. It's the Roles, Not the Titles An agile team is a 5-7 person team, comprised of the roles this team needs. When you use Kanban, you can see how work flows through the roles. This gives you the ability to make adjustments in team size and role distribution. As a recruiter, you might have to discuss the roles needed for this team with the hiring manager. Does the hiring manager have his or her heart set on another developer? If you have a chance to see the Kanban board and the team is over-producing features, you might act as a consultant to the team and say, "Maybe you need a tester." In the Kanban board above, you can see that there are several columns. "In Progress" from a Scrum board becomes: "Develop and unit test," "Dev-Done," and "System Test." Look closely at the numbers in each column (3 and 2). Those numbers are the Work-In-Progress (WIP) limit. The team cannot have more than that number of cards in the column. If they do, they violate their WIP limit. The WIP limit is how Kanban helps make sure the developers don’t overproduce. So when the team keeps to their limits of no more than three stories in development, they don’t overwhelm the testers with stories. The testers can maintain their rhythm, and finish the stories in this iteration. Kanban provides flow Agile has iterations to provide a work rhythm. Kanban uses the WIP limit to keep the flow of features going through the team. Some teams like both the cadence of the iteration and the flow of features with the WIP limits. I use both for my work. I like the periodicity of one-week iterations as a way to review my work, and I like the flow of personal Kanban. How to measure progress in agile Many agile teams use "burnup" charts to measure their progress. Another option is "cumulative flow." A burnup chart is a grid of features completed over time. Burnup charts can tell you many things. If your burnup charts look like hockey sticks (like the one below), your project is in trouble. The team is not maintaining a flow of finishing features throughout the iteration. 
If the burnup charts are more regular and flat (like the "Steady Progress" example below), the project is better. A Kanban board would be able to tell you where features are stuck. 
A cumulative flow chart tells you how many features the team is working on at once. Ideally, a team should have zero features in progress at the end of an iteration. If the team is only using Kanban, there should be very few features open at once, because they are managing to their WIP limits. 
Conclusion You now have a basic understanding of how work is done with agile methods. The team negotiates a scope of work (stories) to be accomplished in an iteration. That work is completed on a prioritized basis, highest first. The iteration ends with another scope negotiation with the product owner. In part four of this series, we’ll look at agile culture and how to recruit for the right professionals to fit on a team.
Agile Terminology Kanban: Card. A pull system of work. WIP: Work in progress.
