The importance of Retrospectives

"Can't we just skip the Retrospectives when we don't have the time?"

While I am myself not a big fan of the Retropective events that I see in many Scrum teams - when considering skipping Retrospectives, we solve the wrong problem: Retrospectives are Scrum's engine of Continuous Improvment. What matters is not the event, but that the team is constantly taking active steps of improvment. Retrospectives just kick-start the mindset of improvement.

The case for Retrospectives

• The purpose of the Retrospective is finding significant improvement potential. 
•  Significant, from a statistical point of view, is 5% or above. 
•  "5% or above" means, "Something worth at least 2 hours a week" 
• Investing 2 hours every 2 weeks to find something worth 2 hours per week already paid off within a single Sprint. 
•  A team improving by 5%, 25 times a year, will operate at over 300% of their original performance after a year - yes, they will be three times as effective as when they started!
•  A team skipping half of their Retrospectives, doing only 10 a year, will have improved to 150% of their original performance after a year - give or take variation, it will appear as if this team hasn't improved and is almost at their original level.
• A team having effective Retros every Sprint will visibly outperform a team skipping half of their Retros - to the point where they deliver twice the value per time. 
• Or, stated differently - a year down the line, a team doing effective Retros will be worth as much as two teams skimping Retros, and as much as three teams without any effective Retros.

The Bang for the Buck

A team investing into effective Retrospectives is worth twice as much to the company as a team which values delivery over improvement.

Teams taking Retroespectives seriously lead to an organization needing fewer people to deliver the same value. Hence, less coordination. Hence, teams get more autonomy, because they don't need to fit into a management corset.

Hence, developers can spend more of their time doing what they like best: writing code, not sitting in meetings. That makes them happier. And happy brains are more productive.

Also, since developers in such teams are worth so much more to the company, they are worth every cent - a great argument for negotiating higher pay.

Effective Continuous Improvement makes everyone a winner: Customers, getting better products quicker. The company, getting more value without hiring extra people. Developers, who get better working conditions, and deserve higher pay.

Retrospective Antipatterns

We have already touched the first antipattern: Skimping Retrospectives. Every lost opportunity of a Retrospective is an improvement not happening, putting the team behind on their potential, sacrificing a lot in the future to gain very little right now.

Skipping Retrospectives usually happens because teams have ineffective Retros. Each Retrospective that didn't deliver a significant improvement outcome was a waste. Hence, teams need to figure out how to get more value out of their Retro. Hint for Scrum Masters - There's a surprisingly low correlation between form and effectiveness of a Retro.

The third antipattern is giving up too early on improvement: If there are impediments towards improvenent, these need to be resolved, rather than taken as a reason to not improve.

If you feel that Retrospectives don't make you better, then improving that is your highest priority.

True story

I don't like formal Retrospective events all that much, but I do like a good continuous improvement process (CIP). Retrospectives are just one way to do it. CIP can be done totally informal. I just want to tell you this story to see how Retrospectives can transform a team.

One of my teams had a 2-hour lunch break every day. This "break" included having a walk, and talking about improvements. 

After 2 months, we delivered in a week what others would do in a month.

Within 3 months, we finished a project we had forecasted to take roughly half a year. 

Spending only 6 hours a day at our desks.

That's the power of Continuous Improvement done right.

Notice:

In the Post-Scrum Manifesto, I explain why active, continuous improvement is better than Retrospectives - and also, what you might be getting wrong about your Retrospectives at the moment.

Tool Tip - The Change Compass

 If you're looking for a simple, yet efficient tool to help you create transparency on how your team is developing and growing, you may want to try the "Change Compass" in one of your Retrospectives:

The x-dimension is labelled "Calm" vs "Stormy", and the y-dimension "Improving" vs. "Worsening". Like this, it becomes a 2D mood-meter on where your team thinks they're heading.

How to use

Give people one minute to put a marker on the compass in whatever place they feel is most appropriate. Any place on the compass is fine, because we're mostly interested in a direction.

• "Calm" would mean "Nothing is really happening, there's no speed."
• "Stormy" would mean "We're in for a rough ride, faster than we can control."
• "Improving" would mean "Things are getting better"
• "Worsening" would mean "Things are getting worse"

Directional Patterns

When looking at the results, you don't need to interpret every single note. Instead, try to look for some key patterns.

The list of patterns here are the most common ones you can spot, although there may be others.

Making Progress

Our "True North" is positive change at a sustainable pace.

A healthy team undergoing healthy change would place their markers on the top third of the compass, preferably close to the center.

Too far on the left means we're not moving as fast as we could, while too far on the right means we may be overburdening the team, potentially making change an impediment in and of itself.

Comfort zone

When everyone feel that we're neither getting worse nor better, and there's no motion, people operate in their comfort zone.

This is good after a long, bumpy ride, but shouldn't be a permanent condition: There's no change without change, so this might trigger a discussion about where we can improve.

Change Fatigue

Sometimes, people have the impression that we're moving fast, but nowhere.

In this case, it's pretty important to have a conversation about what we're trying to accomplish.

We're losing 'em

When you see this, the team is torn. Some people feel the change is moving too slow, others feel things are moving too fast and/or in the wrong direction.

This would be a great time to have a conversation about what causes the different perceptions. Maybe the people who are uncomfortable see something the others don't - or vice versa?

No clear direction

