scrum Archives

Tag Archive for: scrum

Webinar | Sprint Planning

February 28, 2022/by Lauren Edwards

Sprint Planning sets the tone for the entire Sprint. It is absolutely crucial to ensure that this is done properly, because any issues you run into at this stage will have a knock-on effect throughout the entire Sprint. Birge Kahraman and Paul Bultmann have helped many organizations and teams establish Scrum Events and run them with great success. During the webinar, they outline what an effective Sprint Planning Event should entail, and guide you through the practical steps involved in facilitating one. They also share what works well in Sprint Planning, as well as a few traps to avoid, before opening the floor to some listener questions.

Watch now | Sprint Planning Webinar

Stay in the loop about upcoming webinars by joining our mailing list

Meet your webinar hosts

Birge Elif Kahraman started her career in 2009 and worked as a project manager, Scrum Master, and Agile Coach. Before joining agile42, she coached various teams and companies in Telecommunication, Finance, Ecommerce, and Service domains. Birge supports teams in analyzing their impediments and reflecting on the next steps, creating a trustful environment where they can communicate and collaborate. She has a data-driven and pragmatic approach, which helps her tailor her coaching unique to the company culture and the reality of the teams.

As an Agile coach, Paul Bultmann wants to make the world a better place to work. He believes collaboration should be easy, fun and structured to be successful. For the past 10 years he has worked as Leader, Agile Coach, Scrum Master, Trainer and Project Manger. His passions and skills include Organisational Change, Agile Transformation and Team building.

Browse the agile42Agile Certifications

agile42 offers Scrum courses, as well as:

online Agile certifications;
Kanban training with certification from Kanban University;
ICAgile Agile Team Facilitation (ICP-ATF) and Agile Coaching Certification (ICP-ACC) training; and
Scrum Alliance Certified Agile Leadership training.

How to Revive Your Daily Standup

February 4, 2022/by agile42

The daily standup is a fundamental part of Scrum rituals, but it’s also one of the most misunderstood. At agile42, we’ve been coaching organizations to facilitate these Scrum events for 15 years. We’ve guided hundreds of teams towards making these 15-minute sessions stand out as a useful, valuable, and enjoyable event. Here’s our guide to what a daily standup actually is, along with some of our tried-and-tested methods to bring life back into the daily standup.

Recommended online course: Facilitating Scrum

What is a daily standup?

The daily standup is a 15-minute meeting that takes place every day. Although the meeting is not exclusive to Agile methods, it’s an integral part of many Agile frameworks and methods including Scrum, Kanban and XP.

Daily standup vs Daily Scrum

While the terms “daily standup” and “Daily Scrum” are used interchangeably, there is technically a difference. The Daily Scrum is how it is referred to in the Official Scrum Guide and makes up one of the five Scrum events. The daily standup is a more general term for a quick 15-minute catchup, used in Kanban and other settings outside of a Sprint.

Why is a daily standup meeting important?

It is important to understand the purpose of the daily standup, so that you can make sure this Scrum event is a good use of everyone’s time. The two key purposes of a Daily Standup are:

to agree as a team on how to deliver the most value in the next working day; and
to inspect and adapt the sprint plan if necessary, in order to deliver the most value in the sprint.

If you’re having trouble keeping your daily standups, it also helps to remember the Lean and Agile principles that guide these events:

Focus on outcomes over output (or results over activity)
Focus on priorities
Emphasize team ownership of results over individual assignments

Photo by Parabol

How to run a daily standup

The standard format for a daily standup consists of each team member answering three questions:

What did you achieve yesterday?
What will you achieve today?
What impediments are in your way?

This format is used widely with varying degrees of success. While it is the original, traditional format, you don’t have to use it if it doesn’t work for your team. Each team has its own needs and preferences, and as long as you’re focusing on what’s important – like communicating, prioritizing, and managing the flow (not the people) – you can change the format to better suit your needs. The traditional three-question format can also really easily devolve into a mere status update meeting, failing to achieve the purpose of the daily standup and failing to embody its principles. If that’s happened to your dailies, you may need to find a way to revive your standup.

How to revive your daily standup

If your daily standups have turned into status updates, your team is disengaged, and you’ve lost touch with the principles of Scrum that guide the concept of these meetings, you’re not alone. Many organizations have difficulty running effective standups, and their teams feel like they’re not an effective use of their valuable time. If the team is not finding the meeting useful, you need to find the root cause and fix it. Here are 10 ways you can bring life back into your daily standups, and reap the benefit of this crucial Scum event.

Think of it like a sports huddle

Jeff Sutherland, one of the creators of Scrum, says “The idea is for the team to quickly confer on how to move toward victory—i.e., complete the Sprint.” It may help to think of it like a huddle before a sports game: the team comes together to re-energise, encourage, and strategies for the day. It’s not a chance to chat about training schedules, travel expenses, discuss goals for the year, introduce new players, or any of the other concerns a team might have. It’s a quick, razor-focused strategy session for the match they are currently playing.

Photo by LOGAN WEAVER on Unsplash

Ask the right questions

If your daily standups are not working well for your team, and don’t feel like a good use of their time, it’s important to discover the root cause of this. Get someone from the team to observe the meeting and think about the following questions, to guide them to the cause of the concern:

Situation: Does the team report to itself or the ScrumMaster? Is the situation presented honestly? Do they have facts and information in front of their noses? Is the granularity right?
Focus: Is the goal clear? Is the team focusing on getting the next backlog item done, rather than ensuring everyone has work for the day? Is there a lot of bureaucratic overhead?
Speaking: Does everyone get the opportunity to speak? Who speaks most, who is most silent? Do people listen intently or are they just waiting for their own turn? Are people supporting each other?
Decision-making: Who makes decisions? Is it one person or the whole team? Do they evaluate multiple options? Are decisions based on facts? If they make guesses, do they go on to validate the decisions before investing time?
Language: Does the team have their own “slang”? Does the body language support the verbal message? If you’re running virtual standups, are cameras on or off?
Trust: Are they showing respect for each other and for other teams? Are they having fun together? Can they bring up difficult topics? Are they showing courage?

Focus on the work, not the individuals

