in

Ative at Work

Agile software development

Ative at Work

maj 2007 - Posts

  • Retrospectives - Adapting to Reality

    Accelerated learning or "Inspect and adapt" is one of the key lean principles. It is the central feedback loop that keeps our work in sync with the real world.

    In agile one of the ways to do this by performing a "retrospective" at the end of every iteration. Its focus is gathering data and turning it into actionable improvement activities (kaizen). Esther Derby and Diana Larsen have written a wonderful little book on this: "Agile Retrospectives: Making Good Teams Great". It has a wealth of information on how to get the most from retrospectives and includes a number of useful tools.

    Derby and Larsen use a five-stage structure for the retrospective: setting the stage, gathering data, generating insights, deciding what to do and closing the retrospective. Inside this structure they provide a lot of data gathering tools. For example, Diana Larsen recently blogged about a tool for data gathering called FRIM. It works by drawing a diagram where we group the  observed issues by frequency (how often the issue occurs) and impact (how much it impacts the project). Then we use this diagram to pick the most important issues to address for improvement activities in the next iteration.

    In our agile consulting work we have visited quite a lot of projects that do "evaluations". When this is the case the kaizen step is usually missing. Instead people just fill out forms saying "as usual we had trouble with integrating the application.". Needless to say, the kaizen step is the point of the whole excercise. Merely gathering data is just bureacratic waste.

    One of the most common ways to transform the observations into actionable kaizen activities is to name the key issues for the next iteration. This technique is called "Do, Don't and Try" (Alistair Cockburn describes a retrospective activity called Reflection Workshop with "Keep, Problems and Try" in his book, Agile Software Development).

    In this activity we mark out three sections on a whiteboard:

    "DO" is where we put the things we should do or keep doing. This is all the things that makes us more efficient. We don't list all the good practises, just the ones we are currently learning and need to do consciously until they become habits. An example could be "Talk to the customer about the requirements before we start implementing them."

    "DON'T" is the section with all things that we do that lead us to step on the usual landmines. These are the fires we are currently fighting and the things we want to stop doing. Tom Peters calls this a "To Don't List". Example: "Don't over-architect the application to support speculative future requirements".

    The third section, "TRY", is the section for new things we want to try out and evaluate. Example, "Try adding automated acceptance tests with FIT".

    Everybody contributes. As the team names items we cluster them so similar items are grouped in one. Then, the next step is selecting the most important ones as focus for the next iteration.

    We normally recommend a simple process called "dot voting" where each team member puts a dot in each area to mark what they rate as the most important item. This is usually enough to make it clear what the most important issues are. We post these on a big visible "Do / Don't / Try" chart in the team working area. They give focus to the things we should do consciously for the next iteration. Then, as part of the next iteration retrospective, we look back and evalutate the results.  

    We keep the things that help us for as long as they keep helping us.  

    There is a very important point that Jan Elbæk mentioned in a workshop on agile development with Scrum that we hosted recently. When we name the critical issues most often the best action is to do nothing! Merely being aware of the bad behaviour is often enough to stop it. Try this light-touch approach first. If we give in to the urge to create bureaucratic control systems to steer our way around the problem in the future there is a big risk that the bureacracy stays after the specific problem is solved. This is the recipe for building enterprisey organisations.

    That is not our goal, however. The goal is to solve the problems at hand, not to load the process with bureacracy.

  • “Implementing Lean Software Development: Practitioners Course”, by Mary and Tom Poppendieck

    Having attended the two day “Implementing Lean Software Development:  Practitioners Course”, I encourage you to join Mary and Toms classes or speeches if you get the chance, they are very inspiring and their knowledge about lean and agile are amazing. 

    Mary and Tom have done a great job in transforming Lean principles from the manufacturing environment to software development. The course take you trough the Lean history, give you a brush up on the theory behind Lean and give you a lot of god techniques, tools and ideas on how to improve your existing projects and use the power of Lean.

     A few “lessons learned”:  
    • Success factor for implementing Lean: look at the whole supply chain, not only development or test. Think products (end to end) and not only projects.
    • Use pull rather than push. Be aware of utilization: an operations manager will react when a servers cpu utilization is getting close to 100% - but what about people utilization …
    • When implementing Lean it isn’t enough just to use Just-in-time and stop-the-line. It is the people doing the actual work that have the potential to make it a success. They have the good answers and ideas.
    • All queues and stacks of work is WASTE. Remove the cues, improve the cycle time and get better overall performance and quality. Value stream maps are a powerful tool to identify queues and their size.
    • Without automatic tests you are asking for trouble. Don’t buy the “we don’t have time to implement automatic tests” excuse, if you wait your problems will grow…
    • And NO it is not ok to have a backlog that contains work for more than 3 iterations, including ideas for the future – get rid of the WASTE and focus on the important stuff that adds value to the customer.
© Ative Consulting ApS