A Practical Approach to Agility and Product Management

Tag: kanban

What Kanban is – and what it isn’t

Nowadays Kanban is a well-established Agile development approach and various teams either dabble in it at least once or have adopted it for themselves. I believe Kanban can be a great fit under circumstances where Scrum with its fixed iterations can pose some serious challenges, e.g. working in more of a support or break/fix environment. Like everything else in life, Kanban has its pros and cons and while it excels at flexibility, predictability seems to be more of a challenge than with other approaches.

Some of the basic tenants and techniques of Kanban include

  • Visualizing your value stream
  • Optimizing throughput via work-in-progress limits
  • Measuring and optimizing flow
  • Reduction of waste
  • Pull-based system
  • Explicit policies
  • Classes of service

 

Some of these practices and techniques will need to be established early on in the adoption process, such as visualizing the value stream, while others will come later as the system evolves, e.g. classes of service. Another key prerequisite is that work items flowing through this system should be relatively small (or at least not large) and of similar level of granularity. This ensures items keep moving through the system.

Kanban seems “easier” than Scrum and for good reason since there are fewer “rules”, roles, and ceremonies. But Kanban isn’t trivial. In my experience, it requires more discipline than Scrum for a team to practice Kanban well and get really good at it.

Unfortunately, I’m seeing a lot of this happening: A team isn’t doing all that well with Scrum. They hear about Kanban and think they’ve found the Promised Land. Gladly they drop iterations. The value stream is often not thought about much and remains very simplistic. More often than not, other practices are also thrown overboard: no more planning (ad-hoc or with batches of items), retrospectives, sizing, and task decomposition. (They’re all waste, right?) Maybe the daily stand-up survives. Perhaps as a result of little to no planning and sizing, item size variances creep in and work items become less thought-out and defined. Then items get stuck on the board either based on their large size and/or external dependencies (which often would’ve been resolved previously with Scrum before an item would enter an iteration). If WIP limits exist, they’re either way too large (how does 15 sound for a team of 4?) or mostly ignored. Suffice it to say, classes of service and explicit policies never emerge, measuring is forgotten and items are pushed through the system.

What’s the result of all this? Lack of visibility & transparency, inconsistent and subpar performance, potentially poor quality, almost complete lack of predictability and more often than not stakeholders and business owners who don’t know what the status of their development projects is and when to expect features.

If we compare this end state to real Kanban, I’d argue there’s more resemblance to “anything goes” or the “Wild Wild West” than actual Kanban.

Don’t get me wrong: I like Kanban. Under the right circumstances and with a disciplined team willing to learn a new approach and get good at it, there’s tremendous value to be realized. But let’s not kid ourselves: throwing out iterations and using a board doesn’t make you a Kanban team. That’s what I would call “none-ban”. Adopting real Kanban takes work, discipline and requires evolution and maturation the same way a Scrum team will learn and get better over time.

Since Kanban does require a significant amount of discipline, I’m tempted to suggest that new teams don’t go straight to Kanban, but cut their teeth by building a solid track record and discipline with Scrum first. Then going to Kanban gives them a much better chance to continue with discipline in a less structured environment.

As mentioned in one of my previous posts, “structure” is not a bad thing and the less experienced a team is, the more it might need to become a high-performing team. A Kanban team, just like a Scrum team, needs to start basic and then evolve, which may involve adding additional structure (e.g. classes of service). We should be concerned about removing so much supposed “waste” that the team never makes it out of its Kanban infancy and stagnates way before reaching its full performance potential.

So let’s be clear about what Kanban is and what it isn’t. Otherwise we may end up giving Kanban a bad name despite of all of its potential benefits.

The Art and Waste of Estimation and Structure

There has been a fair amount of noise and chatter around “estimation” in the Agile community lately and some of this debate is turning heated and sometimes almost religious. I certainly don’t want to get dragged into that, but at the same time this discussion has helped me see a few things clearer that I wanted to share.

I’m going to widen the term from “estimation” a little bit and call it “structure”. Structure can mean a number of things, all of which are somewhat elective in Agile:

  • Story estimates (in story points, ideal days, t-shirt sizes, etc.)
  • Story decomposition into tasks
  • Task level estimates (most often in hours)
  • Capturing of actual hours at the task level

Sometimes the structure is extended to include things like

  • Iterations themselves
  • Sprint burndown charts
  • Planning conversations and exercises

Some of the voices in this debate quickly judge the above structural elements as waste or in Japanese “muda” (although – as Scott Ambler pointed out – using a Japanese term for something we have a perfectly good term in English for is waste in itself; why waste brain power on translation? But I digress…).

A number of these structural elements are mechanisms to help create team predictability. Predictability in itself has taken a hit in the community and some argue it’s pushing us back to waterfall. I’ll make the argument that despite business model at a minimum an Agile team should have some level of short-term predictability, i.e. the ability to make a commitment / forecast for the next 1-2 weeks and be consistent in meeting it (I’m not talking about defect/break-fix teams here).

At the end of the day, a high-performing, stable Agile team is characterized by being able to produce a significant amount of high-quality output (working, deployable software) in a consistent manner. Despite what Agile maturity model you subscribe to, this always seems to be a big part of it.

I postulate that the less mature a team is, the more structure and with that “data” and visibility into what’s going on it needs.

Having iterations, tasks, task-level estimates, a burndown and the ability to compare estimates and actuals will help a team get better and become more predictable and ultimately high-performing. These structural elements are like training wheels to help the team mature and build some important disciplines.

Once the team approaches high performance, one might consider selectively removing some of these structural elements, assuming the team is mature enough to where those don’t add any value and aren’t required for other reasons. But one shouldn’t have to get rid of any elements, especially if removing them actually negatively affected team performance (which could happen if critical or too many elements are taken away).

On the flip side, doing away with all or most these practices and artefacts right away or never implementing them in the first place (because they’re perceived as wasteful), before a team is high performing, is dangerous and will prevent them from reaching their full potential.

Interestingly, I’ve recently had the chance to see teams that never used to have these structural elements and when they were introduced for the first time, they served as quite an eye opener for them and the additional visibility seems to help them greatly in fine-tuning themselves and reaching higher levels of predictability and performance.

In certain situation data captured by the team may not always directly benefit the team, but serve a purpose outside the team in other parts of the organization. The team may not care about story points, but maybe the Product organization finds them beneficial in understanding relative size of and progress against various epics that – without story points – wouldn’t have a tangible size. Capitalization rules may requires actual effort spent on a project to be captured. In those cases the team should probably not remove those structural elements.

In summary, instead of calling structure wasteful right off the bat and quickly judging it as bad, I think a more deliberate approach might be in order. Maybe the conversation should shift away from “if” and focus more on “when”. It’s not all good or bad; it’s about what things make sense and adds value under what circumstances, during which part of a team’s maturity curve. New and immature teams will require more guidance, data and visibility. Mature, high performing teams will require much less structure.