TWEAK: Knowledge

Creating great products requires the right environment, the right people - but also the right knowledge. In an ever evolving world, knowledge is not something you can "have", but something to continually strive for. On the quest for mastery, knowledge needs to be taken with special consideration. For each domain, you should see if your team is "struggling to keep up", "well in the loop" or "forerunner". While not everyone can win the race, it is a good idea to invest effort into getting ahead of the game.

As a Scrum Master, you should encourage everyone to broaden their knowledge regarding:

• Technical ExcellenceRegardless of whether it is Java, CSS, JavaScript, Databases or virtualization technologies - the team must be keen on their technical skills.
• Engineering Practices
  Testing, Refactoring, Emergent Design, Automation and many others are all essential to build the product right - all of these are easy to learn, but extremely difficult to master. 
• Product Domain
  Developers who are only technical experts will build the wrong product, unless they actively strive to understand the domain of the product they develop. Low hanging fruit may be out of your reach when you can't make the right connections.
• Agility
  The ideal of infinite Return on Investment requires responding to demand without any delay. Every step you take to be more agile will pay off - but what steps are available to you?
• Organizations
  The team must take steps to actively shape the organization in a positive fashion. To do this, they must understand well how their organization and the world around them "ticks".

Since "knowledge" itself is so broad, there is no definite way to approach broadening knowledge. You may read books, share experiences with your team or others in the organization - build up Communities of Practice, join Special Interest Groups or whatever you see fit. You need to make sure is that people are thirsty for more knowledge. You can't "push" knowledge. People must want it.

TWEAK: Ambition

Ambition is the desire not to just fulfil a duty, but to excel - do something better, achieve something better, be something better. There are many ways to increase ambition in a team, but Trust, Willingness and Energy are preconditions. Ambition is usually present in every person, but unfortunately dormant in poorly managed organizations.
As a Scrum Master, you should look out for these factors to raise ambition:

• Feedback Loops: Acknowledge and credit:
• Positive attitude
• Good ideas
• Good results
• Opportunity: Provide the means for developers to:
• try out new things
• be themselves
• Accomplish something
• Safety: Give people an environment where they can safely:
• Try things that might fail
• Say the wrong thing
• Be silly when they feel the need to

There are pretty much two styles of ambition. Negative ambition cares only for personal advantage and is destructive towards the organization. Positive ambition cares for mutually building things up and usually benefits the individual as much as the organization. Raising up ambition is as important as turning negative ambition into positivity.

TWEAK: Energy

Energy is how things are in motion. Low Energy usually implies that something, somewhere is impedited. Leadership activates energy, on which others either thrive. Similar to physics, in an agile environment, there is the law of "conservation of energy" , i.e. energy exists - the question is: In which state?
As a Scrum Master, here are some forms of energy to look for:

• Motion: Do you see things happening regarding:
• Improving the product?
• Improving the process?
• Teamworking?
• Technical excellence?
• Becoming a better organization?
• Heat: Do you see people caring about these?
• Light: Do people communicate about these, make them transparent?
• Magnetic: Where is conflict or tension regarding these?
• Nuclear: Where is unharnessed, raw potential to create motion, heat or light?

You must understand where the energy is - then, how it can be harnessed - and with whom to work. Where is the heat, where is magnetism - Do you want to shed some light, or set things into motion? There are many ways and there is no "final state". Harnessing energy is a continuous process, and the less directed it is, the more agile the organization becomes. 

The only important aspect of working with energy is: Always make sure the energy is positive. 

TWEAK: Trust!

Your team requires a high level of trust within, from the outside in, and towards the outside. Otherwise it will be difficult to perform properly: Performance will be wasted on "looking good" rather than "being good". Schemes and politics will reduce results accordingly, so trust is your primary factor to work with.

As a Scrum Master, here are the dimensions you should consider:

• Does the team trust 
• each other?
• the Scrum Master?
• their management?
• Product Owner?
• Customers?
• Is this trust mutual?
• What is the basis of the trust relationship?
• Is the trust relationship also transitive, for example: Does the Product Owner also trust the Management dealing properly with the team?
• Is the trust relationship also indirect, for example: Do Customers and Management trust each other?

Building trust is the first and most important pillar for team success. Only when trust is present, technical improvement activities will be effective.

Planning Poker: Why Points, not hours

Many Scrum teams struggle with Planning Poker and it's proper use. A recurring question is: "Can't we just use hours instead?". A mistake some teams make is converting the Points back into Man-Days.

The purpose of Planning Poker

Sprint Planning should contain a C-C-C process (Card, Conversation, Confirmation). In brief: 

1 - the PO displays what they want

2 - the team can probe whether they understand the idea in the same way

