Coaching

now browsing by category

 

Getting Value out of Agile Retrospectives: “Boat Exercise”

Hi guys, in this post I will explain how can you use Boat exercise as a tool for a retrospective. I learned this exercise few years ago when I worked together with Vasco Duarte. Few weeks ago I saw an upgrade in Pedro Gustavo blog.This exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by me and Ben Linders with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it within your colleagues.

Here you can find my previous blog “Getting Value out of Agile Retrospectives: “High Performance Tree””.

What you can expect to get out of this technique
From my experience, this technique is quite appreciated by teams because of its simplicity. This exercise helps teams to define a vision where they want to go, it helps them to identify risks during their path and allows them to identify what slows them down and what actually helps them to achieve their objectives.

When you would use this technique
I believe this technique is quite simple and does not require any special occasion. Although, it might be interesting for situations when a retrospective is conducted with more than one team at the same time. I had a situation, not long time ago, that two teams worked together and because of their level of dependency on each other, they decided to conduct a common retrospective because of some ongoing issues. Using this exercise can be extremely interesting, because we simply put the name of both teams on the boat and we remind everyone that we are on the same boat rowing to the same direction.

This technique reveals all good things and less positive things performed by a team.

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

How to do it
photo This retrospective is quite simple. First we draw a boat, rocks, clouds and couple of islands like it is shown on the picture on a flip chart.

The islands represent teams´ goals/vision. They work everyday in order to achieve these islands. The rocks represent the risks they might encounter towards their vision. The anchor on the boat is everything that is slowing them down on their journey. The clouds and the wind represents everything that is helping them to reach their goal.

Having the picture on the wall, write what is the team vision or what are goals as a team. After that, start a brain storming session with the team allowing them to dump their ideas within different areas. Give ten minutes to write their ideas. Afterwards, give 5 minutes to each person to read out loud their ideas.

At this point discuss together with the team how can they continue to practice what was written on the “clouds” area. These are good ideas that help the team and they need to continue with these ideas. Then spend some time discussing how can the team mitigate the risks that were identified. Finally, together with the team chose the most important issue that is slowing the team down. If you do not find an agreement within the team about the most important topic that should be tackled, you can use vote dots. At the end you can define what steps can be done in order to fix the problem and you can close the retrospective.

As many other exercises, this exercise does not require a collocation of a team. You can use, for example, tools like Lino, to apply the exercise on non-collocated teams. This tool allows us to do everything what we need in order to run this exercise.

What do you think? Your feedback is always extremely important for me, so please leave me your comments.

Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: .

I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.





Thanks guys,
Luis

Getting Value out of Agile Retrospectives: “High Performance Tree”

Hi guys, in this post I will explain how can you use “High Performance Tree” created by Lyssa Adkins. This exercise is deeply explained in the book: “Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches and Project Managers in Transition” by Lyssa Adkins.

AThis exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by me and Ben Linders with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it within your colleagues.

Here you can find my previous blog “Getting Value out of Agile Retrospectives: “How to start an effective Retrospective using Car Brand exercise””.

What you can expect to get out of this technique
This is a great exercise to help a team to define a vision for themselves. Lyssa referred in her book: ´ “metaphors” are a core skill that are taught in professional coaching courses.´ This is exactly what High Performance Tree is, a metaphor to help teams to create a compelling vision for themselves; a way to create a path that leads to High Performance teams. This exercise helps many teams to find what are next steps to achieve High Performance; this is what we can expect with this exercise.

When you would use this technique
High Performance teams is an exercise that can be used in several different ways by any team, but because depending on a maturity of a team, the exercise will be used in a a different way. We just need to define the maturity level of the team and adapt the exercise to it. Lyssa states that in order for a team to be highly productive, they need to have strong roots. When the roots are strong and solid, the tree can grow and flourish bearing beautiful fruits.

I see this exercise used mainly in three different ways:

  • Team startup
  • Normal team that still has a lot of problems to solve
  • Good team that is looking for the next step to become high performing team

How to do it
This exercise starts with a coach drawing a tree of five Scrum values as roots; this is a great opportunity for the coach to teach or refresh a meaning of Scrum Values.

