Here is a nice collection of Agile-related memes and comic strips that you may just find hit a little too close to home. And probably a little funny. Enjoy.

The post Mostly Agile-related Memes appeared first on An Agile Mind.

If you are looking to help team members better understand the beliefs and perspectives of others, than look no further than running the Constellation exercise. This can be used to kick off meetings, for team launches, for team reboots, for retrospectives and many other situations. It has the power to surface misunderstandings and also highlight similarities within the group as well as diversity. All of which can help bring a team or group of people into a high-performing state.

When to Use

• Team Building (during a team launch or reboot)
• Start of meeting (i.e. retrospective)
• Gain consensus when team has high trust and psychological safety. If you don’t have these, then some team members may just follow the crowd

How to Run Constellation

Usually I make a statement along these lines to kick things off. “We are going to run a fun exercise called “Constellation” to get to know about each other. We will find that we have similar levels of agreement in some areas but at times dissimilar. It is worth recognizing and celebrating our similarities and differences.” Then I summarize the steps below for the team or group.

1. Clear a decent size space for the amount of people in the exercise to move around
2. Place an object as the center of universe (i.e. roll of masking tape, paper plate, fidget toy).
3. Form circle around the center of universe
4. Make statement (see examples below)
5. Move based on level of agreement. If you strongly agree, move very close to the center of the universe. If you strongly disagree, move very far from the center of the universe. Don’t be surprised if some people will almost want to go through a wall to get further from the center of the universe
6. Invite the team or group to observe the constellation
7. Go back to step 3 and repeat until allotted time is up
8. Debrief with powerful questions
   1. “What surprised you?”
   2. “What assumptions did you have?”
   3. “What do you understand better now?

Example Statements

• I enjoy political conversations
• I enjoy public speaking
• I believe we are producing a high quality product
• I feel confident we can complete the stories for this sprint (if you are working in a Scrum framework)
• I like team building exercises
• I love country music

Similar to the tribes exercise, this is very simple and takes very little effort to set up. It has great value when helping teams or groups form bonds but also surface misunderstandings and diversity of beliefs. It works in many different settings. Good luck running this. I’d love to hear about your experience running this exercise in the comments below.

Credit

I believe credit goes to the Agile Coaching Institute for this exercise. I first experienced it during their Coaching Agile Teams workshop.

Many More Example Statements

This is list comes from the Agile Coaching Institute

• I feel more of an accomplishment working individually than as a team
• I like getting results
• I want others to lead
• I do not like uncomfortable silence and work to fill it in
• I am open to change
• I like chatting about life outside of work from day to day
• I feel comfortable in providing direct feedback
• I like discussing alternatives
• I like to work alone
• During the finish stage, I don’t like to go back to discussing alternatives
• I am competitive
• I don’t mind bending the rules to get things done
• I value work/life balance
• When under stress, I like to be told what to do
• My happiest times are in nature
• I’m comfortable in front of a group
• I like public recognition
• I’m nervous about providing real time feedback
• I’m frustrated when there is not order
• I enjoy alone time
• I feel a sense of accomplishment when I know I’ve done a complete and thorough job
• I feel a sense of accomplishment when others recognize me
• I need to feel a sense of accomplishment to stay motivated
• I thrive on being around people
• I like to make things with my hands
• I like to make my own way
• I like surprises
• I like to take charge and make decisions
• When things are chaotic, I like to create order

The post Team Building Icebreaker – Constellation Exercise appeared first on An Agile Mind.

Whether you are just forming a new team, looking to form new bonds with an existing team, or get to know some friends a bit better at a party. An exercise called, “Tribes,” is a very simple way for people to connect and get to know each other. This works great with anywhere from 5 to 20 people. You will want a space to make a circle with however many people participate.

I usually get the team/group to form in a circle first (see the graphic below).

Then explain the exercise as outlined below. Be sure to let the group know that participation is voluntary and they can opt out. If you are the facilitator or coach (of a sports team or Agile Coach) then you can opt to not participate. If you are a Scrum Master then I would encourage participating.

How to run Tribes

Usually I make a statement along these lines. “We are going to run a fun exercise to get to know about each other. We will find that we have similar likes but also see that we have differences. It is worth recognizing and celebrating our similarities and differences.”