3 - the team discusses how they want to approach the topic,

4 - Everyone agrees that this is what will be done.

5 - Rinse, repeat until the team decides their capacity is reached.

Estimation in Story Points is used to quantify complexity of the task. It is actually expected that estimates vary until the team has reached a certain agreement on the complexity. 

Disregarding the accuracy of an estimate, a precise discussion of the factors contributing to complexity will bring the team's estimates closer to each other.

An example dialogue during Planning Poker

The Product Owner introduces the new Widget that will shoot our sales through the roof. Tim estimated a 20, Jane estimated a 3. Jane reasons: "All we need is to build some plastic device, put a chip on it and contact our service URL."

Tim then turns to the PO, "So, you expect the Widget to be usable from anywhere?" - "Yup" - "Even when no Wi-Fi is available?" - "Yup." - "Can we build a first version assuming Wi-Fi is present?" - "Yup." - the precision increased, but the Story has already been split into two pieces. Also, everyone on the team now understands why Tim had serious reservations about the complexity of the issue.

While Tim may now agree with Jane regarding the estimate for the first version, Jane may now also have serious reservations about the second stage, because nobody knows how complex this issue gets if "everywhere" also includes underground, in the absence of cellular and satellite signals.

Estimation is for Innovation

One of the first things which classic project managers must get used to is the idea that software development, as the name indicates, is development. Development is not just working according to plan, but the creation of something which was not in existence before. 

Software is always new: If we use something existing, we simply buy and/or include it. But we don't build it. If we build it, it's new. This means, nobody has done it before - or, at least, not exactly in the same way that we need it. 

How can you know how long something takes that nobody has done before?

You can't - and this is why at best, we estimate, not a detailed forecast.

Let's estimate

To give you some understanding of the difference between an estimate and the quantification of an effort forecast, let's play a game.

As a Product Owner, I have great visions and would ask you to do some estimation for me.

Here are 5 items which will bring great value to mankind:

• Cure for Cancer
• Immortalism
• Cold Fusion
• Warp Engine
• Terraforming

Now, I would like you to estimate these items for me. You can probably come up with a numbering between 1 and 20 for these items, where "1" is the least complex and "20" the most complex issue.

Almost intuitively, your numbering approach will probably revolve mostly about your understanding of the domain as well as the uncertainty you have. The actual "work to do" will probably play a miniscule role.

Estimates are not Man-Days

Can you now assign hours/months/years to each of these items?

In principle, the problem is identical to Software Development: We may have a certain (hopefully, more intricate) understanding of the domain, but we have never done that exactly same thing before. 

We will not know which solution is correct until the solution is correct and in place.  

Since the course of action is prone to change due to any new information we gain while we are working, it makes little sense to plan a specific course of action. Every step depends on the last step taken, and every result either encourages or discourages the next step we had in mind. Sometimes, next steps only become obvious once a specific result has been obtained.

Summary

The purpose of Planning Poker is the facilitation of discussion about complexity and uncertainty. We care for having a common understanding and dealing with the "known unknown". Removing any last bit of uncertainty about the issue might require more effort than actually coming up with a working solution, so we simply accept this uncertainty.

If the work is totally clear, the item is most likely quite small. When things interact, start to depend or become unclear - numbers will increase. A numerical estimate therefore indicates complexity and uncertainty, not work to do.

We purposefully de-scope capacity planning, because we understand that as soon as numbers increase, there will always be a rather high residual error. We value working software over guesswork numbers, so we only estimate enough to know what we intend to do - not what we will be doing for certain. 

We may have hindsight 20-20, but regarding the future, we will always be guessing.

Effective facilitation

The problem of teams new to agility is that they need to self-organize and may not feel ready for that: Self-organization should never be confused with anarchy or absence of order! But how do you conduct an orderly meeting if it is not organized by the team lead?

The answer is: Facilitation replaces direction.

Who needs to facilitate? The obvious answer would be: "The Scrum Master" - for a Scrum team. Or the team coach for another agile team. But that's not the whole story.
For example, Product Owner might want to facilitate Grooming, Refinement, Planning and Reviews without relying on assistance.
For beginning teams, the facilitator should definitely be an experienced coach or Scrum Master. New Scrum Masters need to learn facilitation as quickly as possible. Without an experienced facilitator, you will be doomed to a boatload of frustrating, boring meetings - and there is no guarantee that it will get better!

More advanced teams do not rely on coaches or Scrum Masters for facilitation: The team can somehow facilitate, based on the team's working agreements and social structure and may just require coach intervention for special occasions.


But how do you effectively facilitate?

Purpose

