From Scrum to Kanban – Part 3

Scrumban Level 1 Kanban is focused on delivering value. To deliver greater value, we must ONLY perform actions that add value to our end product – working, usable software.In my experience, I have found that most developers on a software team have different understandings of the value added steps when working on a task. The typical Scrum board that I see on projects looks like the following:$0 Here’s the confusion – every team member has a different definition of “In Progress.” The steps taken during “In Progress” differ among team members, which causes confusion and frustration amongst the team. Some team members write unit tests, other do point and click testing. Some team members request code reviews, others do not. Some team members comment their code, others write a detailed specification. So what does it mean for work to be “In Progress???”

To answer this question we have stumbled upon the first step of going from Scrum to Kanban – Scrumban Level 1.

To define the value stream, we must ask ourselves two questions: What steps do we take that add value to our product?

What steps do we perform that do NOT add value to our product?

Typically question #2 is the most important. A team must align around following practices that add value and flee from those that don’t. But agreeing upon the tasks that add value for YOUR TEAM is easier said then done. Because once you decide on these steps you must be disciplined, in fact FANATICAL in enforcing them.

For example, most teams believe code reviews are important – but how many teams actually perform code reviews on a regular basis? Very Few! Why is this? Because when a sprint is about to end it’s convenient to skip over reviews. Just mark it done!

To remedy these problems, our team defined our value stream:
Each step in the value stream must be defined with great clarity. Every team member must know what it means to complete each step in the value stream.

As you see, our first step is Specify. We believe it’s so important for our application to have strong documentation that we write the specification first. That way it does not get skipped over or done poorly. Next we Execute. We define this as testing and coding the application. Each team member is crystal clear on the expectations of what test cases must be written and passing for a task to be considered done. And finally, we Review our code. A team member is cannot move the task to Done until the code is reviewed. We believe requiring this step is critical to delivering a quality product.

What are the “right” steps that define your value stream? That will differ from team to team. Different ideas on the software development process combined with varying skill sets means these steps must be tailored to your team. Your team may not need a high level of documentation – so don’t add this in your value stream!

Just remember, once you’ve determined these VALUE ADDED steps – be fanatical executing them!  In your daily standup don’t allow a team member to move a task from one section to the next without an explanation of the work that’s been completed.