Imagine a Failure: a pre-mortem retrospective

/0 Comments/in /by

by Nikos Batsios

Conducting a Post-Mortem at the end of your project is a great lesson learned practice that could promote the recurrence of desirable outcomes while preventing from the undesirable outcomes!

It’s true that we – our teams, processes and organisations benefit from post-mortems, except our project! As the psychologist Gary Klein said: “A postmortem is a medical setting allows health professionals and the family to learn what caused a patients’ death. Everyone benefits except, of course, the patient.”

Instead of conducting a postmortem and looking back on what happened in your project you can try a pre-mortem just at the beginning of your project and imagine that it was an absolute failure! (alternatively think of success)

What you can expect to get out of this exercise

Creativity and openness from all team members to express their concerns in a safe environment when their project is still in the planning phase! Teams can get ideas and actions on areas that if implemented well could increase the chances of success!

How to do it

Creating the “script”

Before starting your pre-mortem, it is really important to illustrate an imaginary failed state, a disaster,  of the project that is about to start. Adding details, using pictures and creating a “script” or a story could help the team to actually be part of this unwanted state! It can be, for example, an “aggressive” email that your team received from a customer’s CEO describing the frustration with the project delivery trigger and he needs your immediate support to resolve all these problems!

Why this has happened? – 30 minutes

After discussing this project imaginary failure story ,  all team members brainstorm possible causes that triggered this disaster!

  • Use sticky notes to gather all the causes and discuss them
  • Group them into common themes and
  • Prioritize the themes based on their importance and their contribution to that failure

How to prevent this imaginary failure? – 30 minutes

Discuss the themes and the identified causes. Ask team members to brainstorm and find possible solutions that will prevent the identified causes from happening in reality. The outcome should be a list of concrete actions that team members should take care of by themselves or delegate these to people who could best support them.

The team can decide to work on a few or all themes depending on the their availability, time and the importance of causes. The team can also follow-up on the actions or discuss more themes in their retrospectives at the end of each development cycle.

Keep Calm and carry on! – 5 minutes

You can close the pre-mortem with a relaxed message all participants! At the end, it was just a simulation and all participants gave their best to prevent this disaster from happening in real life! And the good thing is that you have a list of actions that might increase the chances of success! (in case this would really happen in the future)

About Nikos

Nikos Batsios´ main belief is that great teams could achieve astonishing results! Keeping that belief in mind, contributing in the quality environment creation, human relationships that will further unleash the potential of individuals, will enable teams to perform high and cooperate with one another towards the same organisation’s purpose. As an Agile Coach, I contributing towards that direction supporting and training teams and organisations to understand the importance of agile values, principles, practices and helping them see the benefits in their agile transformation.

If you have questions related to this article, please feel free to contact Nikos on Twitter @nbatsios.

Picture credits go to: Jeff Djevdet

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us please contact us: info@oikosofy.com.

What is a Starfish in a retrospective

/0 Comments/in /by

by Luis Goncalves

The Star Fish exercise is an evolution of the typical 3 questions that are used for retrospectives:

What went well?
What did not go so well?
What should be improved?

What you can expect to get out of this exercise

With this exercise, teams can get a good overall picture of what’s going on within a team, what is working and what is not working. They can get an overview what failed and what was successful in the past.

This exercise helps to identify problems and opportunities for a team. Instead of using 3 questions above, you can use 5 words instead:

1. Stop – Here you identify activities that do not bring value to a team or to a customer. These are activities that bring waste into the process.

2. Less – Here you describe activities, which require higher level of effort and bring little benefit. These activities might be the ones that were brought into the team in past, but did not demonstrate any improvements.

3. Keep – Usually these are good activities or practices that team members want to keep. These activities are already being applied.

4. More – Activities on which a team should focus more and/or perform more often.

5. Start – Activities or ideas that a team wants to bring into the game.

When you would use this exercise

The Starfish exercise is suitable for any team, it does not require any specific level of team maturity.

The exercise is simple and does not require any special occasion. The best situation to apply this exercise is using it at a moment when a team goes through several ups and downs during the iteration. It reveals both good and less positive things achieved by a team. In general, this can be a good tool for making a summary of the sprint.

How to do itstar-fish-retrospective

First, take a flip chart paper and draw the picture you see on the right. In case your team is distributed you can use tool Lino . It´s a tool that allows you to do everything you need to run this exercise.

After drawing this picture, do a brainstorming session with your team. Ask them to collect several ideas in a section “Stop”. Afterwards, give 2-3 minutes to each person to read out loud his ideas. After, take 10 minutes to discuss if everyone is aligned.

Repeat the exercise for each of the different sections: “Less”, “Keep” and “More”.

For the “Start” part, add one extra step. Use the Toyota approach, choose one single topic to discuss. You can do voting to see what the team considers the most important topic to start with. After the topic is selected, design a small strategy to make sure this topic is well implemented. This strategy might include responsible persons, the deadline, and most importantly, success criteria. In order to know if the implementation was successful, we must have success criteria outlined.

The topic, which the team chooses in the “Start” part, does not need to be a new topic for a team, it can be an improvement on something that is not working well.

Worth to mention is the order you should follow when going through the different sections. Start with “Stop” and continue with “Less, “Keep”, “More” and finish with “Start”. Starting with negative topics and moving towards the positive ones will help the team to end a retrospective with a positive feeling!

Picture credits go to: Luis Goncalves & Jennifer Whiting

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us please contact us: info@oikosofy.com.

Value Stream Mapping

/0 Comments/in /by

by Luis Goncalves