The focus of a daily standup should be on stories and priorities, not on any individual’s to-do list or performance. Since you’re talking about the work and flow itself, and not about individuals, it is possible that one team member may speak a few times while others may speak less (or not at all) some days. This is okay: it is not a status report or a chance to check up on productivity; it is a chance for the team to make sure they have everything they need to achieve the outcomes they have in mind for that day.

Brush up on your Scrum foundational knowledge

You simply can’t facilitate a standup well if you aren’t well-versed in the principles of Scrum. Consider taking an online Scrum course, to make sure you are being guided by the right principles and practices.

Keep it to 15 minutes

The 15-minute time limit of a daily standup is there for a reason. Set a timer, and make sure you stick to it. This keeps the meetings productive, focused, and to-the-point. If other distracting conversations come up during this meeting, you can make a note of them, but do not discuss them now. Which brings us to our next point…

Use a parking lot to stay focused

Use a “parking lot” for discussions that are too long or do not concern the whole team. You can have a literal whiteboard in the office, or a virtual space like Miro or Trello. When the standup veers off course, and other topics emerge, simply note them down for later and move on. Remember that anyone has the right to call “timeout” on distracting conversations; this is not the job of a leader or Scrum Master.

Make sure these conversations and concerns don’t get forgotten forever. You can stick around after the standup to continue talking about them, or perhaps set aside a few minutes in your Retrospective at the end of the Sprint or project to do so. You can use a voting system to determine which parking lot conversations to prioritize and analyze. Keep the stand-up focused, finish it on time, and then anyone who needs to continue the parked discussions can do so after the meeting is over.

Agree on the Scrum Master’s role

It is not essential that the Scrum Master attends this meeting, but it is also allowed, if that works for the team. However, it is crucial that the daily scrum is for team members to connect, prioritize, and plan for the day. The team should be speaking and making eye contact with each other, rather than the Scrum Master (or any single individual). This is a good way to tell if there’s a problem in the way the standups are running.

Agree on the Scrum Master’s role, and what works for your team. Should they attend? If so, should their key focus be to ensure that everyone remains focused and no external people are disrupting the purpose of the meeting? Or perhaps they should simply observe, or be available in case they are needed to help with any particular impediments.

Change up the format

The traditional three-question format might work nicely for you, and that’s fine. But there are a number of other tried-and-tested formats that we’ve used at agile42 that can boost the effectiveness of the standup, depending on the team. Here are a few examples, suggested by some prominent thought leaders in the Agile community.

Walk The Board

Jason Yip, Senior Agile Coach for Spotify, uses the “Walk The Board” format for standups. It is a great way to keep the focus on the board. Here’s how the format works:

Gather around your team’s board.
Start with the highest priority story/feature in progress.
Ask what we, as a team, can do to get that story done (per our Definition of Done).
Ask what is blocking us, as a team, from getting the story done.
Repeat steps 3-4 for the next few priority items, up to your team’s WIP limit.
To finish, validate that everyone on the team has been heard and all are focused on the top priority stories.

Photo by Parabol on Unsplash

The Sprint Goal

Olaf Lewitz, veteran and leader in the Agile community, suggests using a slightly different set of three questions: one that shifts the focus to the team and the sprint goal, rather than each individual’s list. He suggests asking:

What did we (as a team) achieve to get closer to the sprint goal?
What’s blocking us from focusing on the sprint goal?
What do we agree on doing today to make sure we reach the sprint goal?

The Two Plus One Questions

Founder of agile42, Andrea Tomasini, starts his standups by asking each person the first two questions:

What have I achieved since last time?
What impediments are still in my way?

Based on these answers the team as a whole can devise the best plan for the day. Finally, each individual can clarify her/his commitment to the team’s plan for the day by answering the third question: What do I commit to achieving today?

The Story of the Day

Dave Sharrock proposes a single question, to ensure the team remains razor-focused on the sprint itself. The question is, simply, “Which story will we finish today?”

Use a ball to add dynamism

If you’re finding your main concern with standups to be that there is low energy and engagement, and you’re sure that you’re using the right format and sticking to the time limit, you can try adding a ball to the mix. Use a stress ball, tennis ball, or really anything you can throw around your workspace (without breaking things).

Once each person finishes speaking, they can throw the ball to the next person to indicate that it is their turn. This can make things a little more lively and fun, and it has the added benefit of keeping people listening and paying attention, since the structure is a little more unpredictable than going in a circle. If your team works remotely, you can use a version of this technique relatively easily. Simply say who you are passing the ball to, and that person can use your video conferencing tool’s “Raise Hand” feature to indicate that you’ve “caught the ball”. As an added bonus, nobody needs to know how good (or bad) your real-life catching and throwing skills are.

Check the granularity of your tasks

If you’re finding that your daily standup often runs over the time limit, and they’re defined by impediments, high levels of stress, or not meeting daily goals, there might be a problem with the granularity of your tasks in the first place. The tasks set each day should be achievable in a single day, to match the frequency of the meeting and foster collaboration rather than any kind of competition.

agile42 offers remote Scrum training

We offer Certified Scrum Master (CSM), Advanced Certified Scrum Master (A-CSM), Certified Scrum Professional-ScrumMaster (CSP-SM), Certified Scrum Product Owner (CSPO), Advanced Certified Scrum Product Owner (A-CSPO), and Certified Scrum Developer (CSD) training, in live remote sessions with our experienced certified coaches. If you need help, coaching, mentoring, or training, don’t hesitate to reach out!

A Practical Guide to the five Scrum Events

January 6, 2022/by Giuseppe De Simone

Scrum is simple. Indeed, it is a very lightweight framework everyone can understand. However Scrum is purposefully incomplete: It just defines the rules of the game, like the rules of a sport. You need to know the rules well to play a certain sport, but knowing them is not enough to win a championship. That’s one reason why Scrum is hard to master: you need to know so many things outside Scrum to make it work successfully. Since Scrum is based on empiricism, a key success factor is how well a team runs their Scrum Events, which represent an opportunity to inspect and adapt either the product or the process.

In this article, we will give you some practical suggestions on how you can make them work effectively, which you will not find in the Scrum Guide. And even if you are not using Scrum, you will be able to apply what you learn here to other contexts.