1. Form circle, if not already formed
2. Someone moves to the center and will make a statement (i.e. “I love to camp, anyone else?”, “Loves camping”).
3. You could provide some more examples from the list below
4. Other members move in if that statement is true for them. Greet your tribe members. Also recognize those that didn’t form the tribe and appreciate where we are different
5. Return to the circle
6. Next person go. Repeat until the time allocated is done

Examples of tribes

• Loves pizza, oreos, sushi, mac and cheese, etc…
• Likes the outdoors, traveling, running, cycling, stand up paddle boarding, video games, etc…
• Passionate about movies, scary movies, bing watching a <insert title of new series>, etc…
• Fond of knitting, board games, reading, cooking, etc…
• Can’t get enough of dogs, cats, birds, snakes, etc…
• Nothing better than beaches, mountains, lakes, etc…

Tribes is a very simple exercise that takes very little effort to set up and has great value when helping teams or groups form bonds. Forming these bonds is but one ingredient in getting teams or even groups into a high performing state. I’d love to hear about your experience running this exercise in the comments below.

Good luck and don’t forget to have fun.

Credit

I wish I knew who to give credit for this exercise. I was first introduced to it during the Coaching Agile Teams workshop that I was in years ago.

The post Team Building Icebreaker – Tribes Exercise appeared first on An Agile Mind.

Brighten up your Monday with some more Agile-related memes. I tried to attribute credit where possible.

Credit: @ThePracticalDev

Credit: @cobraKaiAgile Credit: @ThePracticalDev

Credit: @iamdeveloper

Credit: @nixCraftCredit: @ThePracticalDev

More meme can be found here: Collection of Agile-related memes

The post Memes Make Monday a Little Better appeared first on An Agile Mind.

It is amazing to think that the Agile approach to developing products has been around in various forms for many years. Some would say the mindset can be found in the Scientific Method that Francis Bacon developed in the 1620’s. Agile has taken root as the defacto mindset to have when building a product with unknown customer needs and a need to discover ways to build it. Agile’s dominance comes after many years of failed products developed using a methodology that worked when the customer needs and knowledge of how to build it are well known. Rarely was this the case for the products being developed.

Below is a timeline of some major events that have helped lead us to the Agile mindset for product development. There are many more contributions, but I believe these are the major events:

• 1620 – Scientific Method from Francis Bacon
  • Pose a question, gather information, form a hypothesis, test the hypothesis, and share knowledge. Sounds like an Agile mindset.
• 1930 – Plan Do Check Act (PDCA) by Walter Shewhart
  • This takes the Scientific Method and adds the “Act” component to enable integration of knowledge to form a cycle.
• 1948 – Toyota Production System (precursor to “Lean Manufacturing”)
  • A framework for conserving resources by eliminating waste. People who participate in the system learn to identify expenditures of material, effort and time that do not generate value for customers.
• 1950’s – Plan Do Study Act (PDSA) by W. Edwards Deming
  • Building off PDCA, Deming wanted to bring more attention to the fact that the “Study” phase was about analysis. He felt that “Check” emphasized inspection over analysis.
• 1976 – Evolutionary Project Management by Tom Gilb
  • His material was probably the first with a clear flavor of agile, light, and adaptive iteration with quick results. He stated that, “a complex system will be most successful if it is implemented in small steps and if each step has a clear measure of successful achievement as well as a “retreat” possibility to a previous successful step upon failure.“
  • Approach cited in Software Metrics.
• 1985 – “A Spiral Model of Software Development and Enhancements” by Barry Boehm
  • Formalized and made prominent with a risk-driven iterations concept and the need to use a discrete step of risk assessment in each iteration. Higher risk items were worked on earlier than lower risk items.
• 1986 – The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka
  • Presented a holistic approach taken by product developers within a few select companies with six characteristics: built-in instability, self-organizing project teams, overlapping development phases, “multilearning,” subtle control, and organizational transfer of learning.
• 1990 – Rapid Application Development teachings by James Martin
  • Approach to software development that put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even in place of design specifications.