What can you expect out of this exercise

Although value stream mapping is often associated with manufacturing, it is also used in logistics and supply chain management, service related industries, healthcare, software development, product development, and administrative and office processes. Value stream mapping is a lean manufacturing technique that analyses and designs the flow of materials and information required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as “material and information flow mapping”. It can be applied to nearly any value chain. But how can you use this in your team?

When would you use this exercise

Value Stream Mapping is more suitable for mature teams. This exercise helps to show the ways a team and a system interact. People who are new to agile won´t probably understand most of the things this exercise brings. Why? As an example, the most common issue this exercise reveals is the QA/Loc documentation tail for each story. If the team is not mature enough, they won´t see it as a problem. Therefore, if you´re a mature team, go ahead and use this exercise, it helps you to uncover some complex problems.

How to do it

img_20130217_190326 (1)The easiest way to do this is to grab some flip-chart papers and tape them on the wall, then divide the space in equal intervals, each interval represents a day of the iteration. Draw a line on the Y axis, this line should be on the position Y=0. If they are doing any activity that will bring value to the customer, tell to each member to draw a line on top of the Y axis line. On the other hand,draw a line under the Y axis line, if they are waiting or blocked by something. Teams must do this activity everyday to track all different activities inside the team. Do not forget to write notes when people are blocked or in IDLE; these notes are important to be discussed in the retrospective. The possible result can be something as the picture on the right side.

Remember that all activities/tasks that are needed to accomplish a story bring value to a customer. All other tasks are a waste. In business world, customer value is an amount of benefit that a customer will get from a service/product relative to its cost. Poppendiecks in their book“Lean Software Development” describe a waste as:

  • Anything that does not create value for a customer
  • A Part that is sitting around waiting to be used
  • Making something that is not immediately needed
  • Motion
  • Transportation
  • Waiting
  • Any extra processing steps
  • Defects

If a team is very mature, all QA activities that are performed as validation instead of bug fixing or being part of development, should be considered a waste. As an example, Unit Testing, TDD, ATDD and some other techniques can be considered QA activities as a part of development. If we do a testing at the end just to validate that everything is fine, then consider this as a waste. Bug fixing can be considered as a waste too.

The team needs to do this activity everyday in order to track all different activities inside the team. Do not forget to write notes when people are blocked or in IDLE; these notes are important to be discussed in a retrospective. We guarantee you that you will have plenty of data for your retrospective at the end of the iteration.

Picture credits go to: Luis Goncalves & Improve It

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us please contact us: info@oikosofy.com.

Team Assessment Survey

/0 Comments/in /by

by Luis Goncalves

Team Assessment Survey is a great tool for a retrospective. This tool comes from a SAFe framework established by Dean Leffingwell. You can find the original assessment here. The exercise demonstrated in this blog post is an adaptation from Luis Goncalves. He also shares this exercise in his book co-written with Ben Linders “Getting Value out of Agile Retrospectives”.

What you can expect to get out of this exercise

The idea of this exercise is to analyse how teams perform in different areas and identify possible improvements in next sprint/near future. This assessment has 4 main areas:

  • Product Ownership Health – How the product owner performs
  • Sprint Health – How activities within the sprint are being managed
  • Team Health – How healthy is the team spirit within the team
  • Technical Health – How well the team has implemented technical best practices

Each of the areas has different questions, which you can rate from 0 to 5. This allows a team to visualise what are the areas that need more attention in the team. This exercise is awesome to reveal overall agile health of a team.

When you would use this exercise

Although this exercise is suitable when a team wants to understand better how well they implement agile, it does not require any special occasion. This exercise, however, will not solve specific problems that occur during the sprint, but it might acknowledge some reasons why those problems happen. For example, if your team finds many bugs during development, the problem might be that their unit testing or automation practices are not well implemented.

How to do it

It´s very simple. You will need an excel sheet. You should have 4 main areas I mentioned earlier: Product Ownership Health, Sprint Health, Team Health and Technical Health. Now create several questions for each different areas. These questions must be appropriate for your team. You can refer to questions from SAFe Team Scrum XP assessment, which you can find here.

As an example, see below 2 questions for each different areas:

Product Ownership Health

  • Product Owner facilitates user story development, prioritisation and negotiation
  • Product Owner collaborates proactively with Product Management and other stakeholders

Sprint Health

  • Team plans the sprint collaboratively, effectively and efficiently
  • Team always has clear sprint goals, in support of PSI (Potentially Shippable Increments), objectives, and commits to meeting them

Team Health

  • Team members are self-organised, respect each other, help each other complete sprint goals, manage inter-dependencies and stay in-sync with each other
  • Stories are iterated through the sprint with multiple define-build-test cycles

Technical Health

  • Automated acceptance tests and unit tests are part of story DoD
  • Refactoring is always underway

All these questions can be rated from 0 to 5, where 0 means “Never” and 5 means “Always”.

assessment During the retrospective session, the team needs to fill in the excel sheet and evaluate the team to see where they stand. For easier and more clear demonstration of results you can create a graphic, just like on the picture on the right side.

Visualising the graphic will give a team a good understanding where they stand. They should be able to decide which area they want to improve. Choose one area at a time and one topic within that area.

This exercise does not require to have a collocated team, it can also be run in a virtual setup (in a distributed team).

Picture credits go to: Luis Goncalves and jvleis

In case you are interested in Agile Retrospectives I am at the moment preparing a 10 DAYS FREE AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

If you are interested in sharing your Agile Retrospective exercise with us please contact us: info@oikosofy.com.