With this pattern, it's almost irrelevant whether the points are on the left, center or right of the compass.

The key realization here is that people are disoriented - they don't know where they're headed, or what the outcome will be.

Maybe we lack transparency of what's going on?

Business as usual

People are in motion, at a comfortable pace, but nothing is really getting better.

Are we not even trying to change, or are we trying and see nothing coming out?
What do we need to change, so that things actually improve?

Change Theater

We're moving, but not where we want to go.

The further people move their markers to the bottom, the more likely you should stop and entirely reconsider whatever you're doing.

Dealing with the results

As long as you're "making progress", there's not much to discuss, and the exercise could be over within minutes.

In any other case, you need to start an conversation about what the results mean for your team.

The outcome of a Change Compass session should be that you:

• pick up speed when you're in a calm
• slow down when you're in stormy conditions
• Correct course when you're worsening
• Reconsider when you're not improving

In any case, it creates transparency on how your team thinks about your improvement efforts.

Alternative uses

The Change Compass can also be used in stakeholder environments, i.e.:

• to conclude a Sprint Review (to see how customers think about the team's progress)
• in management sessions, to see how the "outside-in" perspective on the team is
• to provide management feedback when the team feels things are blocked or going wrong

Five Principles of Organizational Agility

Do we need frameworks to be agile or not? 
Maybe. If we have a problem that frameworks solve. And if they are an appropriate solution.
Here are my five principles for change, which are paramount to the question of frameworks.

If you adhere to these five principles, my question would be: "What do you expect from an organizational framework?"

1 - Frame your problem properly

Learn to understand your problem before implementing a solution.
A poorly framed problem's solution may be worse than the current state.

Go beyond both the symptom and the Obvious and frame the problem correctly. And when you learn that you framed the problem in the wrong way, refine your problem statement rather than "working harder" to make the solution work.

There are great tools, like Ishikawa Diagrams, 5-Why-Analysis and many others which can assist you in getting closer to what your real problem is, in a very short time.

2 - Limit change

Only reduce the bottleneck constraint that causes the problem.
Large-scale changes will have uncontrollable, large-scale impact.

Figure out what the bottleneck is, why things aren't moving smoother.
When you know where the bottleneck is, be uncompromizing on making a change. By accepting the bottleneck and making a change elsewhere, you destroy the change process overall.

Tools like Process Mapping, Flow Diagrams, Lead Time Analysis and many others that will help you discover the single point where a change will be effective.

3 - Simplify change

Do the simplest possible thing to reduce constraints on the current bottleneck.
Change should be so simple that it's effortless - if our idea doesn't work, we just try the next one until we find something that does work, and that's a lot easier when we make small, simple changes rather than implementing grandiose master plans.

Simplicity is an art - "anyone can make things complicated, it takes a genius to come up with something simple". When geniuses are hard to come by, it helps to involve the people who actually face the problem, as they often have a pretty good idea why something doesn't work, and they may just need the permission to do the right thing instead.

4 - Subtract before you add

Eliminate structures, processes or tools that cause problems.
The "simplest possible thing" we can do is usually getting rid of a blockage, not adding something.
Problems don't get solved by adding something on top.

Additions to an existing problem are like band-aids on a cracked pavement: They won't really help, won't last and won't make much of a difference. The existing problem needs to be addressed and removed. Often, this is already enough.

I like to use tools like Marshall Goldsmith's "Wheel of Change" to model the change, and tend to remind people that "For each thing you add, you have to remove one thing", because otherwise we create more problems (oftentimes elsewhere) instead of solving them.

5 - Verify outcomes

Verify your outcomes before calling something a success.
Change is successful when the problem is gone.

Many organizations call change successful when the change is implemented - which often leads to "change for the sake of change", and people getting rewarded for doing things that don't help the company.

We can use methods like OKR to define which outcome we want to see, and if we didn't achieve this outcome, that should at least trigger the question of what the change has done instead.



Closing remarks
These five principles stand together and should be applied together.

A well-defined problem allows us to run a minimal change experiment in the right place, which allows us to verify fast and cheaply whether we're making an impact. And we need to get rid of at least one root cause of the problem to make such an impact.

The 5-minute Retrospective: Try Speedrospectives!

Agility depends on receiving timely feedback and turning it into effective change action. Relentless improvement requires closing feedback cycles wherever possible and whenever possible. 

Why Speedrospectives?

Many new Scrum Masters follow the boring, time-consuming and ineffective "What went well/what didn't go so well" template and can burn hours of precious team time without causing significant change - this model often degrades to a platform for self-adulation and/or ranting.

The Scrum Master -- or any agile coach, for that matter -- should create a self-perpetuating system of Kaizen, "Striving for the better", and do this in the most effective way.

Have you considered a Retrospective after every single meeting in your organization, to improve these meetings themselves and thereby increase the value of communication? How much time should that consume to be worthwhile?
A regular Retrospective is unfeasible in this context - but where, when and how do you address improvement potential then?

An important part of behavioural change is to address the situation as it occurs so that the memory is still fresh and set the stage for a future, more desirable condition.

The 5-minute Retrospective

When you know your audience and the situation is already stable, there's no need to go through the (definitely helpful) 5-stage Retrospective Process, you can just cut straight to the heart of the matter: What should be different next time in order to get more value?

And that's where my handy Speedrospective template comes into play:

The diagram itself is self-explanatory:
"If we do this again, the next time, we should ..."

• Try: Introduce a new element or modify an existing element. For example, in a Retrospective, it could be: "Try whiteboards instead of sketching on letter-sized paper"
• Stop: Elements which should not be repeated. For example: "Multiple people talking"
• More: Elements which are helpful and could use strengthening. For example: "Collaboration on issues"
• Less:  Elements which, although helpful, are overdosed. For example: "Process explanation".

Schedule of the Speedrospective

Create sketch

If you're fast (which is what this is about), you draw an X and write 4 words. That should just take half a minute - or a minute, while you're explaining what's coming. (1min)

Collect items

Take 2 minutes to collect feedback - more time isn't needed, because if participants don't have anything on their mind, it's probably not important, anyways - and next time around they might prepare a sticky right in the moment when something happens because they know they can bring it up. (2min)

Decide

After issues are collected, vote ONE the group would like to see implemented. (1min)

Debrief

Agree how to make it happen and thank the group. (1min)

Summary

Speedrospectives are a highly effective tool to close feedback loops, initiate change and establish a culture of relentless improvement. The process is significantly more powerful than the "well/not well" template, because it's fully outcome focused.

Other uses

The suggested Speedrospective template can be used in many contexts, such as event closure - as well as in personal and organizational coaching.

Variations

There are many ways to commence a change-driving Retrospective within 5 minutes. The above approach is neither to be considered prescriptive nor the only way. Try experimenting with Speedrospectives and see what works for you.

A note of caution

Speedrospectives may miss fundamental change opportunities - for example, when we're having the daily frontend architecture status meeting, we will find ways of getting the most value out of this meeting without ever crossing the idea that the meeting itself isn't a good idea. They are not a panacea, just a simple power tool to support a continuous change mindset.

The IOWA-Number - a tool for team building

Not every person contributes equal amounts on the team, and that's often okay. But there are some cases, where a conversation is needed. I devised the IOWA Number as a tool to identify these cases.

Applying the tool

The IOWA Number can be used in the "Gather Data" stage of a Retrospective with the question: "How do you feel about your team members?" This does require a certain level of trust within the team to work properly, and be clear that the tool isn't meant to highlight people as problems, but much rather to help the team find itself properly. There is no score that's inherently good or bad, just some scores that will lead to further conversation down the road.
Most importantly, only apply the tool when you have a feeling that there are some outliers, as the tool is merely intended to open up a conversation on becoming better at collaborating!

Extremely low scores

In some, rare cases the team will feel that a person's absence will actually have a positive effect on outcome.
The most notable case of this happening is usually when said person is lacking so much knowledge that their questions disrupt the others' flow of work. A good way to strengthen the team would be to put delivery work a bit on the backburner and work intensely to bring the person back to speed.
Another common case would be that said person doesn't really understand the impact of their own way of working on the team, often due to being unfamiliar with others' self-organized ways of working.

In any case, team members with extremely low IOWA score need the team's support to rise to higher levels and the team should have an open conversation which behaviours are reducing IOWA score and which behaviours would increase it.

Moderate scores

Anything between 3 and 7 is usual. There's not much to discuss, unless there are tendencies towards an extreme. But since IOWA numbers are nothing more than a snapshot in time, it would be better to use the extreme value right away, as it doesn't make sense to defer a conversation.

Extremely high scores

There's no way to sugar-coat it, high IOWA scores are a risk, potentially even a threat to the team's sustainability!
People typically do not choose to have high IOWA score, they receive that score because they have superior understanding of a subject matter and a strong drive for action. Usually, they feel they are helping the team and the organization by working this way, and in fact - when it comes to getting stuff done, they help a lot.
Unfortunately, all of their help us unsustainable, as the team immediately falters when they aren't available and if for some reason, they should be out (e.g. sickness, family issues etc.) their absence could bring the entire team and whatever the team was working on to a standstill or collapse.

As I wrote in my book, "Extreme Agility", my suggested course of action would be to relieve the person from the responsibility of doing whatever they do so well and instead coach and support the rest of the team in this. It should be exceedingly clear that they aren't taken out of the delivering function because anything is wrong with them, but because they are needed as multiplicators in order to grow the team.

Conclusion

IOWA Numbers are a conversation starter when the team is on uneven footing. It's not intended to judge or condemn the work or contribution of any individual, much rather it is intended to bring people to a more equal footing in order to increase the team's sustainability.

In some cases, it may even be worthwhile to create IOWA Numbers for people in the team's close vicintity, such as traditional line managers. If this is done, be sure to include them in the Retrospective (which is rather unusual).

Bringing power into your Retrospectives

Many people consider that the purpose of a Retrospective is to let the team reflect what went good or bad in the last iteration, then decide on a few significant modifications to the process. Well - that's not wrong. Yet, it's a bit short-sighted. The most powerful retrospectives transcend that level. Here are a few pointers:

Bored of yet another Good-Bad-Improve Retro? Good!

Fit for purpose

Let's start out with the question: What is the purpose of a Retrospective? The obvious answer is: "To improve the process." Let's dig below the surface by asking more specifically: What determines the effectiveness of the process?

Actions
An action is either what we do - or how we do things, You can not expect to have an effective process if it contains ineffective actions. Therefore, we desire to replace actions with more effective actions. Likewise, we like to abolish unnecessary actions. And we should harness the power of our most effective actions.

The standard purpose of retrospectives is to improve actions of the team.

Focus
The more things you do at the same time, the less focused your work is. The more disruptions of the work we tolerate, the less business results we create. An unfocused process generates low value even when every actions is maximized for effectivity.

Another purpose of retrospectives might be to increase focus of the team.

Reflection
While Retrospectives are a points of reflection, they are often induced, triggered reflection. Having reflection points on the calendar is good - albeit very limited. To reduce delays in improvement, increase understanding and maximize the likelihood of successful changes, reflection needs to be an innate skill of the team.

Retrospectives can help the team improve their reflection ability.

Systems Thinking
The system within which a team operates constrains the team in many ways that they may be unaware of. For example, a local optimization may make work easier for the team, yet destroy business opportunities and therefore reduce sustainability. Understanding the impact of the system on the team and the impact of the team on the system is essential to effectively improve.

Retrospectives can foster Systems Thinking.

Collaboration

Collaboration is not only how individual people do their work with proper alignment - it is how people integrate their work with each other. Just like Pair Programming combines two brains on one task, collaboration enables the team to accomplish the same thing easier, faster and better. 

Retrospectives may open doors for better collaboration.

Observation
A team which is coached through a Retrospective is not only conducting activities. While the coach provides tasks to the team in order to guide their reflection process, the coach has the precious opportunity to observe how the team behaves and thinks in a controlled, protected environment.

Retrospectives are a tremendous opportunity to observe.

Experimentation
A wise coach not only leads a Retrospective to a result by guiding the team through the Retrospective process, the coach actively controls the process and experiments with the social and creative dynamics of the team while doing so. This experiment generates insights into the psychological and social structure of the team, which can later be used to change behaviours.

Retrospectives are the coach's experimentation sandbox.

Summary

To maximize the power of your retrospectives, you need to transcend the level of simply defining improvement actions. Use Retrospectives on multiple levels at the same time to:

• Improve the process
• Focus the team
• Instill a reflection mindset
• Nurture collaboration
• Observe the team
• Conduct social experiments

When planning your Retrospectives, move away from finding techniques which entertain the team while going through the mandatory frequent improvement routine. Transcend this level and look for ways to work with the team on many levels.

The potential optimization goals of Retrospectives described in this article are not comprehensive. They are intended as a reflection opportunity to maximize the impact of your Retrospectives.

Add power to your Retrospectives by clearly determining the goals you want to reach, then finding ways to achieve this. 

Happy New Year: A forward-looking Retrospective approach

Most retrospective techniques focus on analyzing past events, leading to introspection of transpired events. I have created the "Happy New Year" technique to help teams transcend the past and orient towards the future. I will introduce it to you for your own perusal:

A look at the clairvoyance Retro

Step 1- Prepare

Horizon

In the first step, create a 2x2 matrix and entitle it with the period the team should address.
Now, in January, it's a decent idea to take the new year. Taking the "next release" the next fiscal quarter may be exactly as valid, it depends on how far ahead you want to look.

Good and Bad

Entitle the columns with "Good" (fortunate) and "Bad" (unfortunate). Now, I've used a four-leaf-clover and a "Friday 13th" (as today is just that day) to depict these, you can feel free to use your own.
The idea is that in the left column, the team should enter events that will help the team - and in the right column, events that become setbacks.

Prediction and Wish

The rows are entitled "Prediction" and "Wish". I used a crystal ball for the predictions and a magic genie lamp to depict them.
The idea is that in the upper row, the team should enter events that are fairly likely to occur - and in the lower row, events that the team hopes, even though there is no evidence that they will happen.

The four squares

The upper-left square is "Predict-Good". This is for upcoming events that the team looks forward, such as "We get Magic Leap on our desks".

The upper-right square is "Predict-Bad". Transpiring events the team would prefer to avoid, if possible - such as "A competitor takes over some of our customers".

The lower-left square is "Wish-Good". This is what the team might wish for - such as "Our product wins the NetGeeks award".

The final, lower-right square, "Wish-Bad", requires a bit of further explanation: Who would wish for bad things? Here, we are looking for events that will severely disrupt our team/organization with an opportunity for massive change. For example "Our cloud hoster goes bankrupt" would result in massive business loss, yet it would be a great opportunity to discover a better hosting strategy.

Step 2 - Collect

Let the team think

Instruct: "For each of these four scenarios - name specific events that you can think of. Try to find at least 1, and no more than 2, items for each of the boxes."
Give the team 5 minutes of silence so that each team member has enough time write their own sticky notes.

Post and Introduce

After the time is up, let the team members post their sticky notes on the board, introducing with a few sentences what the item is. At this time, do not discuss further implications or potential solutions.

Clarify

Potentially, the team will come up with items which are not events, such as "We learn something new" - which is more of an ongoing process than something that you could stick on a calendar and validate with a yes/no hypothesis test. Let the author re-formulate these into an event (e.g., "We attend a HTML class")

Filter

Any duplicate notes should be removed. 

Rearrange

Let the team members quickly discuss whether the notes are in the right segment - are the predictions more like wishes, are the wishes actually coming true already?

Step 3 - Prioritize

You can use dot-voting or any other technique to let the team select a few topics for further exploration.

Hint: In some cases, it's useful to de-scope elements from one (or more) box, such as "Predict-Good", if your intention is more to challenge the team.

Step 4 - Discuss

Depending on the box, the discussion questions look different.

Predictions: "What will we do after this happens?" - and: "How can we ensure/avoid this?"

Wishes: "Why would we want this to happen?" - and: "What will come out of that?"

It's a good idea to write down the key points of the discussion for reference.

Discuss one or two items - and jot down the key points.

Step 5 - Refocus

The discussion will most likely yield multiple strands. In order to elaborate specific actions, you will need to refocus by shutting down all but one or two of them. Again, you can use a technique like dot-voting to let the team autonomously decide with which item to proceed.

Limit the things you want to work on

Step 6 - Propose

In the final step, the team should decide on a way forward, elaborating specific actions to steer into the desired direction.
Topics which are long-term relevant are often not resolved with a single change - potentially, a series of changes need to be made which take some time. If this is the case, simply create a timeline and discuss what you want to do when.

Create a timeline until when ou want to reach your goal.
Make sure people take responsibility.

So, that's it. Have fun, good luck - I wish you great new insights.

The Discovery Questions in agile development

For teams just transitioning to agility, the question arises: "How do we test in an agile team? Which test types do we need?"
There is stuff like the Agile Test Quadrants which are often suggested as guidance. On a different level of abstraction, we have the Test Pyramid. You might look for gaps in your existing test approach and try to cover them as well as possible. You will soon discover that this will not really help, as you merely introduce a structure, but don't solve the underlying "Why" questions.
In another article, we discussed what agile testing is all about.

Let us look at a small visualization of what we are actually looking for when we are discussing quality:

The quality discovery questions.
The matrix can be used to guide a Retrospective on quality.

When we have a new idea (or: Product Backlog item), we first need to discover "What do we want to build in order to make this happen?". This is the specification. The quality of the specification determines the quality of the solution. A basic idea of (A)TDD is to consider functional tests and specification to be the same thing.

In the next step, we need to discover "How do we want to build it, so that it works properly?" This is the source code. Code quality affects both the solution quality and the way how to control quality in the process.

After the code has been built and deployed (into a staging environment) there may still be things going on that we never expected. These are side effects. We need to answer the question: "What happens that we didn't think of?" We don't want that to be many things, but it can always happen.

When we deliver Working Software to the customer, we learn: "What do real users do with the product and how do they use it?" This is user feedback. We use this feedback toadapt our current product in order to maximize value, As we learn more about our users and markets, we will need to adjust our priorities, both strategically for the product and in testing.

Uncertainty

During planning, we try to remove as much uncertainty from implementation as possible. The better our tests are in this stage, the lower our risk of building the product wrong. We do not want to guess whether we built it right based on our idea. We want to be certain. Until we can do this, our first priority is to eliminate the risk of building the product wrong.

After building, we need to validate whether our idea made sense. The more accurate our tests are in this stage, the less likely we will deliver an unsatisfactory product. With the final product in hand, there should be no need to check whether we did do things right based on our idea - only whether our assumptions seem solid.

Early feedback

Each of the four quadrants correlates to a phase in development: Planning, building, deployment and operations. A good way to check whether your current testing approach is effective is by asking the question: "Which activities we do are we doing in which phase?"

If, for example, you realize that you are discovering or verifying acceptance criteria after deployment, you have potential for improvement. A good way to approach this improvement is by asking the question: "Which activities can we do earlier in order to remove the need to do them (so) late?"

Conclusion

A solid agile test strategy removes uncertainty as early as possible. 

The best way to start implementing agile testing is not by focusing on a prescribed set, but by asking: "How can we remove as much uncertainty as early as possible?"

When is Data Driven Decision Making applicable?

Agile companies usually declare "Data Driven Decision Making" as a fundamental principle, because data forms the basis for empiricism.
The standard Retrospective format lists "Gather data" as one of the key stages. But when is it actually a good idea to start gathering data - and when do we stop gathering data?

To understand why we would even gather data, let us start with the problem. Basically, we want to gather data in order to help define the problem we observe and how we are going to solve it. Gathering data without a problem that needs to be solved is waste.

Here are a few types of problems you might be facing:

We don't (really) have a problem with that

Well, then ... work on something that is a problem. Easy.

We already know the root cause and solution

Well, then ... Go Fix it! Easy.

We know the root cause, but no solution

We need to devise an experiment that may bring us one step closer to the solution. After weeding out alternatives, we definitely need to gather data of some sort to help us decide if this experiment can be successful and - after trying it out - whether it actually helped.

We know the root cause, but it's outside our sphere of control

If you can't control it, but you can influence it, the best strategy may be to "make it the problem of someone who can solve it". Find a problem owner who can actually help.
There is not much value in gathering more data, unless that data is required to win a problem owner.

We know the root cause, but it's outside our sphere of influence

This happens, for example, when the problem is caused by a new law passed by the government. You have two choices here: Either, adapt to the new situation or work around. Gathering data will not help you solve the problem, because no solution you devise will be realistic.
However, you might want to collect data which helps you re-define the problem "given the existing external constraints".

We don't know the root cause, or: We don't understand our problem

This is the obvious use case for "Gather data" - go find the root cause, and learn which data can help you do that.

Summary

Data Driven Decision Making has it's uses. However, it is also limited in use. Gathering the wrong or unnecessary data is waste and should be avoided. Which data is "wrong or unnecessary" depends on the problem you are facing.
Therefore, a clear understanding of your problem is essential before actually spending time with data acquisition.

Is you Kanban board healthy?

Have you ever stood in front of a Kanban board and wondered whether the team is actually doing fine?

Here we will discuss a few key concerns that will easily help you discern whether your Kanban board has problems:

What do you see on your Kanban board?

Broken Priority

When picking up a new piece of work, you should choose the top item on the board which is not yet completed. Sometimes people pick the item they prefer doing - ending up with lower priority items getting done first. The good news is that this becomes visible immediately.
If this happens frequently - or your Kanban board looks more like a dotted map than a flow system, you should seriously raise the question "Why do people not work on the highest priority?"

Unfinished Pile

The objective of Kanban is to get as many things into "Done" as fast as possible, where "Done" means "Delivered to the customer". Unfortunately, a wrong definition of "Customer" (e.g. "The next person down the line") invites team members to simply hand over an unfinished item, and work on yet another unfinished item.
When team members do not pick the rightmost "not done" item on the board, but rather any other, this should lead to the question "What prevents us from getting those things done quickly?"

Broken WIP Limits

Specialists often fall into a habit of simply working off their portion of a backlog item, completely disregarding what happens around them. This may cause an "Inventory" problem: The next step down the line may be clogged, with more and more undone work piling up.
Kanban suggests setting WIP limits on queues and stopping the production of ever more inventory before something new gets started.
Observing WIP limits makes it very easy to recognize when this point is reached. Sometimes, teams ignore this and individual columns on the Kanban start cluttering up. In this case, you should raise the question: "How can we avoid clogging this queue?"

Bottlenecks

Another problem of specialists is that they may be a limited resource in completing a specific step in the delivery workflow. If this is the case, we often observe that this step becomes a bottleneck: Some teams permit a huge WIP limit "because it's normal that a lot of stuff is there". Even worse, some abolish the WIP limit for such a step "because we always break it". A bottleneck should never be taken as irresolvable impediment.
When a bottleneck is observed, the team should be even stricter on setting a very low WIP limit. As this WIP limit is broken, this should trigger the question: "Can we re-organize work so that the bottleneck is resolved?"

Queue Mania

Some teams go crazy on Kanban boards - specifically, on electronic boards. It is very convenient to add a column whenever needed, because people feel it helps them organize their work better. Unfortunately, this fails to consider one underlying problem: Each column represents a queue, and each queue is actually a representation of a handover in the process. Handovers cause delay and are considered wasteful in Lean.
When you observe more columns on your Kanban board than you have fingers on one hand, you should ask: "How can we de-fragment our workflow?"

Summary

Starting Kanban is easy, customizing it is also easy. A Kanban board only visualizes what you are doing. To get real benefit out of Kanban, the layout of the board should continuously be put under scrutiny.
When the board looks unhealthy, the team should "stop and fix", using a Retrospective and define measures for Continuous Improvement. Only then will you get real value from doing Kanban.

Quantify problems before solving them

I was recently asked: "How many automated tests, do you think, we need?". An underlying premise was that I would provide an expert opinion on whether the team had the right amount of tests.
I could only reply: "I don't know. If you have a problem with quality, you might need more. If you have a problem with the maintenance of your tests, maybe you need fewer. However, if there is no problem, you're probably doing the right thing."

This one can be abstracted, away from the specific issue of test automation.

If there is no problem, there is nothing to fix. But how do you know if you have a problem then?

Here is a simple suggestion:  Collect data. Then, decide based on facts.

This is an example of how you can track:
Each time your team encounters an issue and spends time with or because of it, make a mark. Your result might then look like this, depending on which activities you are tracking and how you track:

In your retrospectives, you can simply look at the numbers and ask the following questions:

• Does this make sense?
• If not: What should we do about this?
• Will we gain more insight if we get more data in the next iteration?

Summary

"Data Driven Decision Making" is not rocket science. Collecting data can be simple and easy - and require very little preparation or technology. While you may want to refine your collection process depending on your understanding of the problem, the simplest possible solution will often suffice to rule out wasting time on dealing with corner cases or imaginary issues.

Ask the right questions

Questions are your most powerful tool for facilitation.
Many people are afraid to ask questions, because they feel it exposes uncertainty or weakness. But that is not true if you ask the right questions.
The right questions can reveal problems, uncover implicit knowledge, foster mutual understanding and create learning - just to name a few benefits.

Asking the right questions is an art. With one question, you can start, end, derail or destroy a discussion. It's completely up to you to pick the right question. But you can ask many questions:

• Open questions: For example, "What do you think we should do?" - you spark discussions with these. Use them to get others to talk.
• Closed questions: For example, "Do we all agree to do it like this?" - you end discussions with these. Use them to end topics or meetings.
• Probing questions: For example, when a developer proposed a specific approach to a problem, you may ask "What will happen if step 3 doesn't work out?" Use these to create deeper thoughts on specific matters.
• Counter questions: For example, when someone asks you: "Can you arrange an XXL TV for our CI build monitor?" - you may want to ask "What will you be seeing on this monitor?" to get developers to reflect on their expectations or gain further insight.
• Power questions: For example, you may ask "Why are we getting so many customer complaints?" - to provoke deeper thoughts on one specific topic without limiting options.
• Weak questions: To give a negative example, by asking, "Can't we just add more tests?" - you will do the following: Put your opinion above others' expertise, pre-empt a solution that may not even help and end the stream of thought. At worst, you expose a level of ignorance that will cause others to not take you seriously any more.

What you can do

You, too, can learn to ask the right questions.
For your next meeting, prepare one question which fits into that meeting. It may be that you already know the answer for yourself, but you want to check with the team.
Make sure it's a power question and make sure it's formulated as an open question.
Be prepared to add some probing follow-up questions.

Find the right setting to ask your question and wait for the discussion to ensue.

How fancy does a Retrospective need to be?

Especially new Scrum Masters might feel compelled to conduct a firework of Special Effects in order to conduct a Retrospective.
Fancy charts, stand-up exercises and highly facilitated techniques abound: An entire website dedicated to methods for facilitating Retrospective invites experimentation.

But how much glitter and glamour does a Retrospective need?

The Pattern: Funnel results

The general approach, as you can also find in the book "Agile Retrospectives", is a five-step approach to create clear results.
1) Set the stage
2) Gather data
3) Generate insight
4) Decide what to do
5) Close the Retro

