Why? Can't some tasks wait until next week? Is it so important to finish absolutely everything before the weekend? No, it’s not that important. And all this is due to the fact that "Carrying out tasks is bad."
Scrum is no longer quite an Agile development methodology
I have come to the conclusion that there is too much emphasis on the work process in Scrum. Or, at least, people pay too much attention to it, which is expressed in the following:
- It is okay to finish the user story on the last day of the sprint. But finishing work next Monday is already a "task transfer".
- - ( , ), , , , , .
- , , , . , , , ( , ).
As a result, it turned out that Scrum no longer helped us to achieve the goal. This method of project management was now limiting us.
With all of the above, I can note that my team members began to feel dissatisfied with what was happening. This affected the quality of what we created. The programmers were more concerned with meeting deadlines than with achieving the desired quality level.
At this point, we started looking for other ways to organize work, looking for another agile framework that would better fit the way we work.
Then we found Kanban (kanban).
What is Kanban?
Kanban is a production management method that originated at Toyota in the 1950s. At the time, Toyota used a board with three columns: Planned, In Progress, Completed. This framework allowed Toyota to more efficiently allocate resources in situations where bottlenecks arose somewhere along the production line.
Then, when it became clear that using Kanban could increase the speed of software development, Kanban was transferred to the technology arena.
Comparison of Scrum and Kanban frameworks
In recent years, Scrum and Kanban have been battling to become the leading agile framework. Despite the fact that Scrum ranks first , kanban is gradually spreading more and more. What if you compare them?
If we take Scrum as a basis and compare it with Kanban, we get the following:
- , ().
- .
- «». , .
- , , .
- () -.
A more detailed comparison between Scrum and Kanban can be found here .
Kanban gives the development team a fairly high level of flexibility. User stories, in comparison with Scrum, are executed in a freer manner. But freedom is responsibility. While Kanban does not require developers to commit themselves every two weeks, using this method of managing development has its own controls. These are, for example, metrics such as cycle time and system throughput.
It's all about metrics
It is impossible to assess the effectiveness (or inefficiency) of work without specialized metrics. Let's take a look at the metrics used in Scrum and Kanban.
▍Scrum Metrics
When applying scrum, the following metrics and graphs are used:
- (velocity). , .
- , , (commitment vs. done). , , .
- (Burndown Chart). , .
These metrics are unlikely to help you improve your workflow.
“Speed” does not measure the rate at which finished product subsystems are released. This metric only measures the number of completed work steps that are relevant to a user story. If a story takes longer than planned to complete, this metric is meaningless.
“The ratio of the developer's commitment to the volume of tasks completed” should not be considered a metric at all. This “metric” compares commitment to results. Needless to say, this can cause people to close and reopen tasks just to get them done.
Burnout diagram is something that I personally never paid much attention to. This is mainly due to the fact that such charts often look something like the one below.
Burnout Diagram
Why is this so? Let's say you start with a blank board and start working in parallel, for example with three user stories. These stories are likely to be worked on at the same speed, which is why you can see such powerful downward movements in the burnout diagram. Moreover, if there is only one tester in the team who must test the results of work on all tasks, then he will be the team's bottleneck.
▍Kanban metrics
I believe that metrics are the most important of Kanban's strengths. Kanban has many different metrics to help you better understand what's going on with your team. For example:
- Team throughput The number of user stories that were completed within a given time period.
- Cycle time The number of days it takes to complete the history work since the start of the work. Metrics such as confidence intervals are used here. The most common is 85% trust.
- Cumulative flow diagram Such a diagram allows you to visualize the process of solving problems based on user stories. This diagram should look something like the one shown below.
Cumulative Flow Chart
There is a plugin for Jira that allows you to take advantage of all these metrics. This is ActionableAgile for Jira - Agile Metrics . It helps explore metrics relevant to team performance using the same platform used to manage work.
Kanban adaptation
The use of "pure" kanban does not provide for some of the operations that are required when using scrum. But this method of project management is flexible enough to allow, if such actions seem useful, to be added to the workflow.
Retrospectives are one of the most important types of meetings. It is at these meetings that team members can talk about what they have achieved, what has not gone very well, and what can be improved. A retrospective is a calm event where you can talk about your problems and congratulate those who have done an excellent job on their success.
While flashbacks are not necessary in Kanban (they are held at the end of each Sprint in Scrum), we found them valuable and did not want to skip them. In fact, we even started doing them weekly, rather than every two weeks as we used to. This allowed us to react more quickly to the occurrence of any problems. We also use these meetings to analyze team metrics and check workflows for problems and bottlenecks.
We have saved one more element from our Scrum times, which is optional when using kanban. It is about estimating the time required to work on a user story. This is done in the course of clarifying the tasks that go down in history. Scrum uses these estimates to better understand what will fit in the sprint. You might think that since there are no sprints in Kanban, story evaluation is unnecessary. But actually it is not.
Estimating the time it takes to complete a user story helps to ensure that all team members have the same understanding of the scope of tasks that need to be completed while working on the story. If someone gives the story a grade of 8, and someone - 3, it is obvious that we need to continue discussing this issue. Someone may, when assessing the timing, take into account some problems that others do not know about. In someone's understanding, the scope of user story work should include something that others do not consider as such.
In fact, all this pushes the team members into discussions.
When something like this happens, it becomes obvious that not everyone has a clear understanding of how much work needs to be done on a certain user story.
Another common scenario looks like this: the whole team gives the story's laboriousness a fairly high rating (usually everything that is more than 8 points). This speaks of uncertainty. This means that either we are talking about a lot of work, or about solving very difficult problems, which makes the team members unpleasant. In such a case, it is best to divide the user story into several smaller stories and define the goals of the work more clearly.
Outcome
Scrum will forever remain in our hearts as the first widespread agile methodology. But as companies move towards continuous deployment schemes, the use of time-limited sprints no longer makes sense.
There will always be special projects in which Scrum can perform well. However, given the fact that companies are increasingly using agile methodologies, Kanban will gradually come out on top, displacing Scrum.
What suits you best? Scrum or Kanban?
