Abstract
I’m going to step into a minefield, because in this post, I’m going to share my subjective experiences with Scrum, and I’m going to share the reasons why moved from Scrum to XP + Kanban. I’m using the minefield metaphor, because every single sentence I’m going to share can be exploded with good explanations, mostly from advanced scrum practitioners.
Again, this post is going to be very subjective, and is based on my experiences from the last two years. So please keep this in mind, and be gentle when you share a comment.
The Background
Every organization is different. Ours is a strange one: we inherited Scrum, while the organizations we were working with were still doing waterfall. Scrum has a very different terminology, and since nobody else is doing it, they do not understand us. We had a lot of problems from misinterpretations. Story points are a good example.
For example, we told the project management that we are going to deliver 400 story points. They asked in reply how much that was in man hours? We answered that in Scrum we don’t count man hours, we are working with story points. They insisted on the man hours, and since they pay our bills, we gave in and made an estimation in man hours. Almost the same happened with sprints, because the higher-level organizations had release cycles of six months, while we had sprints of two weeks. This means that we deliver a lot of features in one giant step, and lose all the benefits of continuous delivery, like faster feedback on our product. And the list goes on.
After a while, I had the feeling that we are doing several things unnecessarily, and our management does not understand our output, and they don’t care what we are doing internally. Some of us made conversions between our Scrum measures and the company-required measures, which turned out to be a disaster. No one can make a good conversion in this situation. We started to fail, but not at the beginning, but at the worst place ever: around global delivery dates. Additionally, we spent two years trying to change our environment, and the way how people think in this environment. We failed at it, of course. The environment is huge, one small organization cannot make a difference, unfortunately.
My first thought was that we may be doing Scrum wrong. And the next one was that maybe Scrum is not the agile method that we should choose. There are lots of methodologies out there, we should try them out, and after that we’ll see whether we did Scrum wrong, or it just wasn’t for us. Henrik Kniberg has a very entertaining and thoughtful presentation on this topic. I highly recommend reading it.
So I decided that we are going to try out the Kanban methodology. The principles of Kanban would help us handle frequent changes and the diversified work item backlog. However, Kanban isn’t a software development methodology like Scrum. You cannot do Kanban, you need a process on which you apply the principles of Kanban. I usually hear the expression that “We are working in Kanban”, which is partially true. Actually they are working according to their process following Kanban principles. There is a difference. A very well known and good example is Scrum-ban: it is a Kanban system which is applied on the Scrum methodology.
We needed a process under Kanban, and I chose eXtreme Programming. I needed something without an exact requirement on iterations. XP also talks about iterations, but it is not based on them that strictly. DSDM was a candidate for 5 minutes, but it is also iteration-based. Crystal was also a candidate, but since we already have experience with XP, we know its principles – although we still have to practice –, I chose XP.
The Reasons
Again, the following sentences are valid for my current status.
Flexibility
Our environment changes a lot. Once I took the time and counted the number of changes. We had one change per day. In order to be efficient in such an environment, I need something very flexible.
Scrum is as flexible as the sprints are short. For a “one change per day” situation, I need a one day long sprint. It is an overhead: planning meeting in the morning, coding around noon, demo and retrospective in the afternoon. It is possible to do this with longer sprints, but every time a change shows up, the sprints need to be terminated. I admit this statement is a bit rigid, but it is by the book. Let’s divide the changes into two parts:
-
change on organizational level
-
change on team/task level
If the project decides that a certain feature is more important than the features the teams are working on at the moment, we are talking about a change on organizational level. In Scrum, you have to finish or terminate the current sprint, start planning the new feature, build up a product backlog etc. In Kanban, the tasks of the new feature can be put on the top of the teams Priority Queue, and the teams can start working on them as soon as a resource becomes available.
A smaller change can make some trouble as well. We don’t have the luxury any more to take some work - e.g. sprint backlog -, and tell the rest of the world to leave us alone until we are finished. For example, the team commits to three user stories. So far so good. They start working on the first two, but the product owner comes by and tells the team that he re-evaluated the product backlog and now a forth user story has a higher priority than the third one, which the team has already committed to. By the book, in this case neither the product owner nor team can do anything, because the commitment has been made. Of course, there are ways of solving this situation such as sprint termination - when the product owner terminates the sprint -, or cheating and simply switching the user stories. In Kanban, the third, not started user story goes a bit down in the Priority Queue, and the forth comes to the top.
*I feel that the reaction time of Kanban is better than the reaction time of Scrum. **Kent Beck referred to this in his “Software G Forces: The Effects of Acceleration” presentation at SDC2010. He said that if an organization wanted to do weekly delivery it had to switch to *Kanban.
Continuity
In Lean and Kanban teams are having a flow. It is hard to define the flow, but imagine a continuous end-to-end value stream between the customer’s request and delivery. In layman’s terms, the flow represents everything what happens after the customer asked for something, until this something is delivered. The flow is like a river. The calmer and more predictable this river is, the best for everybody. Unfortunately, Scrum is not that calm. The implementation starts slowly with a planning meeting, then it gets faster when the end of the sprint comes, and stops for a day for sprint review (demo and retrospective), and starts again slowly. I feel that the planning meeting and sprint review unnecessarily interrupt this flow.
I like the idea of the demo and the retrospective, and I can accept that the demo should happen always at the same time, because it is better for the customer. But I don’t see the benefit of having scheduled retrospectives. Teams should improve themselves all the time, there is no need for a separate meeting. If something turns south, the team shall stop working and discuss the situation right on the spot. I’m hearing quite regularly the phrase “I’m going to raise this problem on the retrospective”. I’m asking: why wait until then? Let’s do it now!
This is true for planning meetings as well. Why is it necessary to wait with planning? Do it when it is necessary. Anyway, I’ll come back to the planning meetings later.
These meetings make the flow unnecessarily unpredictable. This is not healthy. I prefer the calm flow, in which things happen, and the reaction to those things happens right after. I prefer Kanban, because things like improvements are happening continuously, which make the work/flow smoother.
Focus
I’ve seen several scrum boards, and they were usually in a state similar to this:
None of the user stories are finished, the sprint is almost over, a flat line has appeared on the burndown chart, but everybody is working on something. More precisely: on six somethings.
There are several reasons why this can happen. The most common cases are:
-
Everybody is doing what she knows best
-
Developers move on to the next story after the implementation tasks of the current user story are done
Not only doesn’t any of these help to build up a cross-functional team, but they risk the demo. If you start three user stories and start working on them in parallel, there is a good chance that you won’t finish any of them before the end of sprint.
With a WIP limit, the situation above can be solved. With the limit, the team can put a pressure on itself to finish something before starting to work on something new. In this case, we are talking about Scrum-ban:
Kanban and WIP limits help the team to stay focused and always/continuously deliver something. #### Wasting Time
To eliminate waste is one of the Lean principles. Companies - not just IT companies - are doing their best to reduce waste. Our waste manifested in time spent on things which were not necessary at that moment. When I say waste, I’m referring only to the time spent, because we are working in hours, our estimations are in hours, and our customers pay us based on reported hours. In our case, wasting time equals wasting money.
I consider the task breakdown of planning meetings a waste. Usually, teams commit to several user stories during planning meeting, and do task breakdowns afterwards for each user story. During the sprints, we measured the number of unplanned tasks, and the ratio between planned and unplanned tasks was almost always 1:1. This fact suggests that we wasted some time breaking down tasks which changed afterwards. Additionally, sometimes it happened (not just with us, but with people I know in other organizations as well) that a user story wasn’t finished and was moved to the next sprint. In this case, the team had to re-evaluate every task and determine whether they are still valid. It is another good place for wasting time.
On the other hand, Lean and Kanban advises to make decisions late as possible. In other words, do task breakdown - if you need it all - when the time is right.
Customer Perspective
Technically, the Scrum Team sees the product from the product backlog perspective. The customer is behind the product owner and/or the scrum master, and the team does not know too much about what she would like to have in her software. If these are not clear to the whole team, they cannot implement exactly what the customer wants, in other words, the team may deliver features in which the customer has small interest, or no interest at all.
System thinking can solve this situation. David Joyce has a nice presentation about this topic. System thinking can be done in Scrum, but it fits more into a Lean or Kanban way of working. #### Resource Handling
I mentioned before that our environment is changing, but this is not the only change we have. Our team setups are changing as well. One of the pillars of Scrum is the assumption that the team setup does not change. We don’t have this pillar, which makes commitment and estimation very hard, because the measure it’s based on - the velocity - cannot be determined. You can combine the velocity with the focus factor to make it more realistic. It will help a bit, but it is not a silver bullet.
focus factor = (actual velocity) / (available man days in the actual sprint)
estimated velocity of the next sprint = (focus factor) * (available man days in next sprint)
source: Scrum and XP from the Trenches
Nevertheless, velocity and focus factor are the things which the customer and project management don’t take care about at all. They want to know when the feature will be ready. I assume you can imagine the accuracy of an estimate that was made using a velocity of a changing team. Additionally the velocity is calculated for each sprint. If a user story is finished in a sprint, it will not count in the velocity of the previous sprint, but will increase the velocity of that sprint. After exposing this fact, people start doing the worst thing ever: calculating average…
I feel that the lead time from Kanban is a much better alternative. It will tell the team and the management how much time the team needed to finish a certain item. Everybody can understand the measurement of the time spent, there is no need for equations (like focus factor), and unnecessary calculations (like average). There is a difference between the following two sentences: “Our velocity in this sprint was 6”. “We needed 30 days to finish this user story”. I feel that the second sentence has more information, and raises more questions: “30 days? It is a month. Why did we need so much time?”
Additionally, large organizations tend to compare features and teams. “If a team finishes a feature with an average velocity, the other team with a similar setup will finish another feature with the same velocity. Let’s use that velocity for estimation.” I think everybody has been in a situation where a similar sentence has been told. You cannot compare velocities, because the are team specific values. You cannot compare lead times either, because they are also team specific.
There is one more thing in Kanban which is very helpful when it comes to resource handling: the WIP limits. I talked about them before in a different context. Kanban is a pull system, which means that the teams are pulling/fetching work based on their current workload and limitations. For example, have a team with four members and with a WIP limit of 4. This means that the team can work on four work items in parallel. When someone from the team finishes her current item, she can take a new one. The Kanban system prevents the team from taking on unnecessary workload which would usually mean unnecessary pressure on the team. If she has to leave the team for some reason, the WIP limit can be changed to three, and the rest of the team can continue the work. After she joins again, the limit shall remain three for a while, until she learns everything she missed while being away.
In Scrum, this cannot happen. The product owner kind of pushes the work on the team, and since there is no system preventing this push, the team might end up having more work than it’s supposed to have. Additionally, there isn’t any good indicator on the team’s possible output in ScrumKanban, but in it is available.
Communication
I have shared my thoughts on daily stand-ups in another post.
Progress
In Scrum, teams have different burndown charts, one for the iteration, one for the backlog, and maybe - in a good case - for the releases. Usually, teams are using the iteration backlog burndown chart which shows how much time is left from the iteration. I feel that the charts we were using weren’t helping the team, the project management, the product owner nor the team leader. Different teams had different interpretations on how to draw the chart, and if the management or the team leader wanted to understand what their current situation is, we had to ask them, and they had to teach us how to read their chart. This is a waste.
Additionally, the customer or the project management does not care how much time is left in the current iteration, they are interested in the whole flow, they would like see tendencies and data that help them with estimates and prognosis. I prefer cumulative flow diagrams, because the are more informative to the team, and project management can understand it as well.
A burndown chart (source: wikipedia):
A cumulative flow diagram from Henrik Kniberg (source: InfoQ minibook):
A Cumulative Flow Diagram:
The cumulative flow diagrams tell me much more about the overall flow. One can draw them for Scrum as well, that’s for sure, but the diagram is really for Kanban.
Conclusion
I cannot predict what will happen to us after the Scrum -> XP+Kanban transformation. I know that Kanban helped us reaching our goals with test, maintenance and firefighting teams, so I hope it will help us with development as well. There are very good scrum teams out there, so are kanban teams.
Any comments?
comments powered by Disqus