• 1995 – Scrum framework presented by Ken Schwaber and Jeff Sutherland in 1995 at OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) Conference
  • “A framework within which you can employ various processes and techniques. Scrum is grounded in empirical process control theory, employs an iterative, incremental approach to optimize predictability and control risk.” – Scrum Guide
• 1999 – “eXtreme Programming (XP): Explained” by Kent Beck
  • Emphasized communication, simplicity, testing, and sustainable developer-oriented practices. Advocates frequent “releases” in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.
• 2001 – Agile Manifesto
  • 17 developers known as “organizational anarchists” met for 3 days in Snowbird, UT because they were successfully producing software in an iterative and incremental manner as opposed to using a waterfall methodology. They wanted to share their ideas that allowed their methods to work significantly better. They forged the Agile Manifesto with its 4 key values and 12 operating principles that captured the essence of their methods.
• 2007 – Discussion of Kanban at Agile 2007
  • A lean method to manage and improve work across human systems. This approach aims to manage work by balancing the demands with available capacity and improving the handling of system level bottlenecks.

As you can see, the application of an Agile mindset for developing products has been around for some time. While there may be passionate debates about the Agile mindset history, its roots extend far beyond Information Technology (IT) and will continue to grow into every function of every industry that wants to improve their innovation process.

The post A Brief History of Agile: A Mindset for Product Development appeared first on An Agile Mind.

Changing Perspective:

Accepting the Mind:

Underlying Calm:

Letting Go of Effort:

Brilliant Things Happen in Calm Minds:

The Hole in the Road:

Meditation is Just Like Riding a Bicycle:

Why Focus on the Happiness of Others:

I hope you enjoyed watching these like I did. It certainly gave me an even deeper perspective on how our minds work and why meditation is so powerful.

The post Great Animations on Meditating and Our Beautiful (Sometimes Cloudy) Minds appeared first on An Agile Mind.

In the spirit of the holidays but with a slight twist, I bring you the 12 days of dysfunctional Scrum. Happy Holidays to all and have a Happy New Year! Stay safe! Be sure to play the music while reading. If you are rushed for time, I provided a summary first but that takes a little fun out of it.

If you want to sing along skip to the Sing-a-long section and click the video for some background music:

Here are the 12 days of dysfunctional Scrum:

• Twelve frustrated users
• Eleven manual tests
• Ten slides at Review
• Nine Scrum Master taskers
• Eight broken builds
• Seven misunderstood stories
• Six extend sprints
• Five month releases
• Four “backend” stories
• Three canceled Retros
• Two hardening “Sprints”
• and an hour long Daily

Sing-a-long

On the first day of Dysfunctional Scrum my coach sent to me:
An hour long Daily

On the second day of Dysfunctional Scrum my coach sent to me:
Two hardening “Sprints”
and an hour long Daily

On the third day of Dysfunctional Scrum my coach sent to me:
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the fourth day of Dysfunctional Scrum my coach sent to me:
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the fourth day of Dysfunctional Scrum my coach sent to me:
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the fifth day of Dysfunctional Scrum my coach sent to me:
Five month releases
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the sixth day of Dysfunctional Scrum my coach sent to me:
Six extend sprints
Five month releases
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the seventh day of Dysfunctional Scrum my coach sent to me:
Seven misunderstood stories
Six extend sprints
Five month releases
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the eighth day of Dysfunctional Scrum my coach sent to me:
Eight broken builds
Seven misunderstood stories
Six extend sprints
Five month releases
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the ninth day of Dysfunctional Scrum my coach sent to me:
Nine Scrum Master tasks
Eight broken builds
Seven misunderstood stories
Six extend sprints
Five month releases
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the tenth day of Dysfunctional Scrum my coach sent to me:
Ten slides at Review
Nine Scrum Master tasks
Eight broken builds
Seven misunderstood stories
Six extend sprints
Five month releases
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the eleventh day of Dysfunctional Scrum my coach sent to me:
Eleven manual tests
Ten slides at Review
Nine Scrum Master tasks
Eight broken builds
Seven misunderstood stories
Six extend sprints
Five month releases
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