That's good. But how formal does it need to be?

The Antipattern: Focus on effect, not content

Maybe you feel tempted or compelled to have a clear method for each of these steps, and want to use memorable patterns to guide the team. Here on this link is what the worst nightmare of an antipattern might look like:

Start out with an exercise with a prepared flip chart, continue with another flip chart, go on with another flip chart, proceed with yet more flip charts and conclude with - guess what - another flip chart!
You can now make this completely awkward for everyone by setting up flips with fancy pictures ("visualization") and asking the participants to write post-it's and put them on the appropriate sections of the chart.

Everyone will remember this Retro for certain - but not positively.

Who needs special effects?

Ask yourself one question: "Why would the team want a Special Effect in the Retrospective?" - if you can not answer the question adequately, any effect you are using is most likely waste.

However, if you find many compelling reasons for why the team can not have a good Retrospective without fancy effects, you should lay them out to the team.  Gather feedback to understand if your reasoning is actually just your opinion, or agreed fact within the team.

Hold a Meta-Loop Retrospective

If the team considers retrospectives stale, consider a Meta-Loop Retrospective: "What do you think about our Retros? How can we improve them?"
Maybe the points revealed would go in the direction of "Make more change happen", or "Reduce time investment", or "Better follow-up". Rarely do the points go in the direction of "Fancier effects, please."
Act on the Meta-Loop Retro before planning new effects. Only plan effects that match improvement potential suggested by the team.