Recommended e-learning: Learn to run better Scrum Events with our Facilitating Scrum online course

What are the Scrum Events?

There are five Scrum Events, namely the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. In this article we will take a deep dive into each of the Scrum Events that happen within a Sprint. In Scrum, the Sprint is a fixed length event of maximum one month, which contains all other events.

Scrum Events or Scrum Ceremonies?

The Scrum Events are often also called “scrum ceremonies”. This was a term used in the 90s and probably borrowed from some other agile framework, but it never appeared in the Scrum Guide, where the official term has always been “scrum events”, since its first version published in 2010.

Sprint Planning

The Sprint Planning event takes place on the first day of the Sprint. Its purpose is to plan the work to be done during the Sprint and the whole Scrum Team is involved in this event. Sprint Planning should have roughly three parts. Topic One should focus on the “Why?”. The outcome should be a defined Sprint Goal. Topic Two covers the “What?”. During this topic, the developers should work to decide which Product Backlog Items are going to be worked on during the Sprint, and if necessary, refine the Sprint Goal to reflect this. Finally, Topic Three deals with the “How?”. During this final stage of the meeting, the developers create an actionable plan to get the work done.

When: The first day of the Sprint.
Duration: The Sprint Planning should be a maximum of eight hours for a one-month Sprint. For shorter Sprints it is usually shorter, roughly four hours for a two-week Sprint. A good Scrum Team is usually able to plan a two-week Sprint in less than three hours.
Participants: The whole Scrum Team participates in this event: Product Owner (PO), Developers, and Scrum Master (SM). The event is usually facilitated by the Scrum Master. Other people may be invited by the Scrum Team, including anyone who can contribute to plan the Sprint, for example stakeholders, users or specialists from other teams.
Input: A well refined Product Backlog (PB) with an adequate number of ready Product Backlog Items (PBIs)
Output: The Sprint Backlog, consisting of the Sprint Goal (Why), the list of items pulled from the Product Backlog (What) and a plan for how to achieve the Sprint Goal and deliver the Increment (How)

How to run a Sprint Planning event

Introduction
The Scrum Master, who acts as facilitator, introduces the event by welcoming the participants, explaining the purpose of the meeting to the people invited by the Scrum Team and showing the agenda for the meeting. (5-10 min)
Topic One: Why?
The Product Owner takes the lead, provides an overview of the Product, and reminds everyone about the long-term aim for the Product as well as the current Product Goal. They come prepared and propose a draft Sprint Goal. For example, assuming that we are in a payment domain, a Sprint Goal could be: By the end of the Sprint, we will support card payments for all EU customers. (10-15 min)
Topic Two: What?
The Product Owner and the Developers quickly go through the Product Backlog. The Developers should have contributed to refining the Product Backlog, spending “just enough” time to do some final clarification and possible changes after the last Product Backlog Refinement session. (30 min)The Developers make a forecast of how much capacity they think they can spend on building the Increment during the Sprint and then select a list of PBIs they believe they can complete by the end of the Sprint. If those PBIs seem to be sufficient to achieve the Sprint Goal proposed by the PO, this part of Sprint Planning is complete. Otherwise the PO and Developers collaborate to craft a new Sprint Goal which better aligns with what the Developers can deliver. In the example above they might come up with something like: By the end of the Sprint, we will support only debit card payments for all EU customers. (15-30 min)
Topic Two: How?
The Developers collectively create an actionable plan to deliver the Increment. They self-organize on how to best achieve that. It is not necessary to create a detailed plan for the Sprint. Instead, the Scrum Team should anticipate emergent opportunities and be prepared to adapt their plan as they learn. It is probably enough to have an idea of what each Developer will do in the coming 2 to 3 days. In this phase of the Sprint Planning the PO is not really necessary. However it is good if they are available to answer questions or clarify customer needs. (30-45 min)
Closing
The Scrum Master thanks the participants for their contribution and officially closes the event. (5 min)

Tips for Sprint Planning

The Sprint Planning is not supposed to be a “surprise party” for the Developers. It is not meant to be the first time they look at the PBIs which are candidates to be pulled into the Sprint. Developers usually spend 10% of the Sprint capacity to work on refining the PB and look ahead at what might come in the next Sprints. Otherwise the risk that the Sprint Planning becomes an endless death march is very high.

Daily Scrum

The Daily Scrum is the moment where the Developers step back for 15 minutes, analyze where they are in respect to the Sprint Goal, and collectively decide what is the most important thing each Developer has to do in the next 24 hours to get closer to the Sprint Goal. It is a planning meeting, not a generic synchronization meeting. If your Developers are waiting for the Daily Scrum to speak to each other, you have a problem.

It is important to focus the conversation on the most important Sprint Backlog Items, not on individuals stating what they have done. The Daily Scrum is not a status report meeting. The SM should help create the right environment to encourage open communication, identify obstacles, and promote quick decision-making.

When: Every working day at the same time
Duration: A maximum of 15 minutes
Participants: The Daily Scrum is the only event that is self-managed by the Developers. The role of the SM is to teach and coach the Developers to run it autonomously.
Output: An adapted Sprint Backlog, if necessary
Structure: The Developers decide how they want to run it

Tips for the Daily Scrum

It is usually not necessary that the PO attends the Daily Scrum, but it is also not forbidden. Even if the PO is not directly involved in planning how to build the Increment, the Daily Scrum can be a good moment to check how things are going and offer help to the Developers.

Sprint Review

The Sprint Review is an opportunity for the whole Scrum Team to stand in front of their users, stakeholders and customers and inspect and adapt the Product. It takes place at the end of the Sprint. The meeting should include an overview of the state of the product in terms of progress, budget and next steps. Usually, there is also a hands-on demonstration of the actual product. The users and stakeholders provide feedback, and then the developers incorporate relevant feedback into the Product Backlog.

When: Last day of the Sprint
Duration: A maximum of four hours for a one-month Sprint. For shorter Sprints it is usually shorter: roughly two hours for a two-week Sprint.
Participants: The whole Scrum Team: (Product Owner, Developers, Scrum Master) as well as the customers, stakeholders and users. The event is usually facilitated by the Scrum Master.
Output: A revised Product Backlog and changes to the product or release strategy, if necessary
Structure: An inspection phase followed by an adaptation phase (working session)

