Agile Project Management with Kanban: Adapting from Waterfall

Rude Q & A

What follows is a rude Q & A session that is based on questions I’ve received from traditional Waterfall team members when they were introduced to Kanban. I hope it covers many of the questions you receive.

• Q Why are we adopting Kanban?
• A The software industry continues to evolve. Customers now expect their apps and services to update automatically and be improved continuously. Our current practices impede us from keeping pace.
• Q Instead, how about we stop changing practices, plans, and requirements constantly?
• A Plans and requirements always change, no matter how well prepared or well considered they are. Even when you are your own customer, you constantly change your mind. Nevertheless, stable plans, requirements, and practices aren’t sufficient for us to react quickly to the current market.
• Q So you’re saying it’s hopeless?
• AIt’s not hopeless at all. The rest of the industry is moving forward. We can join in with some relatively small changes that have a big impact.
• Q Will we need training for Kanban?
• A We’ll learn Kanban mostly from doing it every day. Books about Kanban and Kanban coaches are available to help us with adoption.
• Q Are you going to make me sit in a cubical farm or share a desk?
• A No, you don’t have to change offices or share desks. You don’t even have to change how you write specs, software, or tests. We’re just adding a daily standup meeting at which we track our workflow on a large board.
• Q How is adding another meeting going to make me faster?
• A The daily standup lasts less than 15 minutes and replaces our old planning and status meetings. We’ll schedule it at a convenient time for the whole team. Regardless, it’s smooth and continuous workflow that makes the team faster.
• Q How do we get smooth and continuous workflow?
• A Today, we specify, implement, and validate features in bulk. It’s fast, but when a plan or requirement changes, we lose work and momentum, and when bugs are found late, we have lots of costly rework. Going forward, we’ll pace specification, implementation, and validation to run at similar rates so that we can smoothly complete small batches continuously.
• Q How do small batches make us faster?

• A Small batches speed us up in a variety of ways:

  • When a plan or requirement changes, it affects only a small batch, so less work is wasted and the team can adjust quickly.
  • Small batches mean smaller bug backlogs, so we don’t need dedicated team stabilization periods.
  • We have to specify, implement, and validate only a small batch at a time, so we don’t write specs that aren’t implemented, implement code that isn’t validated, or write tests that are never run.
  • We can get customer feedback after every small batch, which avoids being blindsided later and reworking major portions of the design (or releasing a product that customers dislike).

In all, small batches significantly reduce wasted effort and rework, while improving the quality of our product.

• Q So why haven’t we been using small batches all along?
• A Small batches require a coordinated flow of work. If analysts specify more features in a week than developers can implement, specifications start piling up, and you’re back to doing work in bulk. Likewise for developers implementing more features than testers can validate. If you can’t pace specification, implementation, and validation to run at similar rates, you’re stuck working in bulk and dealing with wasted effort, large bug backlogs, and substantial rework.
• Q We have a wide variety of analysts, developers, and testers. How do you pace work properly?
• A You limit the pace of specification, implementation, and validation to match one another. You base those work limits on the current pace of each step, plus some buffer to account for the variety of people and work involved. These work limits are often called “work-in-progress (WIP) limits.” Naturally, your initial guesses about the limits will need fine-tuning, but even initial guesses are typically good enough to produce a smoother, more continuous flow of small batches.
• Q Wouldn’t limiting work make us slower?
• A We’re not limiting people, we’re limiting the kinds of work they do. If developers are stuck on a feature, an analyst specifying more features doesn’t help. Instead, the analyst should work to unblock the developers (for example, clarify the spec, escalate an issue, research a customer preference, or bring in partner expertise). By focusing on keeping the work flowing smoothly, and limiting work so that it maintains a smooth pace, we actually get more work done in less time.
• Q Why not keep the analyst working and have the developer move on to the next task?

• A The key is the status of the blocked implementation task:

  • If the task is blocked by an external dependency, the developer should move on to the next task until the old task is unblocked. We’ll keep an eye on the blocked task in a special column on the signboard.
  • If the task is blocked by a design question or issue, it’s the analyst’s responsibility to unblock the task, ideally while the issue is still fresh in the developer’s mind. The limits on work and the visibility of blocked tasks prevent analysts from ignoring design issues and letting them fester.

The same applies for blocked specification and validation tasks. Instead of letting problems pile up, we’re going to work together to fix them quickly. That keeps work flowing smoothly, fixes issues before they permeate the product and become harder to repair, and delivers value faster and more continuously to our customers.