Mind your audience

Regardless of what method you use for your Retrospective, please remember whom the Retrospective is for: It is the team.

Usually, the team consists of a wide variety of people. Some are result-oriented, others data-driven, some are silent observers, others active forerunners - just to name a few conflicting constellations.
Any method which specifically entices one character may be a put-down for another. Chances are that the things which sound fancy to an outgoing Scrum Master are not fun at all for an introvert Developer.

When you are conducting a Retrospective, do not think about "Which effects will make this Retro fancy?" - but ask the question "What would the team actually enjoy?".

Simplicity is essential

When you are conducting the first Retrospective with a team, you may be well advised to understand your team and their expectations first. The only thing you need to ensure is that the Retrospective results in viable change action. And then follow up and make it happen.

The best Retrospective may happen by simply having an open, focused discussion. But that depends on your team.

Use the minimum overhead and the minimum amount of facilitation which will give the team a Retrospective meeting their expectation.
You may occasionally use fancy effects to lighten up the mood, but do not rely on them: Any added effect could become a distraction rather than furthering the discussion.

Act on your Retrospective!

Some teams sit together nicely during the Retrospective, but they will dismiss the Retro as soon as it ends. Thats an antipattern: Improvements elaborated during the Retro are forgotten, nothing changes. This makes the Retro a complete waste and discourages the team.