How to run a Sprint Review

Introduction
The SM, who acts as facilitator, introduces the event by welcoming the participants. They explain the purpose of the meeting to the participants which can include users, stakeholders and customers. Then they show the agenda for the meeting. (5-10 min)
Inspection phase
The PO takes the lead and provides an overview of the state of the product in terms of progress, budget and next steps. They remind everyone of the Product Goal and describe the Sprint Goal the Developers were trying to achieve. (10 min)
The PO leaves the stage to the Developers to demonstrate the Increment. This is not a PowerPoint presentation of what the team has done, but a hands-on demonstration of the actual product. Usually Developers will go through the scenarios described in the acceptance criteria of each PBI. Some teams even let users or customers try the product themselves, while the Developers and the Product Owner observe how they interact with the Increment. (30 min)
The Scrum Team collects feedback on the Increment from all invited participants. (15-30 min)
Adaptation phase
Users, stakeholders and customers might leave the meeting at this point, while the Scrum Team continues with a working session to incorporate relevant feedback into the Product Backlog. Should the feedback be related to something which does not impact the upcoming Sprint, they can simply take notes to address the feedback in one of the upcoming Product Backlog Refinement sessions. However, if the feedback potentially affects the next Sprint Goal, the Scrum Team will perform a quick Product Backlog Refinement session during the Sprint Review to get ready for the upcoming Sprint Planning. (30 min)
Closing
The Scrum Master thanks the participants for their contribution and officially closes the event. (5 min)

Tips for the Sprint Review

The Sprint Review should not be a “surprise party” for the PO, who is supposed to collaborate with the Developers throughout the Sprint. The whole Scrum Team is accountable for delivering a valuable and usable Increment at the end of each Sprint.

Sprint Retrospective

The final Scrum Event is the Sprint Retrospective. The Sprint Retrospective is the only event in Scrum that is exclusive to the Scrum Team. The intention is to create a safe space where everyone in the Scrum Team feels comfortable to openly share their observations and express their views and ideas. The purpose of the event is to inspect how the last Sprint went and plan ways to increase quality and effectiveness.

Related reading: 11 ways to improve your Retrospectives

When: Last day of the Sprint, right after the Sprint Review
Duration: A maximum of three hours for a one-month Sprint. For shorter Sprints it is usually shorter.
Participants: Only the Scrum Team: Product Owner (PO), Developers, Scrum Master (SM). The Scrum Master usually facilitates the event
Output: An improvement plan
Structure: A good structure is suggested in the book “Agile Retrospective – Making Good Teams Great” from Esther Derby and Diana Larsen, which comprises the following 5 steps:

Set the stage
Gather data
Generate insights
Decide what to do
Close the retrospective

How to run a Sprint Retrospective

Set the stage
The SM, who acts as facilitator, introduces the event by welcoming the participants and showing the agenda for the meeting. They work to create the right environment for focused and open communication. Maybe it was a tough Sprint, with conflicts and failures, and it is essential for the team to step back from the stress and consider different perspectives to find opportunities for improvement. (5 min)
Here is a simple yet effective activity you can do. Ask every individual to write on one sticky note the worst thing going on in their head at the moment and on another sticky note what would make them happy after the event. Then ask them to throw away the first sticky note and keep the second one.
Gather data
Now it is time to gather both objective (e.g. number of found bugs) and subjective data (e.g. how the different people felt throughout the Sprint) from the Sprint. (10-15 min)
Sometimes it is hard for people to recollect data after a few weeks. Consider asking everyone to report events when they happen (for example by adding sticky notes on a Miro board) with a short description and a time stamp. During the retrospective you can look at the sticky notes and order them on a timeline. Then each individual visualises their mood related to those events. Then you have both objective and subjective data in a single visual artifact.
Generate insights
Now it is time to look at data and try to find patterns. These will allow the team to identify one or two improvement areas. (15-30 min)
Decide what to do
Once the most important improvement area is identified, the team collaborates to define a few actionable items to incorporate in the next Sprint. Consider those items experiments. Once the team validates they actually lead to a positive impact, they can incorporate them into the team’s routines and practices. Using the SMART technique enables the definition of action items which are Specific, Measurable, Attainable, Relevant and Time-bound. (30-45 min)
Close the retrospective
The Scrum Master thanks the participants for their contribution, closes the event and encourages everyone to celebrate the Sprint. In an in-person setup, this might be a good moment for the PO to share a cake to thank everyone for their effort. (5 min)

Tips for the Sprint Retrospective

The most impactful improvements are addressed as soon as possible. They may be added to the Sprint Backlog for the next Sprint and usually 10% of the Sprint capacity is allocated to address those improvements.

Whether the PO should participate in the Sprint Retrospective or not has been debated for a long time. In the last few years, it has been agreed that the PO must participate in the Sprint Retrospective because they are not the boss of the Scrum Team but part of it and on the same level as SM and Developers. Retros typically include conversations around how to refine the Product Backlog or how to collaborate with the customer, which are part of the PO’s accountability.

The Scrum Master usually facilitates the Sprint Retrospective, but can also decide to participate in discussions. An example might include sharing observations about how the Scrum Team is running the Scrum Events. In that case it’s a good idea to ask another person to facilitate. This could be one of the Developers or a Scrum Master from another team.

11 Ways to Improve Your Retrospectives

October 20, 2021/by agile42

Possibly the most important part of your Agile journey is your ability to inspect and adapt. This helps you to constantly iterate and improve your output, methods, processes, and product. A retrospective provides the opportunity to look back on the sprint you’ve just completed and make plans to improve in the future. Here are 11 ways to ensure your retrospectives are successful.

Want to run better retros? Learn how in our online short course, Facilitating Retrospectives

What is a retrospective?

A retrospective is a meeting held for the purpose of reflecting on the product development or workflow process. The aim of a retrospective is to look closely at the processes and products produced during a sprint, discuss these as a team, and decide on a way forward together to drive constant improvement.

A retrospective is also known as a Scrum retrospective, retrospective meeting, a sprint retrospective, or simply a retro.