On the twelfth day of Dysfunctional Scrum my coach sent to me:
Twelve frustrated users
Eleven manual tests
Ten slides at Review
Nine Scrum Master tasks
Eight broken builds
Seven misunderstood stories
Six extend sprints
Five month releases
Four “backend” stories
Three canceled Retros
Two hardening “Sprints”
and an hour long Daily

What would you add/change to the 12 days of Dysfunctional Scrum?

The post 12 Days of Dysfunctional Scrum appeared first on An Agile Mind.

Well, unfortunately, that just isn’t the case sometimes.

Some of the items don’t have conditions defined that need to be met for the item to be completed. Some items have significant dependencies. When the team is asked if they know how to demonstrate the item, sometimes this is met with shrugs of shoulders or 5 different versions of how to demonstrate it are given.

So, what usually fixes all this? In my experience, creating a Definition of Ready (DoR) agreement and following it, does the trick.

What is the Definition of Ready (DoR)?

It is an agreement on the collection of conditions that need to be fulfilled in order for a backlog item to be considered in an upcoming Sprint/Iteration for delivery.

Why do we need a DoR?

If the team keeps pulling stories into the sprint/iteration that aren’t being completed, it is probably because the backlog items aren’t adhering to an agreed upon state they must be in to be considered for an iteration. Creating DoR agreement and following it will greatly increase the teams ability to complete backlog items within a Sprint/Iteration.

How to Generate the Initial DoR

1. Gather the team (including the business and development team) around a whiteboard. Explain that the purpose of the workshop is to create an agreement as to what needs to be known about a backlog item before it is considered for Sprint/Iteration planning.
2. Invite the team to generate various items that would be needed for a backlog item to be considered for planning. Allow 5 minutes or so for the items to  generate these items and when it feels like the group isn’t generating anymore, stop. You may need to add time if the items are still coming in at 5 minutes.
3. Have the team vote on which items feel critical to be considered. Give them 5 votes each and let them know they can place multiple votes on one item or spread them out as they see fit.
4. Sort the voted items in order of highest voted. The first 4-5 items should be no brainers to include in the DoR. I typically start at the 5 or 6 priority item and ask the team how critical they feel this item is. If the group feels it is, add and then move onto the next item, asking the same question.

Definition of Ready Example

• Clear Acceptance Criteria
• Has business value
• Small enough to be completed within a sprint
• Team understands how to demonstrate
• Necessary environments are available
• Content is finalized
• Testable examples
• External dependencies are identified and available during implementation time

Now we have a DoR, what do we do with It?

With the DoR created it is time to post it in very visible places. If the team is collocated then the DoR can be printed poster-sized and hung on the wall in the room where the backlog items will be refined/groomed. Additionally post it to an obvious place on the team’s collaboration/knowledge sharing tool (i.e. Jira, VersionOne, Trello). Other teams have created a DoR checklist on each backlog item in the tool.

Is the DoR Static?

No. It should evolve over time. If the team continues to struggle with completing some backlog items, identify if their is a common impediment that is causing this. If so, add a new item to the DoR that will ensure any further backlog items won’t be pulled in.

Alright, what are you waiting for, go put a meeting invite on the calendar to create your initial DoR and start putting it into action. Before you know it the team will be consistently delivering backlog items within a Sprint/Iteration. Good luck.

The post How Do We Know When a Backlog Item is Ready for Development? appeared first on An Agile Mind.

Having facilitated many retrospectives over the years, there is common format (excuse the image pun, “4” mat) that I have found helpful regardless of the technique (check out my Favorite Retrospective Techniques post) used. The format used is based primarily from what I learned at The Agile Facilitator course by the Agile Coaching Institute, and what I read in Ester Derby and Diana Larsen’s, “Agile Retrospectives: Making Good Teams Great” book. If you haven’t done so already, I highly recommend attending the course and reading the book, for sure.

Retrospective Format

The format goes in the following order:

1. Warm up (get all attendees to say something, however short)
2. Set the Stage (why are we here, what is the agenda)
3. Check In with Previous Improvement Plan
4. Gather Data
5. Brainstorm/Generate Insights
6. Explain/Combine
7. Vote
8. Develop Action Plan
9. Wrap up (thank everyone)

Warm up