The Retro should result in an Actionable Item and follow up on this action in the subsequent Retro. Consequently, a failure to actually make the proposed change should spark a Retro topic all by itself.

So, here are a few steps to turn your Retro into change happening:

Link cause and effect

During the Retrospective, there should be a visible line between the input which sparked the proposed change and the change intention. As the Scrum Master, unless the line is blatantly obvious, do not hesitate to iterate the journey verbally: "We discovered that ... which leads us to ... and we hope to address this by ..." . Not only will this increase clarity in the team - if you get it wrong, now is a good time to clarify this.

Be clear

State precisely what you want to change, why you want to change - and what the desired outcome of the change is. Likewise, define who should take the action item and how you will know if you got your intention. As Scrum Master, do not let the team "get away" without having an agreement on these teams.

Follow up

There is nothing worse than having volatile change initiatives without impact. Somewhere during the Sprint, you should have taken the discussed action. And hopefully, there are already results in the next Retrospective. As Scrum Master,  encourage the team to share the effect of the change during the Retrospective before digging into new items.

Learn from action

Provide a forum to discuss the impact, celebrate success and acknowledge learnings from failure. This encourages team members to make the next adjustment, because they will feel that the Retrospective is valuable.
If the change failed, be open about it and discuss whether you want to reverse to the former state or try an alternative route.
If the change was impeded, you can already use that as an entry point for discussion: What can we do about that, how can we be more successful next time?