Borrowing from Dan Pink's "Drive", Purpose is an important element of work.  Whatever meeting you are facilitating, ensure that the purpose is clear and meaningful. This will create engagement.
An important aspect of facilitation is ensuring that the purpose does not get diluted or lost. Intervene when the purpose is obviously lost, but permit potentially valuable sidetracks.

Do nothing

A facilitator's job is not to tell others what to do, say or think. Their job is to get others to do, say or think things. Here are three ways how you can actively do nothing to facilitate the meeting:

• Do not feel compelled to break the silence after a question was asked. Be comfortable with silence. Wait until someone else speaks.
• Accept that some of the things which are said may be off topic or misleading: Do not contradict. If you feel the need to intervene, ask a question without making a statement.
• When a discussion is going on, you may want to take notes, support with visualization or just silently reflect. Do not interfere in a well-going discussion unless the time box is up.

Ask questions

Questions are your most powerful tool for facilitation.
As facilitator, your responsibility is not to tell others anything about the domain of the discussion - your responsibility is to get them to speak. The best way to do this is by asking the right questions.

Games / Exercises

You may want to add some games or other exercises for lightening up the mood or directing the discussion. This may be good to break the ice or to prevent boredom, but be wary that people do not focus on the exercise. This can become a distraction from the original purpose! Do not load a firework of effects without a clearly planned purpose.

Visualize

A good way to facilitate during moderation is by visualizing. This does not typically mean drawing fancy charts, but it means putting the spoken words into something visible for the eye. This is valuable because misunderstandings or uncertainties become really obvious very fast. For example, drawing an arrow to the wrong bubble will immediately be corrected - without you having to say a single word!

Summary

Don't try to change everything at once. Whether you are new to facilitation or "still learning", pick one item that you wish to improve upon and change it for the next meeting. Learn from the feedback, inspect and adapt.
Over the years, your facilitation will continually become more effective through incremental change.

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.

What type of Product Owner are you?

The Scrum Primer has a very clear definition for a Product Owner. "[The PO] is responsible for maximizing return on investment (ROI) by identifying product
features, translating these into a prioritized list, deciding which should be at the top of the list for the next Sprint, and continually re-prioritizing and refining the list ..."

In corporate practice, however, PO is not PO.  Here are two considerations. These are not intended to value persons or their skill, but simply the PO's place in the organization.

Strong vs. Weak Product Owner

You can determine your PO strength with a single question: If they have a great new idea for their product, what do they do? There are many possible answers, but let's take this power scale for orientation:
The strongest Product Owners simply proceed when they are convinced.
Moderately strong PO's rally stakeholder support before proceeding.
Weak Product Owners ask others for permission.
Really weak Product Owners will not even proceed with their own ideas.

Real vs. Fake Product Owner

What does "real" vs. "fake" even mean?
Real Product Owners build their product to make it successful.
They hold the cash pile and can freely decide whether to spend money to build that new fancy feature or to throw a pool party for the team, should they consider the latter to be more valuable.  They thrive on unspoken customer need, because usually, the customer does not even know what they need.

Fake Product Owners, on the other hand, assist someone else in building their product. They receive requirements on a silver platter, grooming, refining and prioritizing them - and do whatever is necessary that everyone is happy with the result. They usually get assigned teams and/or budgets, and their responsibility is delivering a positive business case lest management decides to discontinue the product.

The Matrix

PO != PO

Strong & real Product Owners are the ideal of Scrum and agile Software development. With the right product vision and the right team, they will be wildly successful.


Weak & real Product Owners will continually run a tremendous risk of building the wrong product. In a highly political environment, they are most likely doomed to fail.

Strong & Fake Product Owners are quite comparable to Product Managers - the product is theirs to create, given outside input. To succeed, they must either depend on a Real Product Owner or hope that their direction pleases the customer.

Weak & Fake Product Owners are not even all that rare - we typically call them "Business Analysts". They are not involved in the financial success of the product. Their role is limited to preventing predictable failure.

Conclusion

It is neither good or bad to be anywhere on the matrix. It only becomes "bad" when you are that Product Owner and you feel that you should not be in this specific quadrant - then you must ask "How can we change that?"
If you have just concluded that your product is lacking a strong & real Product Owner, now would be a good time to look for one ...

You, too, can increase agility!

Individuals stuck in a classic waterfall organizations often ask "How can I be agile here?" - and quickly conclude, "I can't". This, however, is untrue. You can be agile. You will never be as agile as someone working in an agile organisation, but you still can be agile.

There are different levels at which agility can be realized in an organisation:

Agility affects all of these levels.

You can always influence some of these things, but you can not change all of them. If you are working at organizational level, agile practices are beyond your scope. Likewise, if you work as an individual developer, the structure of the organisation is beyond your scope.