• Q Won’t I be constantly hassled about fixing problems?
• A Actually, you’ll be hassled less than you are today. That’s because we always have problems, but today we find and fix them late. By fixing problems early, they are fresh in your mind, easier to fix, and don’t have time to multiply and cause further trouble. You will be hassled earlier than before, but most folks appreciate the dividends of not having problems fester.
• Q Will everyone be coming to me with problems?
• A No, you’ll work on individual tasks like you always have. We’re adding a daily standup meeting where we track our workflow on a large board. That signboard will show your work, and everyone else’s work, on cards that flow across the three steps: Specify, Implement, and Validate. The WIP limits that set the right pacing will be written above each step on the signboard. Everyone will see when work is getting blocked and bunched up—they won’t all just come to you. Instead, the team will work out issues together.
• Q What if one person keeps causing all the blockage?
• A There’s a classic remedy if someone really can’t do his or her job. However, if someone is careless or lazy and tends to pass on half-done work, he won’t get away with it. We’re going to have done rules for Specify, Implement, and Validate. Before someone can move a card, claiming it’s done with the current step, the work has to pass the done rules for that step. No half-done work is allowed.
• Q Who determines the done rules?
• A You and the rest of the team decide on the done rules you’ll follow. You know what causes issues. You know how to do your job well. You get to decide when a task should be considered done. Once the team decides on the rules, we’ll write them at the bottom of the signboard so that there’s no confusion. Anytime the rules need adjustment, we can change them together.
• Q What else changes with Kanban?
• A Nothing—that’s it until we want to improve even further. For now, we’ll have a daily standup in front of a big board with our work steps written on it, cards showing our work, limits on the number of cards at each step, and rules at the bottom of the signboard that determine when a card is done with its current step. Whenever you’re done with a step, based on the done rules, you’ll move your card on the signboard and grab the next available card. If no cards are available, that indicates that workflow is blocked, and you should work with your teammates to unblock the flow.
• Q Where will the cards come from?
• A We’ll take our current feature list and work backlog, write the items on cards, bucket them in priority order, and place them on the left side of the signboard, in front of the specification step. When new work arrives or plans change, we’ll add and rearrange cards as needed. (Details in Chapter 3, “Hitting deadlines,” and Chapter 7, “Using Kanban within large organizations.”)
• Q When a card moves from one step to the next, who works on it?
• A We’ll assign work to whomever is free and capable of doing that work at the time. Pretty much like we do today, but as needed, not planned far in advance.
• Q We have daily standups in front of a board that tracks progress. Are we already doing Kanban?
• A Many traditional Waterfall teams meet daily in front of a board that’s used to track progress. However, it’s not Kanban unless you list your steps on the board (like specification, implementation, and verification), and each step has a work-in-progress (WIP) limit, a Done column, and a done rule clearly marked on the board.
• Q Why does each step need its own Done column?
• A Say you just completed implementing an item (it passes the implementation done rule). Without an implementation-specific check mark or implementation Done column, how would you indicate that the item is ready for validation? On an ordinary board, you just move the item to validation. However, that means the item is actively being validated and counts toward the validation WIP limit—neither of which is true. What’s worse is that the item no longer counts toward the implementation WIP limit, so you’re free to implement another item, even if validation is overwhelmed and needs help. The Done column for each step clearly indicates the status of each item and controls the flow of items in conjunction with their WIP limits.
• Q What happens to milestones with Kanban?
• A The larger project might have release milestones to sync across teams, but we no longer need them as an individual team. Our small batches are always complete and ready for production use, based on our validation done rules. Learn more in Chapter 7, “Using Kanban within large organizations.”
• Q What about stabilization?
• A The larger project might have release stabilization to resolve system-wide issues, but we no longer need it as an individual team. Our done rules ensure that work is done at the end of each step, with no remaining issues to stabilize.
• Q If other project teams are using Waterfall, won’t they still need stabilization?

• A Yes, they will. While other teams stabilize, we can do a few different things:

  • We can keep working on new tasks for the current project milestone. This might upset Waterfall folks or break project rules, so it may not be an option.
  • We can work on new tasks for the next project milestone and check them in to a different source control branch.
  • We can improve infrastructure and tooling and address other technical debt that has been neglected.
  • We can train ourselves on new techniques and methods.
  • We can determine the root cause of various issues we’ve encountered and seek to fix them.
  • We can help other teams stabilize their code, particularly teams we depend on. This option may not be the most alluring, but it’s the most helpful.
  • We can run innovative experiments and acquire customer feedback.
• Q What happens to planning?
• A We’ll still participate in overall release and project planning, but our team planning is simply a matter of ordering cards on our big board. We’ll save a great deal of time and produce more value at higher quality, while easily and quickly adjusting to plan and requirement changes.
• Q It sounds pretty simple. Aren’t there sprints and burndowns or something?
• A No, there’s no unfamiliar terminology or new ways of doing the work. Kanban is pretty simple and direct. Kanban roughly means “signal card,” “sign,” “board,” or “looking at the board.” It refers to the cards that represent our work, the signboard displaying our workflow steps (and their assigned WIP limits and done rules), and our daily standup when we look at the signboard. There’s nothing more to it. We keep working on new cards within the WIP limits we’ve set, ensure that the cards are done with each step, and then work on the next cards. If cards start piling up, we figure out what’s wrong and fix it so that work continues to flow smoothly and value is delivered continuously to our customers. It’s a fast, simple, and easy way to work.