Kanban or Scrumban?

The Agile company can be recognized by the presence of Kanban boards with index cards of user stories which are put into multiple columns based on their status. Such a board looks simple and easy to handle.

For agile teams, this is very welcome due to a low level of bureaucracy, high transparency, and easiness of usage. Win-win-win scenario for the team, business, and project management as well.

But is the Kanban board with user stories the best for your team right now?

The biggest concerns we observed in many companies which try to implement Agile are:

• Resources bottlenecks. One or two experts in a particular domain or technology within the team.
• Shortage of IT experts.
• Complex product development due to new technologies.
• The speed of the industry is increasing significantly every year.
• The demand for customers is increasing as well.
• There is no time for learning and knowledge sharing.
• There is no time for innovation or research. For prototyping.
• There is no real clarity of requirements as there is no time to build it up.
• Bugs leakage is increasing over time due to the tiredness of experts and complexity.
• Shorter development time due to business pressure and late requirements discovery.

All these things often block teams. The question “What about breaking down the requirement into smaller  activities?”  Ends up with an impulsive answer “No!”. What are the reasons?

People think that such effort is just a loss of productivity, effectiveness and adds more bureaucracy. But the facts indicate the opposite in most of the cases. Especially in the case of immature Agile teams with the problems listed above.

An investment of just a little more time in the breakdown gives the team more clarity in the discussion about the problems they try to solve together.

The domains which were specialties of only a few people will be possible to understand by others just because of transparency and more details thanks to subtasks.

The Example: VISA payment

To illustrate gains let’s talk about the real-life example we observed while coaching the new scrum team.

The team developed a core company system that must be able to offer electronic payment.

There weren’t so many people in the team who understood the Visa payment process. Typical “expert bottlenecks problem”. In this planning session, we asked how they are going to implement the solution. The first answer was the same as in many other teams.

“You do not understand the problem so why to explain it. It is just a loss of the time. I’ll implement that in the same time instead.”

Exactly this behavior is the reason why you can’t go on vacation. It is the reason why you have to work at home even at night because of all the fireworks.

But once they realized, thanks to subtasks, there is necessary to develop some database table for the invoices, the payment transactions, and transaction status, suddenly more developers were willing to do that even without knowledge of the VISA payment process.

Testers understood how the solution will be built and what exactly needs to be tested and how. The knowledge transfer has just been started by such a small step.

Scrumban

For the new Scrum team, we suggest starting with the Scrumban board.

Scrumban board is based on the Kanban board (well kanban means a card 😁) but compared to Kanban, the board keeps user stories and subtasks at the same time. User stories are put in the first column. Only subtasks are moved around the board to indicate the status.

Using this board your team will:

1. Understand the user story more from the implementation perspective.
2. Learn more about the business problem.
3. Estimate work better thanks to smaller subtasks.
4. Sharing of the work in the team much better. Leveling is much easier and transparent.
5. The amount of subtasks by different types helps identify missing tests or other parts of the definition of done, especially if you use different colors for different types of work.
6. Team members start to feel more confident to choose new business areas.
7. Missing details are discovered much faster.
8. Smaller subtasks need to be updated on the board more often. The team builds a habit of transparency.
9. Burndown chart measuring subtasks is more granular hence the team can adapt much faster.
10. The team is naturally split into micro teams of 2-3 people implementing one user story together. There’s a more intensive feeling of collaboration and the team is more proud of the results.

Is Kanban bad?

No way! I just want to say that based on experience new teams should start rather with the Scrumban board first.

The kanban board is something you should deserve once you built up the discipline of transparency, willingness to work in unknown areas, and collaboration in the team. 

How we were dealing with this in ScrumDesk

When we started the development of the ScrumDesk web edition, we started a new collaboration with a couple of freelancers we didn’t know at that time. We requested one thing consistently. Transparency and discipline.

In the begging, our boards were full of subtasks. As business owners, we were able to identify how disciplined is new team members, how the work is distributed among the team.

How good are they in the discovery of facts which weren’t provided in the user stories? How much testing do we have to do, how much effort do we need to invest into code review, merging, deployment? We were able to measure the cost of non-development tasks as well. Even operation and support, meetings, etc. Such transparency simplified the budgeting of the sprints while still having consistency in the quality of results.

The impact is huge. The team completes user stories in planned order. We are able to deploy new user stories nearly every 2-3 days.

There are 1-3 urgent bugs on average per 3 weeks sprint. The team is more focused on new stuff which gives them better motivation.

We have much more facts before we have to change the Sprint. Shouldn’t we do that? Well, yes in Scrum, but after all these years now we are more at Kanban house than Scrum.

Kanban is the next level for Scrum teams. Deserve such simplicity first! Check The Kanban Glossary and What is the difference between Scrum and Kanban..