Tag Archives: Retrospective

Agile Principles Constellation – A Retrospective

Have you ever wondered if what you are doing is “agile?” Sometimes the work you’re doing doesn’t feel like it has much “agile” to it, especially if you are being asked to do a specific set of work in a specific time frame. Damn you, iron triangle!

Agile Principle of the ManifestoYour workplace isn’t “agile” or “not agile.” Certainly there are parts of your organization that will be aligned with agile principles, and there are some aspects that are likely not. This retrospective is designed to explore your organization’s alignment as it relates to agile.

Here is the outline of the retrospective. Feel free to adapt it as you see fit. If you do adapt it, please let me know what changes you made.  If you use this retrospective, I would like to hear how it went. You will note that the general flow for this retrospective matches the outline in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen.

Set the Stage With One Word Check In

One word check-in. Consider something like “how did the last sprint feel?” This gets everybody to talk at least once.

Gather Data Using a Constellation

The constellation exercise is a way to visualize the degree to which people feel a principle is present or absent from their work. Here is how to conduct this activity:

The facilitator reads one principle out loud, and then places it on the floor near the center of the room.

People then position themselves relative closer or farther from the statement based on how much they feel the principle is present in their environment (e.g., team, organization, company, whichever you chose). If somebody feels it is strongly present they would stand close to the principle you placed on the ground. If somebody feels it is not present or “anti-present”,  they would stand very far away.

Give people a moment to observe the pattern and perhaps jot down anything they noticed.

Pick up the principle you just used, and move on to the next one. After all twelve principles have been read, move on to generating insights.

Generate Insights

Ask people what they noticed about the constellations that took place during the Gather Data activity. Some question you might consider include:

Which of the principles were strongly present? Which were strongly absent?
What similarities or differences did you notice about those principles?
Which had the most disagreement amongst the group?
Which had disagreement by role?
Which had some individuals who felt differently than the majority of the group? What unique perspective might those individuals have?

Decide What to Do and Closing

I would encourage you to determine what kind of activity makes sense for your team to use for the “Decide What to Do” and “Close”. If you want to get more options for these phases, jump on over to the Retromat and give it a spin.

Retromat Screenshot

Background on some of the decisions

Why did I choose to do all twelve principles before generating insights?

I didn’t want to do a deep dive on each of the principles. I was more interested in having the team see the constellation that formed for each principle, and then generate insights on a subset of the twelve.

Why did I choose not to do a constellation based on the “left side versus the right side” of the Agile Manifesto itself?

Certainly, you could create an activity around the values in the Agile Manifesto. However, I have found that the values of the manifesto are a little too vague for this type of conversation. While the principles are more specific, they are still general enough to generate deep conversation.

Preparation and Supplies

Plan to use a room that is fairly open, leaving enough room for people to move about freely.

In preparation for this retrospective, print out each Manifesto principle on its own sheet of paper.

Have a note-card for each individual participating, so they can make notes about their observations. Maybe pre-print each Manifesto principles on a separate 3×5 or 4×6 card for each person.

Conclusion

It is very important for individuals, teams, and organizations to explore the principles behind how they operate, and not simply follow the rules of the framework-du-jour. The goal of this framework is to explore those principles. Please feel free to add your thoughts.

5 Ways to Keep Your Fishbone From Stinking

Do you have a tough problem you are trying to solve? Consider conducting a root cause analysis using a Fishbone Diagram. Here are five tips that can keep your analysis from stinking:

1. Have a sharp problem statement

Get this wrong and you’re wasting your time. Focus on one specific, observable problem. Think about ways you could measure the impact of correcting your problem statement. If the problem is measurable, there’s a good chance that you have a problem statement that is ready to be analyzed.

2. Find the right people

A former manager of mine use to say “availability is not a skill.” Get participants who will have the context and experience to generate quality insights. Make sure you get a diverse group of participants that will view the problem statements from a variety of perspectives.

3. Make time for it

Like so many things in life, the objective is not to rush through the activity. Schedule enough time whereby participants do not feel rushed. Do the analysis in one contiguous block of time. Make sure that participants are giving their full attention to the matter at hand, and that they are not disengaging either physically or mentally.2

4. Make it Visible

Be vigilant for conversation that is not captured in writing. A team can easily get into a dialog about the problem’s causes and forget to capture insights that are mentioned. Don’t let potential causes get missed. Make sure that all the participants have a pen and encourage them to write their observations on the diagram. If you hear a cause mentioned that isn’t captured, stop the conversation, get it written, and then go on with the analysis.

5. Get a Facilitator

Last but not least! Find a neutral party that has facilitation skills that can engage with your team. A facilitator will be focused on the mechanics of the activity, allowing participants to immerse themselves in the actual problem that they are trying to solve. A facilitator is instrumental in helping bring out the voice of all the participants, and can guard against the conversation going down paths that are not focused on the stated problem.

Summary

Using a Fishbone Diagram to visualize a root cause analysis session can yield powerful insights. Give your efforts the best chance of success by setting it up with a solid problem statement, and investing in facilitation to shepherd the team through the analysis.

Please share your thoughts on what helps or hinders the effectiveness of a root cause analysis.

Additional Information

1. A Fishbone diagram is the result of an analysis in which a team of individuals articulates possible causes of a specific problem statement, and then enumerates the possible causes of that cause. The individuals involved continue to do this activity recursively until they identify candidate root causes. The visual that results from this analysis will take on a fish-like shape.
2. Esther Derby and Diane Larson have some ideas on how to “Check In” in their book Agile Retrospectives: Making Good Teams Great. The book is definitely worth buying. Make sure people check their distractions at the door, and that you have the attention required for the activity.