How We Mixed Scrum with Kanban to Boost Project Development

You definitely want your software development project to succeed. And you are sure that the methodology you’ve chosen is the key to success. That’s why you’re reading this article.

I want to show you how we successfully mixed Scrum and Kanban methodologies in one of our projects. This kind of methodology was created gradually, though it can be used in any project under certain conditions.

Prerequisites

In our situation, the model was efficient because it appeared under these conditions:

• The development team was proactive. Developers never hesitated to suggest enhancements, UI improvements, and new features.
• The product owner had complete confidence in the team of developers, particularly the team leader.
• The efficiency of each developer could be monitored. Developers who were unproductive did not stay long in the team.
• The team leader and product owner knew developers’ abilities and were able to estimate their work.

Below, I will specify why each of these prerequisites is important. But first, some project details will help you to comprehend our mixed methodology.

The enterprise knowledge management system being developed by our team was a B2B platform. Its customers are world-renowned brands; they use the platform for efficient knowledge exchange between different groups of experts. Each customer needed the system to be customized for their specific demands. This is why, in addition to developing new system features and enhancing existing ones, the development team spent some time customizing the system. Under these conditions, task estimates were required more by customers than by the product owner.

Scrum Elements

The following elements of the Scrum methodology were used in our model:

• Product Owner. The product owner is the project’s key stakeholder; he/she makes final decisions about the global system enhancements and their priority.
  Unlike in the straight Scrum methodology, in our model the product owner together with the team leader distributed tasks among developers and made rough estimates for each task.
• Scrum Master. The Scrum Master helps the team to be as productive as possible by using the Scrum process.
  Because we did not follow 100% of the Scrum methodology, we could not call our team a Scrum Team.
• Product Backlog. The product backlog is a prioritized list of desired features and enhancements.
  Unlike Scrum, we didn’t have sprints; thus, a Sprint Backlog wasn’t appropriate for our methodological model.
• Planning meetings. In our model, we planned tasks for the whole release. The planning period took around two months and was provided by the product owner and the team leader. During this period, they planned features and enhancements for the subsequent release, distributed tasks among developers, and estimated the time required for each task.
• Daily Scrum Meeting. This is a brief daily meeting that helps set the context for each day’s work and helps the team stay on track. All team members are required to attend the Daily Scrum Meeting.
  

Kanban Elements

The main Kanban feature used in our model was the Kanban Board, which is a great work and workflow visualization tool. However, unlike in strict Kanban, in our model tasks received the following statuses:

• Open. The task has been created and assigned to a developer or tester. The executor (developer or tester) has not started work on it.
• In Progress. The executor has started work on the task.
• Requirement Clarification. The task is unclear for the executor and needs clarification on some details from the creator. When choosing this status, the developer/tester needs to specify what is unclear.
• Unit Integration Testing. The task has been executed by the developer and is awaiting integration testing.
• QA Failed. When being tested, the task has failed. The tester has to write details, what exactly has gone wrong.
• Review Board Failed. The code review has failed.
• Audit Confirmation. The task has been successfully tested and is ready to be checked by the application engineers. (An application engineer is a person in the product owner’s team who is responsible for ensuring the system works correctly.)
• Closed. No Action. The task has been closed because it’s execution is no longer needed.
• Closed. The task has successfully passed audit confirmation and is completely done. This task execution has been accepted by the customer.

Process in Our Model

In our methodological model, the whole process was organized in the following way.

Our distributed team included three subteams:

1. Management team. Created tasks for the release; checked the system was working correctly; communicated with the system customers to identify their needs and coordinate their requests with the system’s feasibility.
2. Development team. Executed development tasks.
3. QA team. Provided testing of the executed tasks.

Releases. We planned one release per year. At the beginning of each release, the product owner, together with the team leaders, decided which tasks should be executed, assigned each task to a developer and estimated the time required for its execution. The total estimated time for each developer was not to exceed one year.

Estimates were pessimistic because the aim was to execute every task planned. Deadlines were adaptive and depended on the tasks being performed: a new system version could be only released when all tasks had been closed.

Developers’ work. During the planning period, developers provided refactoring, bug fixing, and upgrading of libraries. If a developer had tasks assigned to him/her, they would select a task and start working on it. Even with pessimistic estimates, some tasks took longer than expected. The main goal was to perform each task in the best way, so that it was successfully tested; it is better to close one task without failing than to start working on a dozen tasks that cannot be closed because of the “QA Failed” status.

Once all of a developer’s tasks had been closed, he/she could carry out internal tasks focused on code improvements. Our developers were proactive and had already suggested a number of code, architecture, and UI enhancements.

Architecture and UI enhancements should always be approved by the product owner and/or the system customer. The following kinds of tasks don’t require approval and should only be accepted by the team leader:

• Code reengineering when regression is impossible;
• Installing new libraries;
• Changes in code that are able to improve the system performance (if the team leader perceives a risk of regression, the change should be approved by the product owner).

As the product owner confirms a proposition, the development team creates a demo version of the enhancement, which is shown to the product owner (and the customer); thereafter, the approved enhancement is developed.

Pros and Cons

Like any methodology, and especially mixed methodologies, our model has its pros and cons. I will start with the disadvantages, because they are in the minority.

Cons:

• During early development stages, it is difficult to estimate tasks correctly. Each task should be divided into smaller subtasks to enable more accurate estimation.
• The team members should exclude the possibility of idle time. Otherwise, they will lose the product owner’s confidence. The team leader should monitor developers’ performance and remove those with poor performance.

Pros:

• The product owner doesn’t require exact estimates; this is why each developer can maintain the quality of development.
• Based on workflow visualization, it is easy to find out who has caused a QA or code review failure. Everybody understands their responsibility.
• The team is motivated. Their proactive attitude usually meets with a positive response from customers, which arouses team’s interest in the results.

Here, I have described a successful case of our use of mixed methodology: Scrum + Kanban. We took some elements from each of these approaches and this allowed us to increase our developers’ performance, encourage their sense of responsibility, and involve them in creating and enhancing the system, rather than only developing it.