kanban

One Piece Flow – Alternate of Kanban in Software Development

Kanban process is based on 6 basic practices

Visualise
Limit work in progress.
Manage flow.
Make policies explicit.
Implement feedback loops.
Improve collaboratively, evolve experimentally.

If you reflect on these principles the premise essentially is to optimize the flow. Limiting WIP is a way to do that. There are no right or wrong numbers around what exactly should be the WIP limit of each column. All these numbers are bound to change dynamically and organically until the flow has been optimized.

Kanban Mythbusters: When to Use Scrum and When to Use Kanban?

by ShriKant Vashishtha 1 Comment

Kanban comes with the least prescriptions but then you find lots of fake implementations in practice.

Lots of times, people move to Kanban from Scrum just for the convenience.

It’s far easier to live with a process model with no time constraint, no pressure to improve continuously. Also some people get away with a Kanban board with no WIP limits. Even if they put WIP limits in place, you see no discipline in maintaining WIP limits or changing them when required.

Scrum is a Shu or Ha (Shu-Ha-Ri) kind of framework which can be immediately used by beginners. It has valid prescriptions to start with. It’s evident that the process model with the least prescriptions (Kanban) requires more discipline and should be in Ha or Ri category.

When to Use Scrum?

Scrum is useful when a cross-functional team works together within a timebox (sprint) towards a sprint goal. It doesn’t work when you don’t know on what item you’ll be working next and sprint can’t be planned.

Kanban Mythbusters: Limiting WIP is NOT the Goal

by ShriKant Vashishtha Leave a Comment

Kanban comes with the least prescriptions but then you find lots of fake implementations. Kanban talks about visualising the workflow. These workflow steps are columns in Kanban visual.

In many fake implementations these columns become the siloed boundaries of the individuals working there. They maintain the WIP for their workflow step and just keep working within that boundary.

In software development for instance, developers may keep working within their WIP limit and may just want to limit work-scope to keep on development. Other workflow steps may become outside of their preview.

The WIP limit in such cases becomes static.

But such implementation of Kanban doesn’t help anyone.

Everything may be happening by the book, i.e. visualization of the workflow and limiting WIP. But still it may not help anyone just because visualisation and limiting WIP is not the goal. Limiting WIP is mere a mean to manage flow. In this story, people may be limiting WIP but if flow keeps stopping or keeps getting delayed at different workflow steps, it will not help anybody.

A workflow with lots of delays or bottlenecks

One may need to change WIP limits further to optimise flow and have a tab on the flow on continual basis.

The goal is not limiting the WIP. The goal is to have optimized flow.

Kanban Mythbusters Series

There are other posts on Kanban Mythbusters series which you may find interesting

If You Need Kanban in Scrum, You’re Probably Doing it All Wrong!!!

by ShriKant Vashishtha 7 Comments

The original idea of Scrum came from a 1986 HBR article “The New New Product Development Game“, written by Hirotaka Takeuchi and Ikujiro Nonaka. The teams at Honda and elsewhere reminded Takeuchi and Nonaka of the game of rugby and they called this style of project management “Scrum,” a short form of the term “scrummage” where the game is restarted when the ball has gone out of play.

So what’s so significant about rugby scrum?

In rugby scrum, the ball gets passed within the team as it moves as a unit up the field.

Scrum is all about everyone doing everything all the time. It’s an important point to remember as otherwise, Scrum becomes yet another framework with 5 events, 3 roles, and 3 artifacts.

The foundation of Scrum encourages one-piece continuous flow.

So in a Collaborative Daily Scrum, instead of answering 3 daily Scrum questions, a team looks at the Scrum board and plans on how to swarm or mob to finish the top PBI (Product Backlog Item) on the board.

It may happen, depending upon the tasks identified for a PBI, 3-4 people decide to swarm and finish it. And then the rest of the team picks the next PBI.

Daily Scrum is a sprint planning in small. You replan the sprint every day.

If a team is working like this, there should be couple of stories (depending upon size) in progress at any point in time.

So you see, if a team decides to swarm or mob, one doesn’t require to set explicit WIP limits anymore. The disciplinary act of stopping at numerical WIP limits is not required as that becomes part of the system.

The team focuses on finishing existing PBIs before picking anything new.

As we discuss the key idea of collaboration (swarming or mobbing) here, it’s important to understand that the idea of “swim-lane Scrum” (each team member individually taking ownership of a PBI through the stages of the process) doesn’t really work. It blocks the delivery pipeline as any PBI a tester may work on comes after a few days, a week or so.

At that point in time, a tester may get multiple stories to test at once and may become the bottleneck. That kind of scenario is not the ideal state of flow but is more like a Scrumfall in which work arrives in a batch after a period of time.

Kanban Mythbusters Series

There are other posts on Kanban Mythbusters series which you may find interesting

References

Streamline Your UAT and DevOps – Kanban Boards

by Avienaash Shiralige 4 Comments

In my earlier post, we discussed using planning boards to improve your backlog planning and eventually to improve your planning flow. Main project workflow remained same.

Note: People landing on this post directly, please read earlier post to get context of the problem.

This team was using 2 week sprint model for execution. Often stories got completed(tested), but left on the scrum board UAT pending. All real users were on-field consultants, hence not easily available for UAT. This reduced team throughput(velocity). Team decided to change their approach and modify their definition-of-done. They decided to have a done column before UAT. Post demos relevant stories were moved to done. In-fact they did multiple demos to product owner all through out the sprint as stories got completed. They configured their execution scrum board as shown below.