Categories

Scrum has become THE revolution in the world of software development. The main philosophy behind scrum is accepting that a problem cannot be fully understood or defined at start; scrum has the focus on maximizing the team’s ability to deliver quickly and respond to emerging requirements. It came as truly refreshing in the time when projects were ruled by procedure and MS-project planning. Because of scrum:

Projects can deliver what the customer needs, not just what he thought he wanted.

Teams are efficient. They work as a unit to reach a common goal.

We have better project roles (like a product owner and scrum master), ceremonies (like daily stand-ups, grooming) and a scrumboard.

But the central question is: “are we there yet”? And the answer is: “No!”. We can optimize scrum by mixing it with kanban, which leads to scrumban.

A kanban introduction for scrummers

Instead of scrum, which is a software development framework in the widest sense of the term, kanban is a method. It, or instance, does not define ceremonies and project roles. There are two main principles in kanban I would like to highlight:

Each column on the kanban board represents a step in the workflow. So, instead of the lanes ‘todo’, ‘inprogress’ and ‘done’ like in scrum, you have ‘defining’, ‘developing’, ‘testing’ and ‘deploying’. That is a more full-stack view; a task has a wider lifecycle. This concept is also called ‘from concept to cash’; from user research and strategic planning to data center operations and product support.

Another principle of Kanban is that it limits WIP (work in progress). An example of a WIP limit is limiting the number of cards allowed in each column. The advantage is that it reveals bottlenecks dynamically. Because of the WIP, Kanban is a pull mechanism. For instance, a tester can only pickup a next work item if there are items available in de done-column of development-lane and when the WIP limit of the test-lane isn’t exceeded.

After all kanban is incredibly simple, but at the same time incredibly powerful.

What’s wrong with scrum?

The reason why we went to scrum is because we did not want the waterfall approach anymore. But, in fact each sprint in scrum has become a mini waterfall. In each sprint teams plan, try to design, develop and test. At the end the product owner reviews the completed work and decides which of the stories are shippable and ready for production. Those sprints can result in a staccato flow, which can be exhausted. With kanban we can make sprints more agile and the goal is to have a more continuous flow. In comparison with how to run a marathon? You don’t make sprints of 200 meters, but rather with a constant rate.

Scrum is a push mechanism and therefore ‘pushes’ the quality out of your product. When a sprint backlog is defined, the team is asked for a commitment. Whatever happened, a team must satisfy its commitment and at the end of the sprint the product owner must say ‘decharge’, else the team has failed. No team wants to publicly fail, so most of the time, at the end of the sprint, teams take shortcuts to satisfy the deadline. Those shortcuts are killing for quality! Asking for commitment is like not trusting the intrinsic motivation of the team. The correct commitment is visible during each standup. During a standup team members have to tell each other what they’ve done the day before. If they are working too long on a story, another team member will rebel. That is the real commitment.

One of the reasons why we do scrum is that it is better to start immediately instead of doing an estimation and a feasibility study upfront, because almost always after the study is completed, the project will be executed. The estimation at the start is not reliable and the feasibility study is just a waste of time. Isn’t that the same mistake we make with scrum with the grooming and ready sessions that causes a lot of overhead? The first overhead during grooming is that we give an estimation with relative precision. It is in a developer’s nature to argue about the story points; is it 3, 5, 8 or maybe 1 points? And that is a waste. You should only talk about the story sizes large, medium or small. Making a more precise estimation is just a waste of time, because there are too many external factors. Second, with the grooming we do a mini feasibility study. With a team we will think about a direction of the solution, which is fine. But most of the time it takes two or three sprints before it is realized in the sprint. And with all the weekends of beer in between we’ve already forgot the solutions. So one smart guy says: ‘yes, lets document it’, but that is an inefficient way for the real problem: there is too much time between the grooming and the realization.

Scrumban: the board of kanban

A scrumban board

The first column in a scrumban board is reserved for the backlog, where stories are ordered by their respective priority. There are several rules for the kanban backlog:

It is the product owner’s responsibility to fill this lane with stories, and keep it steadily supplied. The product owner must avoid creating or analyzing too many stories, because this is a waste and it corrupts with the Just-In-Time principle of scrumban. Therefore the scrumban board has a WIP-limit of 5 backlog stories.

Assure the necessary level of analysis before starting development. Each story must be analyzed with a minimum effort. That should be done in the Weekly Time Box (WTB), which will be discussed later on.

The backlog should be event-driven with an order point.

Prioritization-on-demand. The ideal work planning process should always provide the team with best things to work on next, no more and no less.