Why are retrospectives important?

When done correctly, retrospectives can be a catalyst for organisational change as well as team change. They can be a place to build and enable teams, or to help teams start their journey from the best possible place. Team retros can be a place for learning, problem solving, or having fun and motivating each other. This is why it is so crucial to get them right.

Common mistakes in retrospectives

Many retrospectives follow the same formula: the team is all gathered in a room around a small table. The Scrum Master throws some pens and some sticky notes on the table, and the team writes down what went well and what can be improved. They make lists and group the topics together. Often, half the people in the retro aren’t really engaged, and some are on their phones. Most of them would rather be coding.

While this makes sense on the surface level, when you look a little closer you often find the same strengths and weaknesses emerging every time. Actions aren’t always followed through effectively, resulting in a sort of Groundhog Day experience that can be very frustrating for all involved.

If people stop engaging in the meeting and feel that their time is being wasted, then it probably is. If meetings aren’t adding value and actively driving change within the team and the organisation, they aren’t achieving what they set out to achieve, and they need to be stopped or changed.

How to make your retros successful

There are some simple changes you can introduce to vastly improve your retrospectives. Here are our 11 top tips to make your retros successful.

Embrace the five stages of a successful retrospective

Diana Larsen and Esther Derby’s book Agile Retrospectives – Making Good Teams Great lays out five stages of a successful retro.

Set the Stage: Understand where everyone is coming from today.
Gather Data: Get the viewpoints of all members of the team so that you can create a shared picture of what is happening.
Generate Insights: Unpack the data and analyse or look for the root causes.
Decide what to do: Make sure the team decides what’s most important together.
Close: Appreciate people’s time and get feedback on how to improve your retros in future.

Your retrospectives won’t always need to include all five stages, but this is an excellent base-line and makes for a good starting point.

Recommended for you: Take an online course on Facilitating Retrospectives

Tailor your retro to your team’s needs

A generic retro structure can be a good start, but if you want to make meaningful improvements you need to make sure you understand the specific needs of your team. The facilitator, coach, or Scrum Master should observe and pay attention during the sprint, project, or whatever cadence the team has. They should be looking closely at how the team works together and any difficulties they’re having. If you’re the Scrum Master, ask yourself:

What does the team need?
Is there a specific issue that they are grappling with?
Are they making their sprint goals?
How is the level of trust? Have they lost trust in each other or is there a lack of trust between the team and the product owner?
Are they a new team still finding their rhythm?
How are the energy levels?

Photo by Jason Goodman on Unsplash

With these answers in hand, you can start to put together a picture of what the team needs: maybe there are big trust gaps in the team that need to be addressed, or maybe they’re lacking resources. Maybe they have just had a hectic series of sprints, and they need to celebrate their wins and not change anything. The only way to find out is to be in tune with your team and the work they’re doing.

Recommended training to boost your skills: Advanced Scrum Master certification

Plan well

Once you have decided on what your team needs to focus on, you need a plan for your retrospective. Spend some time deciding how you are going to divide up the time spent in the retro: are you going to split it into the five phases? Do you need all five phases, or can you skip some? And finally, what are you going to do for each phase?

Break people into smaller groups

Groups of two or three are optimal in a retrospective.It makes it much easier to keep the energy high and keep people engaged. It is also much easier to get things done.

Encourage team members to contribute in their own way

Make sure you are encouraging everyone in the team to contribute in their own way. Many people are tempted to force people out of their comfort zones, such as making introverted employees take the lead on talking. While there is some merit to encouraging people to step out of their comfort zones, remember to play to everyone’s strengths. Someone who doesn’t like talking may prefer to do the writing, do some silent brainstorming in a small group, or get up and take notes on the board. These are valid ways of being engaged, and they bring the best out of people rather than putting them on the spot and causing anxiety.

Photo by Hannah Busing on Unsplash

Have an outcome in mind

A common mistake in team retros is to approach it without a specific outcome in mind, to see what comes up. This lack of structure can be useful on occasion, to allow the team more freedom to explore their experiences. However, most of the time it can make things feel directionless and can get in the way of moving forward. Make sure that there is an outcome for the retrospective and provide support to the team in reaching that outcome. Be careful not to make the change for the team: you want to encourage self-organisation.

Dig deep and find the root cause of problems

If you are only looking at the symptoms of a problem and not understanding the root cause, then you are missing a valuable opportunity for learning and improvement. You will also keep having to deal with the same or similar issues over and over again. This may also result in long lists of policies or agreements set up to change behaviour, but without meaningful change, because the root cause hasn’t been addressed. Analyse and dig beneath the surface, or you may just be wasting your time.

Make use of retrospective games and exercises

There are plenty of places to find great ideas for exercises to do during retrospectives. Diana Larsen and Esther Derby’s book Agile Retrospectives – Making Good Teams Great has a wealth of things to do and is an excellent starting point. There is also a website called Retr-O-Mat that has many ideas for games or exercises. While a game or exercise can be a great way to get creative juices flowing, break the ice, and relax the mood, be careful not to overload your teams with games. The most important thing is to pay attention to what your team needs, make sure your retro flows, and have an outcome in mind.

Photo by Brooke Cagle on Unsplash

Use SMART goals

Remember to not try to do everything at once. One or two key changes are usually more than enough. If a team tries to do everything, they often end up doing nothing. A good idea is to come up with an Action Plan and include a SMART goal. Smart goals are Specific, Measurable, Attainable, Realistic, and Timely.

Get professionals involved

One of the best ways to transform your retrospectives into useful, successful events that the whole team finds valuable is to consult with professionals like the coaches, mentors and facilitators at agile42. Contact us to enquire about our services. We offer them remotely or in-person, and we can set you up for success so you can go forward confidently.

Ask for regular feedback

The easy answer to this is to ask for feedback from the team. At the end of each retrospective, devise a way to get feedback on the retrospective itself and ideas for improvement. There’ll always be someone who will just request pizza, but you will be surprised at the great ideas that are offered if you open the door for honest feedback. As you are asking for continuous improvement from your teams, make sure that you are also looking to continuously improve yourself and your retrospectives.

