A few days ago I was talking to a colleague and he told me “I’ve convinced my boss to start using Scrum”. “Great!”, I replied. But then he started to describe his situation and the problems he is having. And the main problem was that they still didn’t have a product backlog. And his question was “What do I do before I’m ready to do my first sprint?”. This is not exactly the issue I would like to discuss, but it reminded me of another problem I see in agile methods, and it’s the idea that “all sprints are equal”.
Let’s analyze some differences between two iterative and incremental processes: Scrum and UP (or RUP). One significant difference is that UP has the notion of Iteration Phase, or Iteration Type. This means that not all iterations are equal. And this makes a lot of sense to me. Not all iterations are equal because when you start a software project there are many unknowns and things you have to analyze and think about. And when you are about to deploy a system to a production environment or release it to customers there are many other things you need to do that are different from what you do during construction. This doesn’t happen all the time, but it happens often. And then you start seeing agile teams that do “Stabilization Sprints”, or “Release Sprints”. I’m sure those are forbidden words for many agilists, but at least I was relieved to read a post by Mike Cohn about release sprints where he describes a Bank that manages a 13 million LOC core system that needs them. Believe me, they are not alone.
I think Agile methods should put more focus in these issues, which are very relevant in many projects. And give practical and specific advice on how to do all this while being agile. In other words, I don’t think minimizing the potential differences in sprints is a good idea.
So, in this case, the problem I see in Agile methods is not related to what they say, it’s to what they don’t say.
Tags: Agile Methods, Release Sprints, Scrum












But they _do_ say it (you have to look for it).
I recommend Ken Schwaber’s original paper on Scrum:
http://jeffsutherland.com/oopsla/schwapub.pdf
They are called “Pregame” and “Postgame” phases there. It’s true that this is not very well-known
Cheers.
I know about the pregame and postgame. I’m referring to something slightly different. One is that most talk is about sprints and not pregame and postgame. That paper says very little about them, and I think there are some key issues there. Another one is that, although this may sound strange, the view of “pregame, game, postgame” has some “waterfall” thinking. I prefer a more transitioned approach to all activities of development. And to think about different types of sprints.
Hi Santiago
There are a lot of talking on how you start an (agile) project. Many teams use a Sprint 0 to get an initial backlog.
Just a couple of examples:
Jeff Patton (http://www.agileproductdesign.com/) have some works on that. Also Joke Vandemaele made a presentation on Power Workshops (http://www.slideshare.net/agiles2009/agiles-2009-power-workshops-kickstarting-your-agile-project-joke-vandemaele)
This is not “a problem in Agile Methods”, in the sense that it is solved in every team using agile in some sense, as long as the team run successful.
So I’m curious, where do you see the problem?