Summary

As Scrum Master, you must lead the team towards higher productivity. This can only succeed if you take action on your Retrospectives. This requires planning, dedication and followup. Invest time both during the Sprint and the Retrospective to make sure that improvement becomes tangible to the team.

Prepare your Retrospectives!

Why do we have Retrospectives? It may seem obvious, but the idea is not to burn a couple hours in order to reminiscence the past. The idea is to do something better in the future. But how can you get that? You should know what you actually want - and that concerns the entire team!

The best way to get a meaningful result out of the Retrospective is by being prepared. Here are a few pitfalls which indicate your Retro should be prepared better:

Lack of purpose

Many teams focus on the ceremonial part of the event - doing things "because the Scrum guide says so" without comprehending the basic purpose. Much more important than how, where or when a Retro is conducted is the "Why". As mentioned before, the purpose of a Retro is driving the Continuous Improvement. Even before the team enters the room, they should be energized with the idea to drive change.
The Scrum Master can help build this energy level during the entire Sprint, but also by facilitation.

Whimsical input

Some people will only start to consider the Retro when it begins. Improvement potential unearthed during the Sprint is forgotten, they make up something in the heat of the moment just to have said something. This adds complexity to the Retro and may distract from valuable topics. A good way for the Scrum Master to counter this is by setting up an "Impediment Board" and encouraging people to add their impediment items throughout the Sprint. We can then bring this board to the Retro and simply start asking "Now - what?"

