Product Management

Combining Scrum And Kanban: The Best Of Both Worlds

Combining Scrum And Kanban: The Best Of Both Worlds

Some organizations that use Agile approach, combine principles and practices from both Scrum and Kanban, evolving a method that works best for their unique situation. In reality, Kanban and Scrum have many common features.

Self-managed teams

Crucial aspect of the success of Scrum and Kanban is that development teams direct their own work, guided by the business goals. Both methods promote respect for people, allowing them to do their best work, providing the leaders to help remove obstacles to ongoing progress. Team members of both Scrum and Kanban projects manage their own work packages. They define their own rules for determining when a user story is ready to put into production.
Both Kanban and Scrum teams ‘get the work’, rather than asking managers to assign tasks to team members. Scrum teams take the high – priority user stories from the corporate product backlog, separate them down into small tasks, estimating the tasks and stopping when they’ve reached the amount of work to which they can commit for that time period. Instead of planning the iteration in advance, Kanban teams define how many user stories they can work on at any given time.
Scrum will provide the team a complete sprint to decide how to manage itself before the next stage, while Kanban carefully observes the process through the team every time a new story is started. This has large implication on the way that managers (masters), product owners and developers work combined. With Kanban, the team can adapt the work (its progress level) dynamically to avoid free or over-worked developers, and that is something that can be monitored by the management.

Work packages

The most obvious difference between Kanban and Scrum is in limiting work in process, versus a clear number of roles, rituals and artifacts that can be accepted and used instantly. In practice, though, there can be only a few differences. Both Scrum and Kanban prosper from well-defined user stories that can be accomplished and delivered separately, and Scrum leaves the decision to the team – how much to work on the same time, while Kanban focuses on limiting the number of items the team has in progress. Scrum does not limit the work in progress, but if you start too many stories – you may not produce useful deliverables at the end of the Sprint. A key difference factor is that Scrum measures the levels of teams’ productivity in terms of the team’s speed, and controls – how many agile points a team will score during a sprint. Kanban controls for continuous work in progress and limits the number of stories the team will accept to working on at the same time.
Scrum is optimized to produce product iterations (to the clients’ side) on a regular basis via user stories, and Kanban provides a permanent set of autonomous results and deliverables. The key advantage of Kanban is that it can control the size of work the team has in progress at any moment of time.

Planning approach

Scrum’s approach asks for estimating stories and tracking team velocity, and the number of user stories that are done in each sprint. However, all Agile teams need a way to help the business plan when some features should be produced, knowing that plans always change. Some Kanban teams count how many features were produced in a week, or the average time to produce each minimum deliverable feature. Others accept a Scrum-like approach for estimation and measurement. Kanban teams may hold planning meetings as needed, to prepare more stories for development, or they may plan at a regular frequency, as Scrum teams do.
Scrum uses a product backlog of user stories, whose cost should be estimated by the development team, and which are prioritized by the company. If the backlog isn’t populated actively, the removing stories will never get to the top of the priority list, and it becomes a problem. When the team is ready to practice Scrum for several years, you should plan two big boxes for the story cards, that are going to be pulled into a sprint. That’s not a way to make business value visible.
In Kanban, the team can adapt the work (its progress level – Lean approach) actively to avoid free or over-worked developers, in a way that can be monitored by the managers.

Try both

It would be significant for your team to decide wisely which methodology will be the most useful, depending on the type of your project. If you are creating products, you will find that Scrum is a more obvious choice. If you provide services, you will find Kanban to be a better solution for you.
A team that is adopting Agile may find it more useful to start with one model or framework, implement it as described, and then use retrospectives to evaluate where progress can be made. You should try to experiment with ideas from other frameworks and models instead of using just one. Agile development will enable you to uncover better ways to do your best work.

Today, many companies are adopting the agile approach. The need for the agile methodology has grown in the IT industry, and in a few other industries as well. In the past years, there have appeared many proponents of the agile methodology. We will describe the process with these steps:
– Iterative development, time boxed process, collaboration with the customer enforced;
– The process naturally allows involving of all team members;
– Enabling fast, recurring and confident deployments;
– Continuous integration, easy resolving of changes.
Of course, there could be some bad practices that you can personally face about agile organizations and teams:

User stories in the sprint can be changed. Sometimes the user story has the same size and has increasing importance, but it should not be changed with a less important story. In some cases the story could swap during the sprint, but not to entirely change the initial requirement. When the sprint starts, the scope is sealed and a change in the needs will imply that sprint is invalid, as the goals of the sprint have changed.
Regular team meetings. One of the bad practices is when the scrum master asks frequent status updates from the team members. This is very unnatural to Scrum, since it looks like a micro-management. Scrum needs spontaneous, energetic and involved participation from all team members, with the scrum master defining the time/content and product owner listening in for potential questions and unclearness of stories. A good way to abandon this practice is to make standup meetings optional, until the team decides to meet and learn together.
Unclear, incomplete user stories. Agile methodology provides software with no defects, with the assumption that the product owner has expressed his/her intent completely and clearly. Stories that don’t have acceptance criteria – bring misunderstanding to everyone, or cause continuous arbitration throughout the sprint, thus lowering the quality and the speed. A good way to prevent this from happening is to close the sprint and immediately close a story that has no acceptance criteria. Product owners should adapt, since their budget is limited.
Product owner is also a developer/team lead. Product owner should determine the objectives and goals of the project together with the client, and not directing engineering tasks. There could be cases where a product owner could be in the advisory board. Defining how to do the work does not only wastes the time of a product owner, but also shifts focus away from the final goal.
Scrum master is the product owner. This case is similar to a pirate becoming a captain. Aside from daily dashing to the team and immediate lack of direction, the dictating nature of this role does nothing more than interruptions in the Sprint.
Automation is not always present. With no acceptance of testing running regularly, there is no proof that everything that worked so far is still working. Without testing, new development efforts will be unclear. Unclear results almost always float, disturbing the sprint. There have to be taken enough time and efforts for automating tests and deployment.
Deliverables are not finished at the end of a sprint. Putting the product to production could be optional, but deliverable that satisfies all user stories as a set is obligatory. Some teams, especially teams with short duration sprints, choose to have a consolidation sprint, before delivering the production.
Story points have large duration. They are measures of the efforts, not in terms of time. Once you realize the abstract nature of software development, you will understand that work cannot be quantified in time, but only in complexity. “This story needs 28 hours to complete.” “It could be done in 30, but we can sum up to a week and help in planning.” That type of discussion should not be done by any team, whether scrumming or non-scrumming.
There are no software oriented stories. This happens if the team has amazing technical capabilities, or infinite hours in a day. Scrum allows patchwork, add-ons on existing software to incorporate new features. But, over a period of time, the team might end up with a fragile and an uncontrollable product. To prevent this from happening, it is important to have a consolidation sprint, or have engineering stories in the sprint. However, aside to regular stories, these stories should have a well-negotiated purpose and the end.
Backlog cleaning is a weekly meeting. Product backlog cleaning is usually a non-interactive process, where development team uses the backlog as a knowledge base, permanently adding comments and updating story sizes, as they learn more about the product owner’s goals and intent.
There are some companies that disrupt the scrum process, though few and far between. Scrum, or any similar agile process, is a simple and lean process that works for developing software. It also requires complete forgetting of traditional practices and willingness to accept it completely to make it effective.

Rate this post