Commitment is the state or quality of being dedicated to a cause, activity, etc. A commitment should never be broken and if it is broken, it was not a commitment but an empty promise and a lie. In the Scrum world, this means that everyone involved in developing a product is committed to working towards a common objective.

Courage is the ability to confront a fear, pain, a danger, an uncertainty, or intimidation. In software development, all these feelings will be always present and it is up to team members to try to dispel anything that prevents them from being successful.

Openness is the ability to be open to new ideas, new approaches and new ways of working. This is a fundamental state in Agile software development, because every day teams encounter different problems that need to be approached differently; being open is mandatory for achieving success.

Focus is the process of selectively concentrating on one aspect of the environment while ignoring other things. In software development, this means that teams should completely concentrate on one topic at a time, they should not start a new topic before finishing a previous one.

Respect is a feeling of deep admiration for someone or something elicited by their abilities, qualities, or achievements. In Scrum all team members interact closely; respect is mandatory for such relationship to work.

scrum_values

After listing and explaining the Scrum Values you can start listing characteristics of high performance teams, like for example: Empowered, Consensus-Driven, Self-Organised, Constructive Disagreement, etc.

You can continue the exercise explaining that as a result of this combination there will be teams that can do anything, get astonishing results, get a right business value, get business value faster, etc. A possible example can be see on the picture on the right.

I truly believe this drawing will be a fantastic tool to be used in several retrospectives. New teams will be aware of what they need to be a high performance team. Teams that are already together for some time can come back to the picture and analyse what is missing in order to become high performing teams. I believe the same applies to teams that are already performing as High Performing teams; they will always find some things they can improve.

As many other exercises that I explained before, this exercise will have a big impact when all team members are collocated. However, this is not mandatory, this is an exercise that can be easily done using a web cam, like for example Lyssa did here.

What do you think? Do you think this is useful? Please give me some feedback.

On my next blog post I explain how to use the “Boat” on the retrospective.

Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: .

I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.





Thanks guys,
Luis

Getting Value out of Agile Retrospectives: “How to start an effective Retrospective using Car Brand exercise”

This post is dedicated to a topic: “How to start an effective Retrospective”. I already blogged about this topic when I explained “How to start an effective Retrospective using Constellation exercise” the post can be found here. TThis exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by me and Ben Linders with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it within your colleagues.

One of the important parts of a successful retrospective, is an interesting “opener”, we must set a stage, allowing a team to feel comfortable to speak freely about any topic. This post describes the “Car Brand” exercise.

Here you can find my previous blog “Getting Value out of Agile Retrospectives: “How to start an effective Retrospective using Constellation exercise””

What you can expect to get out of this technique
This is a simple exercise to set the stage for the team to start the Retrospective. Its a good exercise that allows people to show how they feel about how the sprint went without expressing openly their opinion, this is extremely important specially when the team is new to each other and they are not comfortable in showing their feelings or opinions openly.

When you would use this technique
I believe this exercise is super simple and does not require any special occasion. It can be used as an opener for any retrospective. This is a good exercise to reveal individuals´ opinion, allowing everyone to have a common understanding about what the others think. This is important because team members must be aligned.

How to do it
When the retrospective start make everyone feel comfortable and ask them a simple question: “If you think about this sprint as a brand car which car would you chose?”. For example if the sprint went so well that there is nothing to point out most probably everyone would chose a Ferrari. If the sprint had several ups and downs maybe a Fiat would be more suitable. Give them two or three minutes to think what is their brand.

When you feel that everyone knows which car they want, invite them one by one to reveal “their car”. Do not go into discussion at this point, people will have time to justify their choices quite soon, allow everyone to see what others chose first, this will give an overall feeling about where the team stands. After this exercise ask people to think about their dream car and give them 10 minutes to think about what they would change on the past sprint in order to have their “dream car”.

People will come up with dozens of different ideas, but based on my experience a lot of them will be common problems. You as facilitator try to group them into the same groups. Ask the team to use for example dot votes and select the most critical problem that should be tackled for the next sprint.

For this exercise the topic was car brand but you can use anything that makes sense for you. To run this exercise the team does not need to be collocated, team members can be spread all over the world and still be able to run this exercise using virtual tools.

What do you think about this exercise? Do you think its a good exercise? I would love to receive some feedback from you.