No pulse

Especially Scrum Masters sharing multiple teams often fall into the trap of not having taken a pulse for the Retro. Not knowing what is the perspective of the team, they need to waste precious Retrospective time fishing in troubled waters, trying to uncover an issue. Effectively, this is the Scrum Master's equivalent to "Whimsical input": Whimsical facilitation. The best way for the Scrum Master to get a pulse is by silently observing throughout the sprint and giving individual team members to speak up over a cup of coffee in a 1:1 setting.

Conclusion

Retrospectives have a clear, unique and very important purpose of introducing process, structural and organizational change to improve the team.
To get the most out of your Retrospectives, everyone should be well prepared.

Keep your Retrospectives focused!

The retrospective should be oriented towards a meaningful result, as you want something to get better. However, many teams struggle with the notion of Continuous Improvement being the team's responsibility, and so their Retrospectives are derailed.
Unfortunately, it is not only the teams who derail a Retro, but also well-meaning Scrum Masters.

Here are some problems that indicate your Retro may not be meeting its purpose:

Whine-fest

Yes, especially in transitioning organizations, there is often a lot to complain about. Even in well-running environments, we can complain about many things. However, the purpose of the Retro is not to provide a ranting forum, but to elaborate one thing that should be modified. 

Blinders

Often, teams zoom in on one thing that concerns them and their work, ignoring the big picture. Maybe the first thing a team should work on is something that only remotely concerns them, but affects the organization at large? It's just a maybe. But give room to the thought, in order to prevent local optimization. Think Lean: "Optimize the Whole!"