Finally, remember, if you are having fun, chances are others are too. Sometimes we need to be serious and sometimes we just need to have fun.

Webinar: What makes a great Product Owner?

May 28, 2021/by Amy Bridge

The theme for the month of May was Product Ownership. We had two of our agile42 coaches covering this topic, Daniel Lynn and Lothar Fischamnn. Daniel kicked off Part 1 with a video interview where he looked at what makes a great Product Owner, including how to handle a team looking for a list of tasks to complete as well as navigating those needy stakeholders.

In Part 2, Lothar looked at why having a Product Vision is so important for a Product Owner and what we can learn from “Shark Tank”.

This culminated in a webinar on the 26th May, where Daniel and Lothar shared their thoughts and experience in a Q&A style session. The audience certainly gave them some challenging questions!

Some of these included:

Do you coach/teach Product Owners to ruthlessly prioritize to drive better product/service focus?
There was a debate whether the Product Owner role is still required in Scrum. Any thoughts?
What would you say are the most important "watch-outs "or pit-falls as a Product Owner?
Can you be a PO across 2 teams working on multiple products or is that another role completely?

As always the hour flew by with many more discussions still to be had. This is why we have decided to launch a Lean Coffee event after each webinar where you can continue the conversation with two of our agile42 coaches. This provides an opportunity to address those remaining burning questions as well as meet like-minded people. Join our free agile42 Community to gain access to our monthly Lean Coffees as well as an array of other benefits. We hope to see you there!

If you missed out on the live session, don’t panic! We have the recording for you here - please feel free to share around with your network.

Part 2: What makes a great Product Owner?

May 20, 2021/by Amy Bridge

Why is having a Product Vision so important for a Product Owner?

One of the first questions we ask Product Owner’s when it comes to any kind of coaching conversation is: “what is your product basically about”? And hopefully, the Product Owner is able to give us a short insight into the main characteristics of his product and be able to tell us where the journey should go. If he is able to tell it to us, he should also be able to tell it to stakeholders, users, or clients. The basic idea behind the Product Vision is that the Product Owner should be able to make an elevator pitch for instance to his company’s CEO/CIO of the idea behind this new product.

Are there any good examples of Product Visions?

There are a couple of good examples of Product Visions that are very well known. For example, JFK’s “Man on the Moon” speech or Martin Luther King who stated, “I Have a Dream” and, of course, Steve Jobs’ vision of the iPod. So what we are seeing is that a Product Vision can also be used for organisational or social development as Martin Luther King did. A vision and a clear understanding of the product is helpful and guides people on the journey.

We use the idea of a Product Vision also when we talk about an agile transition. For example, where there is a sponsor at the top who has an idea of how the agile organisation could look like, what the benefit of agility is and why it is important to start working in an agile way. Other good examples of Product Visions can be found within shows such as “Shark Tank”. The principle behind “Shark Tank” is quite simple. There are people who have an innovative product idea and they would like to get some capital from venture capitalists. So they pitch their product and try to convince the “Sharks” to invest in their product.

What can we learn from “Shark Tank”?

The people on “Shark Tank” are extremely motivated in selling their product to the “Sharks”. In their presentation, they will focus on the most important aspects of their product and why people would buy it. Some of them also hand the product to the “Sharks” so they can touch, smell or possibly taste it, which can be quite important for some products.

It’s not only the presenter's work we can learn from. You could also learn something from the “Sharks”. For example, what kind of questions are these people asking? Typical questions include:

have you already sold some of the items or is it still an idea?”
have you been able to collect customer feedback?
what did they say and how have you been able to incorporate that?
what is the market looking like? Are there any kind of competitors?
Why should we use this approach over other competitors? (i.e. a “make or buy decision”).

You will find Product Owners who have given a thought to all these questions, who prepared themselves in front of a mirror or with friends, who thought how to present their product in a succinct way that will be well perceived by stakeholders, users, or the “Sharks”. This helps people to understand the product and to develop it. Therefore, working on a Product Vision is always a good first step on your journey.

Watch the recording of Lothar's webinar on "What makes a great Product Owner?".

*Click here to read Part 1 blog post*

Part 1: What makes a great Product Owner?

May 6, 2021/by Amy Bridge

What makes a great Product Owner?

A great Product Owner always has the customer or end-user in mind. In fact, this is one of the most important things that a Product Owner brings to the Scrum Team. If you look at the Scrum Guide, most of the responsibilities of the Product Owner can actually be delegated out. There is no reason that the development team can’t add items to the backlog and help identify what priorities they should go in. Those are all things that the Product Owner is accountable for, however, can get help from other people.

While the development team is focused on building a product increment and the Scrum Master is focused on the overall health and effectiveness of the team, the Product Owner is still thinking about the end-user.

- - What solves their needs?
  - What are the next most important needs to solve?
  - What are the unanswered questions that need to be resolved and brought into the team so they can make a more effective product?

So if you want to be a great Product Owner you need to always be thinking of what does the customer or end-user need and how can I connect the rest of the Scrum Team to that.

What about teams who are looking for a list of tasks they will be assigned to complete?

It is not uncommon with new Scrum Teams that the development team will just look for “what exactly am I supposed to build - give me a list of tasks”. This is normal, as this is how they have worked for many years. However, Scrum is different. In Scrum, we are trying as a whole team to tackle complex problems. Problems that often we don’t know the answer to. So as a Product Owner you need to help keep the voice of the customer in that conversation. You’re bringing the most pressing challenges to the team - not the most important solutions. So it is often valuable to remind the team, as you start backlog refinement meetings and planning sessions, the Product Owner is there as the voice of the customer to help connect and translate what is the highest priority, what is the highest value work to be focusing on.

What about very needy stakeholders?

As a Product Owner it is not uncommon that you’re going to have stakeholders that have an idea of how something should be delivered, think that their piece of work is the most important and always wanting to know exactly what is going on and when it will be delivered. This is normal. Every Product Owner has to deal with this. So what do you do when that happens?

As a Product Owner you need to understand the needs of the stakeholder and then devise a framework for engaging with those stakeholders and identifying what is the most valuable work. You shouldn’t try to hide this from the stakeholders. Invite them into the conversation. Often invite many stakeholders into the same conversation so they can all see how their needs align with one another.