On my next blog post I explain how to use the “High Performance tree” exercise to open and set the tone for the retrospective

Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: .

I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.




Thanks guys,
Luis

Getting Value out of Agile Retrospectives: “How to start an effective Retrospective using Constellation exercise”

This post is dedicated to a topic: “How to start an effective Retrospective”. This exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by me and Ben Linders with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it within your colleagues.

To have a successful retrospective, we need to have an interesting “opener”, we must set a stage, allowing a team to feel comfortable to speak freely about any topic. This post describes the constellation exercise which is not the first time I write about it; you can find my previous post here, and my Scrum Alliance article here.

Here you can find my previous blog “Getting Value out of Agile Retrospectives: “Team Assessment Survey””

What you can expect to get out of this technique
This is a great exercise for people who do not like or do not feel comfortable sharing their opinion/feelings openly, at least in the beginning of the project when they still do not trust everyone completely. Due to the cultural backgrounds or the personality of team members, answering some questions can be difficult for some. But this exercise can help, because people do not need to speak in order to answer questions. Another good advantage is the fact this exercise reveals what all team thinks about certain topic without the need for early discussions.

When you would use this technique
I believe this exercise is super simple and does not require any special occasion. It can be used as an opener for any retrospective. Although, it might be suitable for situations where the Scrum Master/Agile Coach feels that the team does not have the same opinion about the practices applied within the team. This is a good exercise to reveal individuals´ opinion, allowing everyone to have a common understanding about what the others think. This is important because team members must be aligned. For example, if some team members think their level of automation is good but others do not share the same opinion,there is no way team will work together to improve this topic.

How to do it
We begin a retrospective with welcoming team members and setting an affirmative goal for the session. This is where the “Constellation” exercise can be used.

Start making an open space, move tables and chairs around, if needed. Put an object on the floor and explain to a team that this object is the center of the Universe and kindly ask them to form a circle around it. Explain them that you will read some statements, and while you are reading the statements, you would like them to move closer to or farther away from the “Universe” depending on how true the statement is for them. So, if they really agree with the statement, they should move to the “center of the Universe” as close as possible. If they do not agree with the statement, they should step back away from the center. Once you read a question, let the team observe the “system”, as Lyssa said, “Let the system reveal itself”.

You can use any topics like:

  • How mature is our continuous integration process?
  • How mature is our automated testing process?
  • Etc

Just choose a topic and ask several questions related to that topic and let them see where they stand. Like I said, they do not need to give verbal answers at all, they answer with the movements by showing their position in the “system”. You could do several questions until you feel a good vibe from the team. To benefit fully from this exercise, you could ask the team in the end: “Where were you surprised with the shape?” and let them talk to each other a bit.

As a next step, you can, for example, ask the guys to form small groups and run a normal retrospective exercise, like fore example THIS one. After that just agree with the team who will take which responsibility and close the retrospective.

One good thing of this exercise is the fact that you can actually do it virtually, of course having co-located people helps, but its not mandatory. You can use tools, like for example lino.

What do you think about this way to set the stage for a Retrospective? Do you think it is useful?

On my next blog post I explain how to use the “Car Brand” exercise to open and set the tone for the retrospective.

Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: .

I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.




Thanks guys,
Luis

Getting Value out of Agile Retrospectives: “Team Assessment Survey”

Hi guys, in this post I will explain how can you use Team Assessment Survey as a tool for a retrospective. On my current job I was exposed to the SAFe framework by Dean Leffingwell, this framework provide a team assessment survey, the exercise that I will teach here is an adaptation of Dean’s assessment. The original assessment can be found here.

This exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by me and Ben Linders with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it within your colleagues.

Here you can find my previous blog “Getting Value out of Agile Retrospectives: “Value Stream Mapping””

What you can expect to get out of this technique
The purpose of this exercise is to analyze how teams are performing in different areas and identify possible improvements to be taken in the near future (next sprint?). The assessment has four main areas:

  • Product Ownership Health - How the product owner is performing
  • 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 that can be rated from zero to five, allowing the team to visualize what are the areas that need more attention from the team.

This is a great exercise to reveal the overall agile health of a team.

When you would use this technique