This is a simple technique to get each attendee to say something. This helps even the most introverted feel more comfortable sharing later when asked to come up with ideas. Typically I use something like a weather forecast to describe what we are retrospecting. For example, if it was about the last sprint (Scrum terms for a duration of time to build a working piece of product, typically 2 weeks or less), one attendee may say, “cloudy with a chance of rain.” Another might say, “Thunderstorms with lighting.” I don’t ask anyone to explain further just provide your weather forecast, that is it. You would be surprised how much this technique opens the quiet ones into sharing.

Another warm up technique is just to allow each attendee a maximum number of words to describe what is being retrospected. I usually go with 5 words or less.

Set the Stage

Give the purpose of the meeting and walk through the rest of the agenda. I make sure to remind the group that we aren’t here to blame and complain, we are here to help ourselves (the team) improve as a team. Walk through the technique (pick from one in this post) that will be used. Note: You should have already planned how long each agenda item will take and as the facilitator be mindful of this as the retrospective unfolds.

Check In with Previous Improvement Plan

This is one of the most important steps to me. It is important to check in with how the last retrospective improvement plan went. If you set a measurable goal for the plan, for example, pair program at least 2 hours per day, than you can use this time to see if the improvement plan was successful or not. Also use the time to see how the team felt about the improvement plan and whether they felt it is better than before. It may take multiple iterations to get accurate measurements, so this may just serve as a check in to see how the improvement plan is going.

Gather Data & Display

Gathering data usually happens during the iteration/release that is being retrospected. It could include snapshots of teams task board throughout the iteration. Other useful data to provide is defect counts, cycle time, lead time, velocity/throughput, customer satisfaction, test code coverage, time spent fixing defects, burndown/burn up charts.

Don’t shy away from gathering feelings either. I have found it helpful to collect data throughout an iteration where teams simply give a 1 to 5 rating on their happiness and then this is presented during the retrospective.

Brainstorm/Generate Insights

Typically I use silent brainstorming, about 5 minutes where the attendees are writing on Sticky notes and posting them on the board. I make sure I preface this section by saying that we aren’t looking for solutions on the sticky notes. We are looking for ideas. Then I give some examples of what a solution looks like versus an idea. An example of a solution might be, “start stand up on time,” “stop checking in code only at the end of sprint,” or “have the Product Owner attend the stand up.” An example of ideas might be, “start communicating more,” “stop working on so many projects at once,” or “start sharing knowledge.”

I typically announce what is written on the Sticky notes as they are placed on the board. I find that this spurs others to think of something they hadn’t thought of. Some can find this distracting, so feel out whether the group is okay with this.

Explain/Combine

After the brainstorming section, allow the group to review what was submitted and ask if they would like any clarification on what was submitted. If there are some obvious ones that might be misunderstood, invite the submitter to provide some more context. If there are also ideas that seem similar or the same, ask the group if you may combine them.

Vote

With the group understanding what each idea means, it is time to vote. I tell the group that their vote is going to the idea or ideas that they think will have the highest return on energy to implement.

I typically give each attendee 3 or 5 votes. If I have dot stickers laying around, I pass those out. Nine times out of ten, I usually just have them use a marker to indicate a vote. Making sure that they put the mark on the sticky note. A word of caution here, make sure the attendees don’t use a permanent marker on a whiteboard if you are collocated. I have made that mistake before. Luckily a dry erase marker over the permanent marking will remove it with a little elbow grease.

I tell the group that they can place all their votes on one idea or spread them across multiple ideas.

Once everyone has voted, sum up the votes on each idea and then move the top voted ideas (no more than 3) to different section. I usually label this section, “Develop Action Plan.”

Develop Action Plan

Now is the time to get the biggest value out of the retrospective. Developing the action plan from the top voted idea(s). Hopefully you have at least 15 minutes left until the scheduled meeting end time. And make sure that 2 minutes is left for wrapping up.

I focus the group to think about what measurable actions can be taken to improve the top voted idea. As actions begin coming, either invite a participant to write it down and bring it up or write it down for the group. Make sure the action is measurable and then once it is, invite one of the participants to be the champion/cheerleader of this action. This is very important. I express that the champion/cheerleader is not necessarily the person that will implement the action but will be the one that holds the group accountable for implementing it.

