First, we recognized the need to have an objective way to select an Agile methodology. For those already facing this challenge, we suggested a framework aimed at guiding managers in constructive negotiations with stakeholders, while choosing an Agile methodology. At the same time, we want to avoid myths, stereotypes and personal preferences and prejudices. Sometimes we are keen to apply our own personal preference when choosing an Agile methodology.
The Framework Approach
The framework is composed of 4 key elements:
- Comparison table
- Set of criteria
- Relative importance of the criteria
I started this post based on a past case with a client. Our stakeholder wanted Scrum because of some positive perceptions about Scrum methodology including:
- Scrum proves to be an effective delivery model in other teams in the program
- Scrum has short and well-defined iterations
- Scrum offers a “commitment on the scope” practice
- Scrum quickly allows one to see team performance
This is a simple technique to compare two or more models. In our case we are comparing Scrum vs. Kanban.
Set of Criteria
We are going to use this case to better see how important aspects may be easily ignored that in the end, heavily impact results.
Let’s investigate if the methodology is able to support business needs and at the same time naturally scale while the business is growing. In Scrum we have velocity and the backlog size. In projects with a high level of uncertainty, Scrum metrics can help forecast realistic plans, improve direction, reduce delivery risks and wisely budget. With Kanban, we measure how quickly a business task can reach production. All Kanban practices are tuned together to help the team see how to improve metrics, such as lead-time.
What about scaling? In Kanban we scale up when we need to improve throughput. The theory of constraints tells us that there exists one and only one bottleneck in the system so the goal is to find the weakest place in the process and improve Kanban; for instance, by increasing the team's capacity. The easiest way to identify bottlenecks in Kanban is to set up tougher work-in-process limits so that the sum of all limits should not be greater than the number of people in the Kanban team. In the graphic we see that the QA phase is the bottleneck. To improve the system’s throughput, adding more QA resources might be a good idea. Here are the most common solutions for eliminating the bottleneck:
- Switching non-QA specialists to the QA team. This solution will improve lead-time, but can negatively impact the motivation of developers and other non-QA specialists.
- Unload QA specialists by shifting some responsibilities to developers and analysts; for instance, by having analysts write test cases up-front, or by having developers create automation scripts. This solution can safeguard the non-QA specialists’ motivation but requires some time to introduce the new practice.
- Add more people to the Kanban team. This solution improves both lead time and throughput.
In Scrum a different approach is used for scaling up. Usually a good Scrum team has a well-estimated “Product Backlog” and known “Velocity.” This information is enough to build a Release Burn-down Chart. Let’s explore an example of a chart below. There we see that the team has started to work on the project with a certain velocity, which was not enough to accomplish the “Product Backlog” phase by December. In order to improve burn-down dynamism, a decision was made to add one more team, enabling them make the initial deadlines.
Let's see what was happening with our “Skeptics.” Our stakeholders confirmed that for new initiative the business needed an approach to speed-up the delivery of individual business tasks. We agreed that Kanban would serve that need better than Scrum.
Team size is another important aspect we tend to ignore. In Kanban we don’t have limits on team size, whereas in Scrum, the team size should not exceed 9 people. For instance, if we have 15 people on the initiative, Scrum requires splitting the group into 2 or 3 teams. This can be problematic if we have some unique talent and it’s impossible to form 2 or 3 equal feature teams. Another thing to keep in mind is that two or more Scrum teams will require more time for synching, so you should be prepared to pay for communication overhead.
In the case of our “Skeptics” we had a team of 14 people with some unique expertise. Our stakeholder agreed that in this respect, Kanban would be much easier to set up.
Each methodology has its own approach on how task management should be organized. We cannot avoid what Scrum prescribes without risking permanent conflicts between the development team and stakeholders. We have to answer two questions if we want to try the Scrum model.
First, how often we are going to change priorities? If priorities are meant to change faster than the Sprint length, it will lead to serious conflicts between the Scrum team and business stakeholders. Frequent changes in the middle of the sprint often require significant re-planning efforts. When we asked our stakeholders, they told us that their initiative required quite a bit of flexibility on the team’s part because they anticipated that the priorities could change every two or three days.
How quickly do we have to deliver on the business task? If the business stakeholder requests the Scrum team to deliver some features ASAP in the middle of the sprint, it can result in another conflict because the Scrum team is working on a plan to deliver working increments by the end of the sprint. This is why some Scrum teams use the “red line” to increase flexibility, but this workaround may lead to a significant drop in performance.
Coming back to our “Skeptics,” when we asked our stakeholder, she admitted that the nature of business implies multiple changes in priorities and certain critical tasks with SLAs around 2-3 days.
Size of the Task
In Kanban we focus on improving the time-to-market of each individual business task. Kanban is a very metric-driven methodology. For example, the lead-time metric helps us see if we are improving or not. However, Kanban metrics require that business tasks be of relatively the same size, otherwise it’s hard to gain any value from the method. We wouldn’t be able to predict or estimate delivery dates lacking the reliable measurement approach for lead-times. If we have large business tasks to deliver and these task-projects can be broken down into smaller tasks, then Kanban can work.
For business projects that aren’t as clear, Scrum will serve better. We experienced situations when large and unclear projects were getting to the Kanban board and staying on the same place on the board for weeks. There is no value in such visualization. We decided to use Scrum instead.
When we asked our stakeholders about the expected size of the task, we found that this initiative was designed to serve relatively small business requests. Therefore, in this category, both Scrum and Kanban could work.
A Scrum team involves mandatory roles. It is highly recommended that there is a dedicated Scrum Master and Product Owner in each Scrum team. Violation of this rule would lead to serious risks in delivery. I have never seen anyone have a problem finding a good Scrum Master and a brilliant Product Owner for one Scrum team, but what if there are four or even ten teams? Are we ready to hire at least five dedicated Scrum Masters and find five dedicated Product Owners for ten Scrum teams?
We definitely don't recommend using Scrum if you’re not ready to pay for dedicated people to fill the roles.
In our case, the client was ready to provide a Scrum Master and Product Owner per team if we split 14 people into 2 teams. So here, both Scrum and Kanban are a good fit.
The requirements structure can vary pretty drastically. It may appear as a backlog of features for a new application or it may appear as an everlasting queue of enhancements for a legacy application. This is a classic factor for choosing between Scrum and Kanban. If the project is long-term and there are already some epics and a set of expected features to be implemented, it is an ideal case for Scrum. That being said, there are some precautions. For large-scale Scrum setups (three or more Scrum teams) it’s good to split the “Product Backlog” up by areas. Scrum teams serving the “Area Product Backlog” can work with minimal dependencies and integration with other teams. This allows effective collaboration between Scrum teams and stakeholders. You can see a similar structure below:
The truth is that new product development can easily go along with the Kanban method. In Kanban we can use “Swimlanes” from splitting requirements flow into several independent streams, though it is possible to work with one swimlane which can be served by a large team.
In our stakeholder’s case, it was possible to split requirements. Therefore both Scrum and Kanban would work.
How does the delivery model perform when we have assigned resources in multiple locations? This is a good question to explore. Scrum was initially designed to boost performance in co-located teams. This can be achieved by shifting control from the management to the development team. The Scrum team becomes self-organized. The development team autonomously decides how to achieve the Sprint Goal. Without extensive communication and work on soft skills, we may not achieve the expected performance boost. The best description of Scrum team dynamics can be found in Bruce Tuckman’s model. Good performance requires passing certain stages of Tuckman’s models. In the case of dispersed (not co-located) teams there is the potential risk of getting stuck in the very first “forming” stage forever, because the next stage, “storming,” is hardly possible without being physically present in one location with other team members. I had a great chance to participate in “Distributed Scrum” development. We started as a dispersed team, where the Scrum team consisted of developers from London and Kiev. This set-up was extremely ineffective. Then we used Distributed Scrum, where we formed fully functional co-located Scrum Development Teams in London and Kiev. Cross-team collaboration was not great until we started to use high-end communication tools like SMARTboards, video-conferencing, Google docs, a TV-status board, frequent business trips and other means to effect that sense of connection and presence. Here is the deal: effective Distributed Scrum is possible only when the customer is ready to invest in communication tools and cross-location business trips.
Then Kanban model, on the other hand, has different organizational dynamics. Kanban is not very dependent on co-location, making it possible to implement effective Kanban via traditional communication means. Minimal setup for distributed Kanban requires a comprehensive online board, like a JIRA Kanban, and good telephone technology. The claim is that Distributed Kanban is less problematic than distributed Scrum; however, let’s not deceive ourselves - good investment in effective communication leads to faster delivery and better productivity. Well-done Distributed Scrum with high-end communication is far better than Distributed Kanban with a minimal set of communication tools.
In the case of “The Skeptics,” our client confirmed that they didn’t have any plans to spread resources out across multiple locations.
It is common knowledge that Scrum leads to profound organizational changes, whereas Kanban takes the current organizational model into account and encourages evolutionary improvements over time. The frequently asked question about Scrum is what is one supposed to do - with Chief Architects, Project Managers, QA Managers and other current organizational roles? Scrum is strict. The Scrum team should consist of the Product Owner, the Scrum Master and Developers. Other roles should be either incorporated into the Scrum Development Team or considered “Stakeholders.” Stakeholders communicate all their needs via the Product Owner - they don’t have direct access to the Development Team.
For “The Skeptics,” close communication with many area stakeholders was necessary, making the pure Scrum model problematic.
Usually in self-managed Scrum teams, the knowledge transfer process between unique specialists and other developers is much faster than in any other team. In Scrum this happens organically. The entire team is responsible for achieving the Sprint Goal. In a Scrum team there is no excuse for failing to deliver on a product increment because a specific expert is absent. Given that the Scrum team starts proactively pulling out and elucidating critical knowledge from experts, I have rarely seen a situation when a Scrum team was dependent on an external specialist to accomplish its task.
Kanban, however, doesn’t have an internal mechanism for a profound knowledge transfer process. If we see that unique talent could risk the project, I would suggest using Scrum.
Our “Skeptics” had some unique specialists but the customer didn’t consider the above possibility a big risk, so both Scrum and Kanban passed in this category.
Relative Weight of Criteria
This is where we decided to stop, since we had investigated the most influential criteria, and we had already determined that Kanban would be a better overall fit for our case. If, however, the results were split pretty evenly between Kanban and Scrum (5:5 or 6:6, for example), we would take another look at the relative weight given to each factor. This final score is applicable only to the "Skeptics" case. In your case, the score will be different by a probability of 99%!
The final step of this exercise was to decide which to use, Scrum or Kanban. For us (Agile coaches), it was important that our stakeholders made the decision, instead of the classic case where the client relies solely on the consultant’s recommendations. Our goal was to help our stakeholders to make a carefully weighed and considered decision, after considering important variables. Through the exercise, if our client insisted on going through with Scrum adoption, then everyone would share equal responsibility for risks associated with it.