I believe this technique is quite simple and does not require any special occasion. Although, it might be suitable for situations when a team wants to understand better how well they are implementing Agile. This exercise will not solve specific problems that occured during the sprint, but might reveal some of the causes why those problems happened. For example if the team is finding a lot of bugs during development it might be that their Unit Testing, or automation practices is not being well implemented.

How to do it
To Perform this exercise you just need an excel sheet. Like I said before that excel well have four main areas (Product Ownership Health, Sprint Health, Team Health and Technical Health). For each different areas you create several questions that you think are appropriate for your team. You can always refer the questions from SAFe Team Scrum XP assessment that you can find here. Below I list two questions as an example for each different areas.

Product Ownership Health:

  • Product Owner facilitates user story development, prioritization 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 (do readers know what PSI is?) objectives, and commits to meeting them

Team Health:

  • Team members are self-organized, 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 (e.g. the sprint is not a waterfalled)

Technical Health:

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

All these questions can be rated from zero to five, zero means “Never”, five means “Always”.

Screen-Shot-2012-08-02-at-8.29.01-AM During the retrospective the team just need to fill the excel file as a team and evaluate themselves to see where they stand. If you want, you can create a nice graphic to easily see the result of the assessment. An example can be seen on the picture on the right side.

Visualizing the graphic will give a team a good understanding where they stand, with the graphic in front of them they should decide which area they want to improve, again chose only one area at the time and one topic within the area.

Like many other exercises that I explained this exercise does not require to have a collocated team (true, but they would need some kind of scoring and voting mechanism). This exercise can be run in a virtual setup where the team is spread all over the world.

What do you think about this exercise? Do you think it could be useful for you? Please leave me your ideas.

On my next blog post I explain how to use the “Constellation” exercise to run a retrospective.

Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: .

I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.




Thanks guys,
Luis

Getting Value out of Agile Retrospectives: “Value Stream Mapping”

Hi guys, in this post I will explain how can you use Value Stream Mapping as a tool for a retrospective. In this post I already explained the full exercise but now I want to create it with a more structured approach. This exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by me and Ben Linders with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it within your colleagues.

Here you can find my previous blog “Getting Value out of Agile Retrospectives: “Star Fish””

What can you expect to get out of this technique
Although value stream mapping is often associated with manufacturing, it is also used in logistics and supply chain, service related industries, healthcare, software development, product development, and administrative and office processes. Value stream mapping is a lean manufacturing technique used to analyse and design 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. As an outcome using this tool you can visualise how your development process is working allowing your team to identify several possible parts of the software development process that can be improved.

I guarantee you that you will have plenty of data for your retrospective at the end of the iteration. I tried this couple of times and I was surprised how many issues we found out, how many dependencies and blockers we had and so on. Having this information available, it will help a team to decide how and where they can improve.

When would you use this technique
This technique will be more effective with mature teams. This technique will reveal how the team and system interact. For this kind of exposure, the team must be mature. I believe, if team members are new to agile, they will not understand most of the things this exercise will reveal. For example, from my experience one of the most common things this exercise reveals is the QA/Loc/documentation tail for each story. If the team is not mature enough they will not see this as a problem. I believe most of the times only true agile teams will understand how important is to reduce QA tail introducing TDD, ATDD, Unit Testing or how important is it to have documentation/localization done within the sprint. In order to get more ideas how to bring localization inside of the spring please take a look into this post. Value Stream Mapping technique will reveal some complex problems that only mature teams are ready to deal with.

How to do it
This activity is not an activity to perform during the retrospective. Instead, this is an activity to be run during all iteration and suitable for analysing the results within the retrospective.

IMG_20130217_190326The 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. You should have a flip-chart for each different story of the iteration. If your team is not co-located there is no problem, just create an excel for the same effect.

During development, the team should be concentrated on one story at a time. If they are doing any activity that will bring value to a customer, each member draws a line on top of the Y axis line. If they are waiting, blocked or doing some activity that does not bring value to the customer,draw a line under the Y axis line.

