Kanban or Scrumban

The Agile company can be recognized by a presence of Kanban boards with index cards of user stories which are put into multiple columns based on their status. Such 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 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 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 of customers is increasing as well.
• There is no time for learning and knowledge sharing.
• There is no time for an 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 tiredness of experts and complexity.
• Shorter development time due to business pressure and late reqs discovery.

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

People think that such effort is just a loss of the 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 problems listed above.

An investment of just 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 a 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 an 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 for 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 new scrum team, we suggest starting with Scrumban board.

Scrumban board is based on the Kanban board (well kanban means a card ?) but comparing to the 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 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 type helps identify missing tests or other parts of the definition of done, especially if you use a different colors for different type 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 us 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 more intensive feeling of collaboration and team is more proud about results.

Is Kanban bad?

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

How we were dealing with this in ScrumDesk

When we started 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 the one thing consistently. A transparency and discipline.

At the begging, our boards were full of subtasks. As business owners, we were able to identify how discipline are new team members, how the work is distributed among the team. How good are they in a discovery of facts which weren’t provided in the user stories. How much testing we had to do, how much effort 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 budgeting of the sprints while still have 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 story nearly every 2-3 days.

There are 1-3 urgent bugs in 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 Kanban house than Scrum.

Kanban is the next level for Scrum teams. Deserve such simplicity first!