Next to the backlog-column is the tasking-column, in which there should always be at least one story that is tasked (a minimum WIP-limit). If this isn’t the case the team will task after the standup to satisfy this condition. A story is picked up from the backlog and is tasked by the team. Tip: put the tasked cards at the back of the story cards. The next columns are the realization columns. Each team is free to add, remove or change necessary columns so it suits the business. In the realization columns there should be a maximum number of stories that are worked on. If the maximum limit has not been reached, a story can be pulled from the tasking column and unfolded on the ‘to implement’ lane. Now the team can work on the tasks of the story. Each task that is implemented can be moved to the ‘ready’ lane. If all of the tasks are done for a story, the story can be moved to the next lane. When the story and tasks are ready, the cards can be moved to the right bottom of the board, so there is a new horizontal lane available for the next story.

Scrumban: the ceremonies of scrum

With scrumban we only have two types of meetings: the daily standup and the weekly timeblock. The Weeky Timeblock is a recurring meeting used for multiple purposes. It should be set up in the middle of the week. The big advantage of the weekly timeblock is that developers are distracted from their work only once a week (instead of the various of meetings with scrum).

The Weekly Timeblock contains three parts. First there is a demo of the work done. Second, there is a retrospective on the development process of the last week. Third, the team should have a preview of upcoming workitems. The team try to understand the intent of each item and provide feedback. The only size-indication a team has to make is if the story is small, medium or large. Avoid using poker cards/story points, which are too fine-grained and are to vague.

Conclusion

Scrumban is a mix of the scrum ceremonies and the kanban method. With scrumban we

Introduce the weekly timeblock (WTB). The weekly timeblock should be around 4 hours and there are no more meetings

Have a wider lifecycle of a story: ‘from concept to cash’.

Change the scrumboard to company flows and avoid the push principle of a sprint but using a pull mechanism.

Previous post

Next post

Comments

Jan, I recognize the issues you have faced and the solutions you found for them, it’s solid advice for a team. Some remarks:

1) Scrum is a framework, not a method.

2) The problems that you attribute to Scrum are actually a bad implementation of it. For instance, the commitment thing, “mini waterfall”, the number and frequency of meetings, the “push” nature (Scrum is pull, not push)…

2.1) Some things you attribute to Scrum are not part of Scrum, but part of the de facto implementation of it. Some examples: a Scrum board is not part of Scrum, user stories are not part of Scrum, and Story Points are not part of Scrum. There is a lot more freedom in the framework than the dogma that people like to attribute to it.

3) Before Dave Anderson started to market Kanban as an alternative to Scrum we were already using principles like WIP limits in columns: every good Scrum implementation has always blended a large amount of Lean in it. That the leaders of the Kanban movement claimed it for themselves did not make it something other than Scrum, and it still doesn’t.

4) Realize that what you suggest is contextual. There are just as many teams that I move from Kanban to Scrum or vice versa based on their context, and I can give you enough examples where the fixes you propose are the very worst thing you could do.

To conclude: solid advice, but be aware that it is contextual, and that the problems you attribute to Scrum are in many cases not prescribed by the framework at all, or not in that way.

1) I didn’t know the difference, but I’ll have to grap a beer tonight to understand the difference between the ‘framework’ and ‘method’ term.

2) At the beginning of the sprint: yes, the teams pull the stories to the backlog. But the way I feel it, is that during the sprint it becomes more of a push, because
it’s in teams nature to achieve their sprint-goals.

2.1) You talk about a dogma, maybe that’s true. Because the way teams and the internet perceives scrum is that all those things (scrumboard, user stories, story points) are part of scrum.

Of course I realize that there is no one size fits all solution. Thanks for your comment.

One of the things that Serge forgot to mention is the Definition of Done (DoD), which IS a part of the Scrum Framework. The DoD is how Scrum manages technical quality: a PBI is not Done until it meets its DoD – the DoD “pulls” the PBI through the system. Additionally,
in order to reduce the pressure to “complete” the PBIs in a Sprint, Scrum has explicitly removed the commitment to the specific contents of the Sprint – the Sprint Goal MAY NOT be a commitment to a specific quantity of work. In particular, the Sprint Backlog is now considered a “forecast” and not a “commitment”. Many, if not most, Scrum Trainers have become much more kanbanish in Sprint Planning: there is a chapter on this in my book: “Exploring Scrum: the Fundamentals”. Check it out…

In my understanding:
a Framework is a set of Tools and Constraints, while
a Method is a description how to use them.
Therefore the Scrum is strictly a framework, and each specific application is a unique method..

I’m always getting these terms confused, which is strange, knowing that I do understand the difference. I blame media for not naming these correctly, which leads to these methods and tools users not knowing what to name them either. Just saw a post here: http://kanbantool.com/blog/agile-tools-and-approaches-lean-xp-scrum-kanban outlining the very basic differences between methods and approaches and tools. It’s all too confusing, I’m just gonna get back to work, follow my tasks on the visual board and not think of what my approach/. method / tool is called.