If you are new to this exercise, as a rule of thumb, you can think that all tasks that are needed to accomplish a story, bring value to customer. All other tasks bring a waste. As it is used in a business world, customer value is an amount of benefit that a customer will get from a service or product relative to its cost. Waste as Poppendiecks describes in their book “Lean Software Development” is:

  • 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 extremely mature you can start thinking that all QA activities that are performed as validation instead of part of development or bug fix, 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 you can think this is a waste. Bug fixing can be considered as a waste too. With this statement, I am expecting to get lot of reactions :D

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 the retrospective. The possible result can be something as the picture seen above. Like I said I tried this activity several times and its amazing how much information team gets out of this exercise. For me this is one of the exercises from my toolbox that I more appreciate.

What do you think about this exercise? Do you think it could be useful for your and for your team? Leave me some feedback in order to make improvements.

On my next blog post I explain how to use the “Team Assessment Survey” exercise to run a retrospective.

Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: .



I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.




Thanks guys,
Luis

Getting Value out of Agile Retrospectives: “StarFish”

In this post, I will explain the exercise called “StarFish”. This exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by me and Ben Linders with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it within your colleagues.

Here you can find my previous blog “Getting Value out of Agile Retrospectives: “Happiness Index””.

What can you expect to get out of this technique
Starfish exercise is an evolution of the typical three questions that are used for retrospectives:

  • What went well
  • What did not go so well
  • What will be improved

Instead of the typical three questions we have a circle with five words:

  • Stop - These are the activities that do not bring value to a team or to a customer. Activities that bring waste into the process.
  • Less - These are activities where an effort required to perform such activities is much smaller than a benefit. Or the activities that were brought into the team in past but did not show any overall improvements to a process.
  • Keep - Usually these are good activities or practices that team members want to keep. These activities are already being applied.
  • More - Activities on which a team should focus better, perform more often. For example, many teams tell me how pair programming is good,yet they do not do it every time they should.
  • Start - Activities or ideas that a team wants to bring into the game.

With this exercise, teams can get a good overall picture of what’s going on within the team, what is working and what is not. They can get an overview about failed as well as successful work experiences in past. In my personal opinion, I think this is a great evolution of the typical three questions.

When you would use this technique
I believe this technique is quite simple and does not require any special occasion. Although, it might be interesting for situations when a team went through several ups and downs during the iteration. This technique reveals all good things and less positive things performed by a team. Therefore, this might be a good tool to make a summary of the sprint.

StarFish is suitable for any team, it does not require any specific level of maturity.

How to do it
Star Fish - Retrospective This retrospective is quite simple. First we draw something like what is shown on the picture in a flip chart. One of the beauties of this exercise is the fact that collocation of a team is not mandatory. You can use, for example, tools like Lino to apply the exercise on non-collocated teams. This tool allows us to do everything what we need in order to run this exercise.

After having the picture on a flip chart, it´s good to start a brain storming session with a team allowing them to dump their ideas in the “Stop” area. After that, give 2-3 minutes to each person to read out loud its “stop” ideas. Afterwards, spend 10 minutes for a short discussion to see if everyone is aligned.

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

For the “Start” part, add one extra step and use Toyota approach choosing one single topic to “Start”. I would go for votes and see what is the most important topic that one should start with. After selecting the topic, design a small strategy to make sure a topic is well implemented. This strategy might include responsible persons, due date and most important success criteria. In order to know if the implementation was successful or not, we must have a success criteria.

I would like to highlight that a theme that is chosen in the “Start” part, does not need to be a new topic for a team, it can be an improvement of something that is not working well within the team.
Another important thing that I think it´s worth to mention, is the order of different “words” in the circle. I really like to start with: “Stop”, “Less”, “Keep”, “More” and finish with “Start”. I think this has a big impact. Starting with negatives topics and progressing little by little towards the positive ones will help the team to end the retrospective with a much more positive feeling than if they did it in a random order.

I honestly think this exercise is really nice, but I really would love to get your feedback. Please comment on this and let me know your opinion.

On my next blog post I explain how to use the “Value Stream Mapping” exercise to run a retrospective.

Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: .



I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.




Thanks guys,
Luis

Getting Value out of Agile Retrospectives: “Happiness Index”

In this post, I will explain the exercise “Happiness Index”. This exercise can be found in the book: “Getting Value out of Agile Retrospectives”, a book written by me and Ben Linders with the foreword from Esther Derby. The book can be downloaded by free in LeanPub.com or InfoQ.com, please download it and spread it within your colleagues.