Predetermined agenda

Over-zealous Scrum Masters may be determined to set not only the topic for the Retrospective, but also steer the team towards accepting their solution to the problem. A Scrum Master has the full right to add an observation to the Retrospective, but they must realize they are facilitators, not actors!

Method Circus

There is a tool called "Retromat" out there on the Internet which might encourage over-ambitious Scrum Masters to fire off a wild pandemonium of effects in an attempt to make the Retro memorable. Unfortunately, the Retromat simply randomizes a set of methods without providing a continuum. This distracts, rather than focuses the team. A Scrum Master should be aware that Retrospective tools are intended to focus the team on the issue at hand, not on the method itself. While the Retromat itself is not bad, care must be taken to choose appropriate methods suitable for the session context.

Conclusion

A good Retrospective must be sufficiently open so that everyone can name their biggest concern and gives everyone a voice in the solution process, but quickly provides a funnel towards a single workable change. The facilitation of the Retro should support this process as naturally as possible, while still keeping focus on a meaningful overall outcome.

3 Ways to increase your Retro effectiveness

Inspect and Adapt is at the heart of agility: "Responding to change over following a plan". The Retrospective is Scrum's standard ceremony to discuss potential improvements. However, especially new teams struggle at making Retrospectives effective. Consequently, the ineffective Retro becomes an impediment towards agility. Here are a few tips for new Scrum teams to increase the effectiveness of their Retrospectives.

Get a good room

Since in a Retro, you expect to make a significant change towards a meaningfully positive change, do not let the room hinder the team from coming up with good ideas for change.

Focus

Every minute spent on sidetracks and gimmicks destroys organizational value. Everyone has the responsibility to keep focused during the Retrospective and the Scrum Master's facilitation of the Retro should support this process as naturally as possible.

Preparation

The best way to get a meaningful result out of the Retrospective is by being prepared. On the other hand, being completely unprepared is the best way to make any meeting for any reason whatever - completely ineffective.
Both good teams and Scrum Masters prepare the Retro in advance. Then, they follow through and turn this well-prepared Retro into meaningful and highly effective action.

Summary

Continuous Improvement, is the only way to reach high performance. The Retrospective is the standard mechanism of establishing Continuous Improvement.
On the downside, poor Retrospectives will result in inherently low agility.

A Scrum Master must frequently reflect, "How can we make our Retrospective more effective?" - and adjust their own behaviour accordingly.