If you have a particular mechanism that you’re using to determine value, it’s important to share that early on. If your team is building a product that helps another team be more effective, then maybe that is one of the metrics you’re going to use to determine what is the most valuable work to do. Then when a stakeholder comes to you and says: “I want this done and here is why it’s important”, they already know the framework their value will be judged against. For those stakeholders who always want more information, there are real needs behind that. Reach out to them and understand what their needs are.

- - - - Are they using that information for planning or budget purposes?
        
        Are they using it to plan trade shows?
        
        What is it they are trying to do with that information?

And then help them succeed. Help them get the information that they need to make the decisions that they need to make.

Watch the recording of Daniel's webinar on "What makes a great Product Owner?".

*Click here to read Part 2 blog post*

Gaetano Mazzanti (AKT) proves to Martin von Weissenberg (CEC) that Kanban is better than Scrum.

Scrum Survivor

April 1, 2021/by Martin von Weissenberg

agile42 is proud to present a new TV series format: Scrum Survivor! Three software development teams of 7±2 people will battle it out on reality TV. Who will be the winner? Read on for an exciting behind the scenes interview.

“Scrum has achieved global name recognition by now,” says the executive producer of the show, Niels Verdonk. “With software taking over the world, everyone knows what Scrum is about! There’s an immense pent-up demand — millions of people will want to watch geeks argue with Product Owners on live TV.”

The director of the show, Daniel Lynn, nods in agreement. “It’s all about ‘individuals and interactions’,” he says, inserting the inverted commas with a flourish. “Just like in reality TV. Lots of synergies here, and we think this adaptation will work out very nicely.”

“We are setting up three teams now for this spring season that starts on April 1, 2021,” Niels confirms. “The teams will be named Node.js, C++ and The Pythonistas according to their programming languages. We had plans to line up a fourth team too, COBOL, but it kind of died out.”

According to Daniel and Niels, Scrum is a great method for this project. “There’s just so many meetings all the time!” says Niels. “Plenty of opportunities for people to meet and talk and discuss and move notes. Post-it notes.”

Daniel fills in the details. “We’ve been advised to do daily standups, planning meetings part I, planning meetings part II, backlog grooming, brainstorming meetings, customer meetings, quality circles, retrospectives by the book — and a very good book that is, by the way — sprint reviews, retrospectives on the retrospectives, post mortems, and of course the team building exercises that Scrum team members so love.”

“Yeah, and then drinks on Zoom after work — bring your own beer! It’ll be so much fun”, Niels beams. “And then we’ll be taking each developer aside to put their suspicions and reactions on film.”

Success in the game is based on delivering working software every sprint, of course. Also compliance with the Agile Manifesto will be closely monitored and measured. After each Sprint, the team delivering the fewest story points will be forced to vote out a team member.

“There’s got to be some tension in the team, obviously,” explains consulting agile coach Martin von Weissenberg. “Otherwise they’ll get complacent.”

The discussion on how to measure productivity was quickly resolved using Full-Violence Communication. Based on Lothar’s very convincing argumentation, the producers accepted story points as the metric. “The C++ team wanted to do the estimates themselves — they almost had us there,” laughs Lothar Fischmann, who will play the role of Product Owner on the show. ”All estimates in the show will of course be done by the Product Owner, just like in reality.”

The producers are aiming for the teams to complete a number of common challenges, brainstormed by experienced agile42 coaches. One of the first will be to get some training and coaching. “That’s just a simple warm-up exercise. And a trap, of course,” sniggers Martin von Weissenberg. “Any team that goes for the training and coaching will find the other teams already coding away like there’s no tomorrow.”

According to Niels, the teams will be closed down after the season is done anyway, so training them would be a waste of time and money. “But sure, we can send a couple of people to a CSM. If they ask for it. Or buy a few books perhaps.”

How to integrate the immunity amulet is still up for debate, however. Initially the producers were leaning towards giving the amulet to the most productive developer after every sprint. However, installing a proper source code versioning tool to keep track of things would just add to the overhead. “So we’ll just have the Scrum Master nominate ‘the coder of the week’ or something like that,” Lothar explains. “It’ll work out fine, I’m sure.”

Normal work will proceed in the usual way, we’ve learned. The production team went to great lengths to ensure a good, workable backlog. First they copied the list of customer requirements into Jira. Then they started generating insights with all stakeholders in a long series of in-depth, synergistic workshops.

“We added estimates, story points, hours total, hours remaining, projected increments, and suchlike,” Lothar clarifies. “We also filed all 479 backlog items as priority 1 and then flipped the ‘Mandatory?’ dropdown to ‘Yes’ for all of them, so that the team knows it’s all in the contract and not optional in any way.” Martin agrees: “What if the teams left something out, or went and built something that the customer hadn’t agreed to pay for? We would all feel so stupid.”

For the Scrum Master, the team considered a number of high-profile actors — with the additional intention to draw in an extended audience. Early talks with George Clooney floundered, as he was just too likeable for the role. The producers warmed to Jack Nicholson, who, as Daniel put it, “had the right kind of gleam in his eyes.” In the end, they decided that having a dedicated Scrum Master was just a waste of time, so one of the developers will have to volunteer 50% of their time.

“That’s how it’s done everywhere nowadays,” says Martin. “And I ask you — how much time does it take to send out those meeting invitations anyway? What? Yes, well, with all those meetings it will add up I suppose. But even so. Can’t take that much time.”

In a move that has been criticized strongly by many fans in the Agile community, all sprints will be synchronized and pooled up into product increments. “I don’t see what the problem is,” says Daniel. “This is just common practice across the industry. We can’t have one team go off and deliver earlier than the others, can we? Or work in different Sprint lengths? We’d have the customers running around here every day!”

Martin agrees. “Scrum teams can start delivering twice the stuff in half the time, so you will need to slow them down,” he says. “It’s common sense really — just introduce some kind of framework and they’ll be back in lockstep before you can say... um, whatever the framework acronym stands for. If that isn’t agile, I don’t know what is.”