Here are just a few pointers on how you can increase agility on your level:

Practice Level

Every developer is in charge of their own work. Agile engineering practices, such as for example Clean Code, Refactoring, Test Driven Development and Emergent Design are completely up to you.
While developers can not expect a traditional Project Manager to give them freedom for completely refactoring your 12m LOC legacy code or add unit tests to everything, there is nothing stopping you from writing better code today.
As a developer, you can increase practice level agility and convince others by results. Even if others are not convinced, you will be more agile than if you do not heed these practices.

Your primary constraint will be the scope of your work. You must accept that you alone can not save the Whales and that unless your organization supports wider practices like Scrum or Continuous Integration, you can only improve your own work.

Team level

Depending on how agile your organization already is, you may have "agile teams" already - or you may be led by a team lead. Assuming you are in either of these positions, the entire structure and practice of the team is up to you.
Even if your Product/Project/Line manager dictates the work items and their deadlines, you still can practice additional agility with your team.
Continuous Integration, Pair Programming, Standups, Retrospectives and Reviews are just examples of good agile practices that will all increase the quality of your work and the credibility of your team.
As a team, you can do all of this - as a Team Lead, you can direct your team in this direction to increase team level agility.

Your primary constraint will be the Product/Project context. You must accept that agile teams will not make unrealistic expectations more realistic and and that wrong plans do not automatically correct themselves.

Product Level

Gaining the freedom to develop an entire agile product is a large step in many organisations. To be agile at product level requires a lot of discipline and dedication.
Product level agile practices include working with a backlog, prioritizing and delivering by value, building increments, permitting room for learning and feedback in the product delivery cycle etc. Additionally, you must build your teams and processes around your product rather than vice versa.
As a Product Manager / Product Owner, you can institute all of this with the backing of your developers.

Your primary constraint will be that you need practice and team level agility, to succeed with product level agility. You must also accept that if the outside organization is still arranged in silos, you will still not build the optimal product and be fighting many political battles.

Organisation Level

Working with an entire organisation to increase agility is the best way to remove global impediments. However, you can not simply declare, "From tomorrow, we will be agile". Command and Control mindset will most likely still be ingrained within your organisation and silo structures will be rooted much deeper than org charts.

Organisation level agility can be supported by top management and can be stepwise instituted by middle management, but this level is very slow and requires much patience. 

As upper/middle manager, you can encourage higher agility and remove impediments during the Agile transformation. You can provide training, get coaching for yourselves and agile practitioners - but then that's about it. As an agile manager, your responsibility is not telling others what to do - but to provide freedom to make decisions and learn from mistakes. However, early on in the transformation, your responsibility is also enablement to make informed decisions and deal with ignorance.

Your primary constraint working on an organisation level is the current state of the organisation and the mindset of the workforce. You must accept that by doing things and making decisions for the teams, you are quite likely being counter-productive - so your biggest impediment is actually the entire non-agile organisation and everyone who is stuck in a traditional mindset. 

Summary

Regardless of where you are, you can do something to be more agile. Taking small steps is actually easier and faster at practice level - but the "big wins" are made slowly on organisation level. For maximum effectivity, all four must go hand in hand.

The "engine" of agile transformation

Everyone can do something to be a little bit more agile tomorrow. You can take small, thoughful steps: Grind the gears, but consider the whole picture. Moving too fast in one place might break the entire approach. Have patience.

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.

Why a good meeting room matters

Scrum has a set of ceremonies that are conducted in a meeting atmosphere.
They are Planning, Refinement, Review and Retrospective. All of them are essential to a well functioning Scrum team.
Let us de-scope the Daily Standup here, because it should be conducted in the team room anyways.

But you can't just have the meeting anywhere.
Here are a few factors of inadequate rooms:

• A noisy room causes distraction and breaks the focus. Keep the interfering outside noise level at a minimum.
• A dimly-lit room might make people sleepy and add difficulty towards both noting down information and reading notes. You need sufficient lighting. At the same time, avoid scorching lights.
• A crammed room discourages moving around, which both decreases the energy level and the potential for interactive problem solving methods. Everyone needs the freedom to move around unhindered.
• If the team is exposed to external scrutiny, this may reduce trust and willingness to discuss critical problems.
  Especially for the Retro, you will require a secluded environment where the team has privacy to discuss even highly political or personal issues.

It is completely valid to ask "Is our meeting room adequate?" - and treat "No" as an impediment to resolve.

Try to get the best possible space for the meetings to make them sufficiently productive.
If your team does not have access to adequate meeting space in the office, consider renting external facilities. It is better to pay a bit of money for space than to reduce team effectiveness.