Category: Agile

  • The Power of Closure

    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.

  • Slides – Am I Agile Now? Öredev 2006

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

  • Positive Reviews Just In

    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.

  • Video med Jeff Sutherland

    Jeff Sutherland beskrev tillsammans med Ken Schwaber det ramverk för utveckling av mjukvara som vi idag kallar Scrum. I en utmärkt och intressant video på InfoQ berättar han om detta.

  • Kurser om Scrum och DDD snart på Citerus

    Under hösten kommer vi på Citerus dels att fortsätta med våra populära utbildningar i den lättrörliga arbetsmetoden Scrum, dels ha en del andra intressanta evenemang. Se här till exempel:

    Eric Evans budskap är minst sagt angeläget. Han vill hjälpa oss mjukvaruutvecklare att utnyttja kraften i domänmodeller för att lösa våra kunders problem. Det handlar om ett nytt fokus på att använda våra kunskaper om begreppsmodellering för att dels prata med kunden på kundens sätt, dels implementera objektorienterade lösningar på ett elegant och effektivt sätt.

    Vår senaste workshop med Eric Evans var mycket populär. Samma gäller vår senaste Scrumkurs. Båda evenemangen är upplagda för att aktivera deltagarna att lära sig genom att göra, snarare än bara genom att lyssna.

  • The Visible Planning Calendar

    Planning is great. Too bad it’s so hard. Too bad it so often results in weird plans and deadlines that jump around in the calendar like drunken fleas.

    Here’s an idea (yet untried by me) for a counter-measure: The Visible Planning Calendar. Goal: to make planning more transparent by at least making dates somewhat less jumpy. Contents: an agile, or at least iterative, development methodology, plus some extra rhytm to it.

    Just an idea. Inspired by others. Credit given in pdf above.

  • Using your Scrum senses

    I’ve written a short piece on the importance of learning to use your senses to gather information. It’s published on the scrumalliance.org site.

  • Where Did the Time Go?

    Efficiency in an iterative mode of working requires that we have little overhead in all our processes. For example, if building a release candidate takes us several days of manual work, we will have a hard time working in two week iterations, since so much of the iteration will be consumed by release work. Add to this slowness in detailing specifications and test cases, and we’ll get even less product created in the iteration. Then add cumbersome and manual design/coding (developers have not yet learned how to utilize whiteboards to visualize holistically, and refactoring tools to fluidly change the source code), and we start to understand why so many development organizations have a hard time adopting iterative modes of development.

    What to do? Well, for starters, maybe we can try to look at our organization and how we work, and see where the time goes. Create an overhead scorecard, a simple table outlining how long activities take. Or try the value stream mapping technique, in an attempt to really nail down how you spend your development time.

    Then, attack your worst bottleneck. And, no, you do not have to be an expert in theory of constraints or some other thinking technique. Just scrutinize your own behaviour, and do something about the things that look bad. The need for this way of approaching challenges is, paradoxically, becoming greater and greater in the software industry as ideas about new ways of working spread. I see lots of people interested in learning about things like Scrum, lean, theory of constraints (of which I know very little myself), test-driven development and so on, but when it comes to going home to your back yard and do some cleaning up, many fail.
    So: try approving a bit, pluck some low-hanging fruit (there’s typically lots of it). When you start to see the limits of this simple approach, go ahead and learn about advanced techniques. There’s lot to learn out there, but you don’t have to know it all to be able to improve.

  • Donald Reinertsen till Sverige, 3 maj

    Donald Reinertsen är konsult och författare till “Developing Products in Half the Time” och “Managing the Design Factory”. Hans approach är särskilt uppfriskande i dessa tider, när metod ställs mot metod. Lättrörligt mot traditionellt. Istället för att ge sig in i såna strider föredrar Reinertsen att utforska hur olika faktorer faktiskt påverkar varandra. Han går tillbaks till ekonomin, och visar till exempel hur kostnaden för en försening kan ställas mot värdet av en ny feature.

    Den 3 maj kommer Reinertsen till Sverige i regi av IVF Industriforskning och utveckling.