There have been rumors that the lead agile coach, Andrea Tomasini, resigned from the job on the first day. We asked Niels Verdonk if he had any comments on this. “Absolutely untrue! He didn’t storm off and slam any doors at all,” says Niels.

“Rather, just after we finished presenting the setup to him, he had an unfortunate attack of dizziness and needed to go for a stiff drink and a lie-down,” Daniel explains. “The doctors say it’s an advanced case of over-agile thinking. We wish him all the best and hope for a quick recovery. They said they’ll let him out of the padded room within a few months, tops.”

And what kind of reward will the winner of Scrum Survivor get? "Reward?" asks an astonished Niels. "Oh yes, the Survivor will get some heartfelt thanks from the CEO and probably a small gift, like one fine crystal champagne glass. Isn't that customary after a project finishes?"

"Yes, one of those expensive artsy pieces of glassware that you wouldn't buy even if you could afford them, and then you'll have an odd number of them ever after," Daniel explains. "Oh yeah, and they'll still be employed, obviously. Should be grateful."

Authors: agile42 coaches & trainers, Martin von Weissenberg & Pascal Papathemelis

Starting a Scrum Team

June 15, 2020/by Elrich Faul

This blogpost will give you insights into starting a Scrum team, with a recording from the webinar and some additional information to support you with this journey.

As with Scrum in general, starting a team is easy to understand but difficult to master. I presented a webinar on this topic where I wanted to run you through the finer points of starting a team. Starting a team is not just explaining Scrum and proclaiming: “Go!”. It is a process in which the level of complexity needs to be evaluated in order to determine the right approach to move forward. Will Scrum really benefit you? Once this has been established it’s time to get into the nuts and bolts. I discussed what steps need to be taken in the first few weeks and what to expect while establishing a healthy team.

Since we are progressively stepping into a world where remote collaboration is becoming the standard, I created the opportunity for Q&A during the webinar where we discussed some interesting questions regarding remote collaboration as well as other pain points. This can be heard in the recording of the webinar.

For those who missed the live session, don't panic! Here you can find the recording, and it is also available on YouTube. Have a look and feel free to share with friends and colleagues. If there is anything we can help you with regarding this topic, feel free to contact us.

We would also like to share a few links that may be of interest to you. We have a Scrum start-up package for kicking off new Scrum teams, and this link gives you some insights into this service. We would be more than happy to walk through with you how we can help support your teams. Please keep in mind that e.g. the Team Kickoff can be done every now and then with the teams, and we strongly recommend this e.g. after summer vacations or winter breaks.

As we mentioned in the webinar, if you want to take your basic learnings to the next level, we recommend Certified Scrum Master (CSM) training. At agile42 we are currently running this training remotely, and dates can be found from the listing.

For more on the topic of team dynamics, you can always book sessions with a coach, and if you want to learn how to support your teams with this, please have a look at the Advanced Certified Scrum Master (A-CSM) training or the Advanced Team Coaching Course (ATCC) where you can boost your own skills. These trainings give you, as an Agile Coach or Scrum Master, valuable support to help you with your teams.

We have all kinds of support for the Agile teams, and many of the steps that I listed in the webinar are services we can provide, so please connect with us and we would be more than happy to help.

For more webinars and recordings, please look here! More webinars!

To Scrum Or Not To Scrum

June 11, 2020/by Regina Martins

I get many questions in my trainings, and one of the most common is when to use Scrum – usually preceded by utterances of “Scrum will never work in my team…” The wording of the question below comes from the Scrum Alliance Certified Team Coach (CTC) application. So this topic is relevant, and there is no one answer.

The Question

When might you advise a client to apply XP, Lean or a non-Agile approach to workflow instead of Scrum?

Let me answer this question by describing an actual situation. Read on for my thoughts.

The Context

I once coached a program of teams at a large corporate that had to automate a manual and laborious business process onto an off-the-shelf product. This program had been working in a waterfall manner for a year and had managed to automate a small subset of the business process.

A new CIO was employed and decided that this program needed to use Scrum because it would help with faster delivery. When I arrived this is what I found:

Teams had been set up, consisting mostly of contractors from different contract houses;
Most people had received an Agile Bootcamp training focusing on Scrum;
Project Managers were in-house and expected to be Scrum Masters as well;
Teams were supposedly dedicated, but the program manager repeatedly moved contractors in and out of the teams;
The deadline had already been decided by the CIO.

It became apparent that the teams were not set up for success and that the program would revert to using a waterfall process. I thought that by helping the teams focus on some of the principles of Lean without giving their way of working a label, that it would start them thinking about bottlenecks to their workflow and identify wasteful activities.

The Rationale Behind This Approach

Major organisational impediments which due to the nature of the organisation (size, structure, and politics) were outside of the teams’ control to resolve resulted in an interrupted value-stream, but for which they were being held accountable. Here are some of them:

Data sourcing – each business process was multi-layered with multiple data sources which the teams did not own nor have access to. Obtaining data required a long process with multiple approvals;
Environments – development, test and production environments were being built at the same time that the team needed them to do their work.

Program-level impediments:

Teams were not stable – people moved in and out without notice to them and the Project Managers;
No Scrum Masters – Project Managers were expected to also be Scrum Masters – this created a conflict of interest and anti-patterns began to emerge;
Teams did not own their full value stream and yet were held accountable for delivery;
Each business process to be automated was 1 large story because they were not easy to break down into user value items;
Teams consisted of more than 10 people and had 3 Product Owners.

I recommended that teams adopt Lean principles and visualise their work, in its imperfect form, and start improving where they could because:

The Product Owners were present and involved – there was a real effort on their part to help teams break their work down into manageable chunks taking into account the organisational impediments;
By visualising the workflow as it was they would start to see where all their bottlenecks were and having the teams and Product Owners focus on customer value they would begin to identify wasteful activities;
For me, it was also important to help teams see that their current process was not value-creating, and by regularly looking for improvements they would start to look for different ways of getting around that which was seemingly outside of their control.

There are other ways of addressing this type of problem, such as using a complexity frame and the Stacey Complexity Model. As with all things that relate to coaching, the context of the organisation and the maturity of the team are important. In order to help them become unstuck I guided them along this path and brought in the learnings of complexity later. I felt that this was, for these teams, a useful place to start.