This exercise is a combination of “Develop a time line” and “Emotions Seismograph” from Norman L. Kerth.

What can you expect to get out of this technique
The purpose of this exercise is to draw a graphic representation of team members´ emotions during sprints, connecting their emotions to sprint events. With this kind of information, the team can identify what exactly affects its performance during the sprint. For example, if they have some problems with the build server, most probably the mood will drop because of the team frustration not being able to proceed with the work. This kind of exercise is a great way to represent team emotions within the sprint.

When you would use this technique
I believe this technique is quite simple and does not require any special occasion. Although, it might be suitable for situations when a team has many different emotions within the sprint and they wish to analyse the consequences, or when the team has several challenges within the sprint and would like to understand better when and how the issues appeared.

Happiness Index is suitable for any team, it does not require any specific level of maturity.

How to do it
To perform this exercise, you simply need a A4 white sheet and some post-it notes. Start by dividing the sheet in two parts, having positive and negative axis. After, divide the X axis in the number of days that your sprint has.

There are two ways of doing this exercise:

1) The exercise is done within the retrospective itself with all the team
2) The exercise is done in small pieces during the sprint

Let´s start with the first option, create small groups of 2 or 3 persons. Ask them to do a small brainstorming session and let them think about all the events that occurred during the sprint. Afterwards, ask them to create a graphic showing emotion levels with events occurred during the sprint. When all groups are done, create a representation of all small groups in a single graphic. Do not forget to put an explanation of each different emotion.

For the second option, instead of the team drawing the graphic in the retrospective, each person will draw his own emotion level at the end of each work day. This approach will make sure that all events are covered and not forgotten.

Using one way or another, we will have a fantastic picture of what happened during the sprint. With this kind of information, a facilitator can help the team to identify events that should be repeated and events that cause delay in the team. The root of problems can be found using normal root cause analyses techniques.

With the right imagination, this exercise can be applied to remote teams as well. Being collocated is not a requirement to run this exercise.

What do you think about this exercise? Do you think this would be a good retrospective exercise for our new book? To find more information about the book, check my post here.

On my next blog post I explain how to use the “Star Fish” exercise to run a retrospective.

Please leave your comments, all your comments and ideas will help me to improve the exercise and the book.

Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: .



I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.




Thanks guys,
Luis

Getting Value out of Agile Retrospectives

Hi guys, I want to use this post to introduce a topic I will discuss during next few weeks. Me and my colleague Ben Linders we are writing a pocket book about retrospectives. The title of this book is: “Getting Value out of Agile Retrospectives“.

The main target are: Agile coaches, scrum masters, project or product managers or facilitators who have at least some experience with doing retrospectives. They know the purpose of them, how they fit into agile / scrum, and how to arrange and perform them. This book will deliver practical description of retrospectives and how to do them, as well as an inspiration to different retrospective techniques and good practices in doing them.

Based on the previous information I want to use this blog to get a feedback from you. During following weeks I will publish several posts that will cover retrospective exercises and I would like to get some comments which would enable me to improve a content for the final version.

Below you can find some of the exercises that will be part of the book(Ben’s exercises are not here).

In conclusion, I would like to ask you to leave as much feedback as possible so that I can improve the outcome of this book.

Did you like this post? Do you want to get more in the future? Subscribe my newsletter below and follow me on twitter: .



I am trying to improve these blog posts with a help from professional designers and editors to give you even more valuable content. If you want to support me on this effort, feel free to contribute with any amount of money that you think it´s fair.




Thanks guys,
Luis

Ping Pong Programming

pingHi guys, in my last post I gave a small introduction to pair programming. This post will be short where I would like to present a small technique that can be used during pair programming. I learnt this in Rachel’s and Liz’s book. This technique is called Ping Pong Programming and it ensures that both members of the pair take a turn at the keyboard. Below you can find the steps.

  • The first developer writes a falling test and then passes the keyboard to his pair
  • The second developer writes just enough code to make the test pass
  • They then work together to re-factor the code that has just been written
  • Then the cycle can start again with the second person writing a new failing test and handing the keyboard back to the first person.
  • What do you think about this approach? Do you think that would help your developers? Do you think it would help you guys to design a better code and to spread knowledge within a team?

    Please leave some comments.

    Final3dPostCTA