Sprints and Compelling Goals
There has been a debate in the Scrum and Kanban communities about having iterations (sprints) or not. I am worried that this blog post will generate flame wars and rants. Thus, there will certainly be some energy that will be lost. My hope is that this post will generate real debates and discussions so we can learn from each other’s opinion.
I have been developing software in Scrum for a long time and coaching many teams and organizations adopting Scrum. Therefore, I have been exposed to a lot of situations and feel I have integrated the fundamentals and the theoretical foundations of Scrum.
My general feeling, which you will see expressed throughout this blog post is that the Agile community is falling into the trap of looking for optimizations everywhere and is losing sight of some fundamentals about complexity, creativity, teamwork and commitments.
When I first heard about Kanban, I was intrigued and read about it and even applied it in some situations I felt it could be helpful. There are a couple of nice things that Kanban brings to the table but I also think that it breaks some fundamental things that make Scrum work.
Within sprints, Scrum suggests a simple workflow with sprint backlog items going from ‘To Do’ to ‘In Progress’ to ‘Done’. I have certainly seen some Scrum teams have way too much work ‘In Progress’ and using Kanban techniques to limit the amount of work in progress can certainly help. I also do not think it is necessarily a bad idea that a mature team establishes a more defined workflow and uses Kanban techniques to control its flow of work but going too far (I have seen a Kanban board with 10 columns corresponding to stories’ statuses) in that direction will reduce the possibilities of emergence that creates true performance in self-managing, multidisciplinary teams.
Getting to the actual debate of having sprints or not. Some Scrum proponents say that not having sprints may be problematic because the team needs to hold regular retrospectives to accelerate learning. While I do agree that holding regular retrospectives is absolutely essential, I think that a Kanban team could do regular retrospectives while not completely applying sprints.
I think Ken Schwaber has a much stronger point. In his Waterfall, Lean/Kanban, and Scrum blog post, he presents sprints from the point of view of the complexity theory.
A container is a closed space where things can get done, regardless of the overall complexity of the problem. In the case of Scrum, a container is a Sprint, an iteration. We put people with all the skills needed to solve the problem in the container. We put the highest value problems to be solved into the container. Then we protect the container from any outside disturbances while the people attempt to bring the problem to a solution. We control the container by time-boxing the length of time that we allow the problem to be worked on. We let the people select problems of a size that can be brought to fruition during the time-box. At the end of the time-box, we open the container and inspect the results. We then reset the container (adaptation) for the next time-box. By frequently re-planning and shifting our work, we are able to optimize value.
Vincent also brings an interesting viewpoint in his recent post Scrum is not about project management
.
While explaining the notion of container, Ken mentions above: “We put the highest value problems to be solved into the container.” I would like to push this a little further and relate it to planning and commitment. I have always insisted in my Scrum classes that a successful sprint planning is not about delivering a sprint backlog, it is first and foremost about having a team committed toward a goal that is compelling for them as a whole including the ScrumMaster and Product Owner. I believe, this is one of the fundamentals to create creative hyper-performing, self-managing teams that can sustain.
I have felt during the last few years that as a community we are putting too much focus on the concept of velocity and, therefore, many teams are un-passionately identifying their commitment based on their velocity and do not get to the true nature of what it means to be committed toward a compelling goal.
Before you throw tomatoes at me, I am not saying that measuring velocity is useless. I am saying that while it is useful for a team to measure and be aware of its velocity, I think we let it drive too much the commitment decisions of the team. Some tools are in my opinion putting too much emphasis on using velocity to drive the sprint planning process.
This belief of the importance of being committed toward a compelling goal was reinforced recently while reading the following book: The three laws of performance. Here are the three laws presented in the book:
- How people perform correlates to how situations occur to them.
- How a situation occurs arises in language.
- Future-based language transforms how situation occurs to people.
I will not try to summarize the book here. I thought it is useful to mention this reference because I think it links the importance of creating an environment in planning sessions that enables the team to choose a goal that is compelling for them to some fundamentals of human beings.
In summary, I suggest to use sprints as defined in Scrum because when done in the true spirit of Scrum, they enable a team to look at the highest value problems, imagine a compelling future, and use all of the thinking, collaboration, and creativity possible to put together solutions and plans. Then, you leave the people alone within the container of the sprint to apply their professional skills, without interruption so they can concentrate and focus on their work. This is the core of them being creative people doing creative work rather than resources being managed to optimize productivity.