For example, if the group voted “Start meetings on time” as their highest vote, then one action might be “Start daily at 9am with the conference line up and taskboard shared before the start time.” One of the team members can champion this action and monitor it for the upcoming weeks and also remind the group when they aren’t doing this.

I prefer to fully develop each action, one at a time, so that if the meeting end time happens then the group has at least some actions to implement.

Wrap Up

You may not get through all of the top voted ideas before the end of the meeting. That is okay, if these are continued issues, they will come up again. End the meeting on time and celebrate what actions were developed.

Thank the entire group for their contributions and presence.

Alright, well that wraps up My Go To Retrospective Format. I invite you to give it a shot and let me know how it goes in the comments.

The post My Go To Retrospective Format appeared first on An Agile Mind.

Below are a collection of retrospective techniques that I have found very useful over the years. There are many more that I have also used but these are the ones I lean on heavily. I think it is very important to vary the format of any retrospective if you are typically facilitating them with the same group of people over time. This keeps it fresh and new ideas flow when you change techniques.

If you want to know what format I typically use with these techniques, read My Go To Retrospective Format blog post.

With each of the techniques below I am expecting that these will be used to allow the group to generate ideas for improvement that will lead to an action plan owned by one or many of the group members.

Favorite Retrospective Techniques

Start, Stop, Continue (Keep)

Simple yet very effective. Label 3 separate columns for the group to add ideas, similar to the picture below. Ask the group what would you start doing, stop doing, or continue (or keep) doing to improve what is being retrospected (i.e. the team, a process).

Start Stop Continue Retrospective

Starfish

This is an similar to the Start, Stop, Continue retrospective with a couple of extra categories. Draw a starfish pattern on the white board or on your virtual white board with the labels for each category similar to the picture below. Here I ask the group what would you start doing, stop doing, keep doing, have more of, or less of that will help improve what is being retrospected (i.e. the team, a process).

Starfish Retrospective

Speedboat

Draw a picture of a speedboat or sailboat with a few anchors under the water, an island in the distance, and some rocks up ahead. See the picture below for an example. Then ask the group, imagine our team is a speedboat/sailboat and our destination is the island in the distance what is slowing us down (anchors), what could speed us up (tailwinds), what obstacles might get in our way (rocks). The island can represent the team in a higher performing state or maybe it is the process the group is trying to improve.

Speedboat Retrospective

Timeline

The timeline retrospective requires a little more homework by the facilitator and team members. The facilitator will need to capture major events (both positive and negative) that occur during the time frame being retrospected. Typically I use this to span a time greater than a single Sprint/Iteration (two weeks or less). Most likely for a release (1 to 3 months). It is possible for the team to do this as well during the time period that will be retrospected. I have had a whiteboard with the timeline and some different colored stickies to indicate positive and negative events.

During the time frame when an event occurs, note it and place it on the whiteboard. If you are going to collect the team happiness through out then make sure each team member is surveyed for a happiness value at periodic times. I usually just make up coins with numbers 1 through 5 on them. A 1 indicates unhappy, a 5 indicates happy. Or you can print out the happiness coins below and use them. This can be collected anonymously as the team ends their daily stand up.

Happiness Vote Coins

For the retrospective, have the group meet near the whiteboard or take a picture of it and project it in the meeting room. If you follow a retrospective format similar to what I typically do, during the brainstorming section ask the team open ended questions. For example:

• “What do you make of our timeline?”
• “What can be done about the events that occurred?”
• “How often are we experiencing these events?”
• “What is the root cause of these events?”

Timeline Retrospective

These are my favorites, what has been your experience with any of these? Comment below. If you have one that you go to, I would love to here about it in the comments.

Additional Resources:

• Start, Stop, Continue by Retrium
• Start, Stop, Continue by Mountain Goat Software
• Starfish Retrospective by Fun Retrospectives
• Speedboat Retrospective (the original geared towards customer satisfaction)
• Agile Retrospectives: Making Good Teams Great by Diana Larsen and Ester Derby

The post Favorite Retrospective Techniques appeared first on An Agile Mind.