By Tobias Fors
Have you ever watched an episode of, say, Prison Break, and noticed how they stop for commercials just when the action is most intense? Of course you have. Those moments are called cliffhangers. You are literally left hanging for awhile, and that's a situation you want to get out of.
Psychologists have a name for this phenomenon, this need to bring stability back into an unstable situation. They say that what we're so desperately longing for in cliffhanging situations is closure. We need to close the book to be able to move on. Until we've done so, we can literally feel like we've been left hanging.
Here's my take on why iterative, incremental, agile software development is so powerful: it teaches us the power of closure.
Everything that starts needs to have an end. That which is opened needs to be closed. Sooner or later. When we do sprint planning in Scrum, we set up a situation where all parties are left longing for closure. And closure will come soon. Those things we select to work on in the upcoming sprint will, to begin with, result in divergence: the team will discuss, debate and even procrastinate, but soon enough, the need for convergence sets in. The need for closure is making itself known again. Before the sprint has ended, the team will have realized the need to test, package, and document that which was requested during the first day of the sprint. They may even have done all these things.
When a sprint does not end with closure, the feeling of having been left hanging is most obvious to the product owner—the person in Scrum who is responsible for controlling the direction the product takes. He has heard the team commit to a set of goals, and has been hanging around to see them be realized. When this does not happen, closure is missing.
For the team, this lack of closure is equally obvious. As the team gathers and performs the end-of-sprint retrospective, the reasons for why not all goals were fulfilled are discussed. This is done without the assignment of blame, but it needs to be done for closure to begin. In order to fully close the book on the goals that were not reached, the team soon works with the product owner to determine when to attempt to reach those goals again, or decide not to do so.
In Scrum, that which is selected for development must be demonstrated. That which is begun must be finished. When we finish, we are taken back to a stable state, both in a technical and a mental sense. From this stable state we can the start anew.
In its essence, what Scrum does is this: it helps us to constantly look around us and ask, “What have we begun that needs to be finished for us to be able to move on?”
Psychologists might scoff at this use of closure, but it works quite well in this context, because in software development, starting is not the hard part. All it takes is a bright idea and a few spoken words. That’s why it’s not a bad thing to embrace our human need for closure: it helps us finish things at the same rate we start them.
