In this blog post I will tell you my experiences in using Scrum. It will be fully transparent and I’m not holding anything back. I will share the mistakes and triumphs we had along the way.
A scrum (short for scrummage) is a method of restarting play in rugby football.
Some years ago when the company I work for merged with another, we brought with us the use of Scrum as the framework for software development. They had been using a ”home brewed”-method up until then. Approximately half the development department had previous knowledge of using Scrum, while it was new to the other half. An introduction to Scrum was held for all, but no other formal training, then we kicked off the first sprint.
The result was not a total failure or a huge success, but something in between (to be specific the actual focus factor, calculated after the sprint, was 39%. While the planned focus factor was 70%). The retrospective after the sprint talked about ”everything is new” and ”too much unplanned”. At least is was not as ”unstructured and ad-hoc” as before, so we decided to continue planning and running Scrum sprints.
Here are some of the problems we faced in the following sprints:
- Stories stalled (from outside dependencies)
- Fuzzy requirements
- Poor communication between teams
- Bad estimates
- Problem with finding good Scrum Masters for the teams
- Teams were not kept together for more than a few sprints. We moved around persons between the teams.
We struggled along, now and then we hit some high notes (actual focus factor close to, or above, what was planned before the sprint) but mostly it were between 40-60%. Now you should not just stare blindly on the actual focus factor to deem success or failure, but one problem with not completing your sprint goals is the ”remaining tail of tasks” left after each sprint. If it is just a couple of days of work, it can be fixed in between sprints or included in the next sprint. But if it’s more (say above 10% of the total planned work) people start to question the whole idea with using Scrum. We particularly had one person not seeing the benefits of time-boxing, ”We work and have the sprint open until everything is completed!” (not using the possibility of taking out less prioritized tasks from the sprint to keep the time boxing and the ”steady state delivery” that it gives). The teams were also struggling with finding ”small enough chunks” to deliver in each sprint, almost all stories seemed to span over several sprints with no logical deliveries for each.
The flat line syndrome
To sum up the result from most of our sprints please see the picture below.
Scrum burn-down chart with what I would like to call ”the flat line syndrome”.
What is the syndrome and why is this the end result? In the beginning of the sprint the progress on the tasks are good. All the developers can start working and they feel confident that they are taking steps forward. Often the planning only took half a day (not included in sprint) so the team has a half day ”head start” working with sprint tasks.
In the middle of the sprint dependencies between the tasks starts to occur. To be able to complete task A I need the same methods that are developed in task B, but that is not finished yet. Some type of tasks may also have come to an end in the sprint. For example there are no more GUI tasks to do for the GUI developer. And to ”best use” the GUI developer he or she is fed with other GUI tasks from the Product backlog (not planned in the sprint from the beginning).
At the end of the sprint, we enter a ”third phase”. Now tasks become hard to complete because there are no specific DoD (Definition of Done), written for them. For some reason the first 90% of a task is pretty straight forward, but those last 10% can take ”endless time” to complete. This is human behavior I guess, there is always ”some more things” to fix. Some developers also likes to ”hang on” to a few tasks for a whole sprint to ”polish them to perfection” instead of moving on to another task, i.e., to have the sprint goal in first focus, instead of the specific task.
One other quite common reason for no process (flat line) at the end of the sprint is that the team is not working on the tasks that were planned for the sprint in the sprint planning meeting, The reasons for this:
- Other tasks (not foreseen on the planning) has emerged when working with the sprint tasks. Those tasks must be fixed first before the actually planned tasks can be attacked.
- As mentioned, some type of task (like GUI development) has ”gone dry” and therefore developers with that competence (GUI) works with other tasks not planned from the beginning
- Things have happened. During the time that passed since planning, other tasks with higher priority has emerged that the team must handle ”on the focus factor” (i.e., on the time that was not planned for the sprint. Using a focus factor of 70% for sprint work that leaves 30% for other work).
So what have we learned? Here is a list of thing we should have done better:
- Use metrics to see if we made improvements over time. Without proper metrics you only have ”gut feeling” if the changes you make is for good or worse
- Keep the teams together – We learned this after a while, and then we saw real improvements
- No real continuous improvements (kaizen) to the process. The things that came up on the retrospectives went around in circles (too small teams -> too large teams -> too small teams, too short meetings -> too long meetings -> too short meetings etc.)
- No proper Scrum training from the beginning.
So I guess you are wondering if we have solved all of our problems using Scrum? The answer is yes, and no. We started to use Kanban instead, all teams wanted to do that.