Tobias Fors

I have a new short article up on the Scrum Alliance site, where I look at Scrum from the perspective of closure. Don’t miss this weekly column, where good little articles pop up every now and then. Last week’s was by Ken Schwaber on the topic of sprint reviews.

Magnus Ljadas på Citerus håller snart en tvådagarsworkshop på temat testdriven utveckling och refaktorering. Missa inte detta tillfälle att förstärka din förmåga att hantera dessa kraftfulla verktyg!

Many problems we’ve traditionally had with understanding, communicating and implementing solutions for user’s needs are reduced or go away as agile development lets us shift our focus from requirements documents to frequent conversations about actual, current, needs.

Still, these things in no way mean that we should stop thinking about requirements, even written ones. We’ll still be facing them even when the terminology and the means of handling them change. And context is key, as always: if you must have very formal written documents, if you really must, well, then you must.

With no further ado, here are some books (see: it’s not a bad idea to write things down from time to time) that have helped me understand this aspect of communication in our projects.

• To begin with, we need to understand that at the core of the challenge of understanding user’s needs lies a deeper challenge: that of knowing what the problem really is. This is what Gerald Weinberg and Donald Gause explore in their entertaining little book Are Your Lights On?, a true must-read in this context.
• Next up, something completely different. Or not. While expressions like “requirements gathering” may have some believe that requirements are like pretty little flowers waiting around to be picked and catalogued by a jolly gatherer, this act of finding user needs is not seldom pretty challenging: we’re talking about facing and synthezing a multitude of opinions from a bunch of stakeholders, after all. So, we should be able to talk about potentially contentious issues in a productive way. In come the authors of Crucial Conversations, with their collection of principles for helping yourself keep even your challenging interactions with others sane.
• On a possibly less far-fetched side, Mike Cohn’s book on User Stories describes a middle ground between the often bloated use case format and the context-disabled IEEE-style “the system shall” requirements. Simple and usable, but beware: XP-people will sometimes angrily remind you that they, not Mike, invented user stories.
• In software projects, we have a long and sad history of estimating the cost of requirements, but not the value of them. Donald Reinertsen takes us one step beyond the (powerful and typically sufficient) product backlogs and teaches us how to bring back value to the table. See: Managing the Design Factory.
• I think I liked this next one too, even though a few years have passed since I last read. Since its Gerald Weinberg again, I’m not worried about recommending it: Exploring Requirements: Quality Before Design, by Mr Weinberg and Donald Gause.
  

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 a while, 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 cliff-hanging 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.

Every thing 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. The 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 reason 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 its not a bad thing to embrace our human need for closure: it helps us finish things at the same rate we start them.

Yesterday, I spoke on the topic of agile software development at the Öredev conference. Here are the slides from that talk.

I’m glad to read that Henrik Mårtensson, whose interests and knowledge I have come to respect through the reading of his blog (and even more now that I’ve met him in person), enjoyed a recent Scrum Kickstart I facilitated, and he participated in:

“It is rare to meet someone that can talk about the same subject matter for two days straight without being boring even once.”

Don’t miss out on Henriks excellent blog: Kallokain.