Awesome for you. The retrospective can be one of the most fun and informative "ceremonies" of agile.
So once you get the book, Diana is going to recommended never falling into a rut and tailoring your retros based on what is the needed to be focused on, or to take the team into a new direction.
When you first get started though, simple is very good.
Retrospectives: For Continuous Improvement
The misunderstanding of the retrospective as a place to fix problems is very common. However, the goal of the retrospective isn't just to discuss problems; the goal should be continuous improvement of the team's processes.
When things are going well, the team should be asking themselves "What did we do well this ...
While such a confidence check is nothing that you'd read about in Scrum Guide I don't see it as something that violates Scrum in any way. It is, in fact, answering a different question: the one about confidence of people, not the one about forecast end date.
The native method to answer a question about expected end date in Scrum would be based on Velocity ...
Facilitating a meeting is very different than leading a meeting. One focuses on leading the content of the meeting while the other focuses on the structure of the meeting...the facilitator being the latter.
The facilitator manages the meeting plan, ensuring the flow the agenda, the objectives of each agenda item are being met, time, participation, conflict ...
Ideally the Product Owner will be present and will find the retrospective both interesting and rewarding.
However, if the Product Owner does not see their value in technical conversations then there are some things you can do:
Start the retrospective in the usual way but cover Product Owner related issues first, then allow the PO to leave and focus on ...
According to the book the product owner shall be present on the retrospectives, because he can provide very valuable information how the team performs from a business perspective.
Your fear is valid: if the boss is around the team members won't behave naturally and most probably their findings or ideas will favor the boss' expectations.
You could have a ...
The best thing would be of course to have a separate moderator.
Now, considering that if you could do this, you would have already, here is a proposition, which should be considered in all such cases: cycle.
That is: when an important role needs to be regularly taken by some group member, but that assuming this role prevents him/her to ...
Is is right if a team member moans about a 'bad performance' of another team member in retrospective?
No, that's not okay. Most SM's will explicitly call out the rules up front which will include "No personal attacks. Attack issues, not people."
If the person was bringing the issue up that a particular project is under-staffed and thus can't keep up with ...
...a lot of time to deliver even the simplest stories
Only the development team knows what constitutes a simple story.
The time it takes to deliver a story depends on a lot of factors, including:
The quality of the existing codebase
Operational constraints, such as organisation standards, etc.
How high the quality target is
Non-functional requirements ...
The other three are pretty self explanatory: people are the individuals involved in the project and how they conducted the work, processes are how the work was done, and tools are the things necessary to achieve the work. Relationships refers to the connections between these things.
With the people-orientation that the agile methods have, that it tends to ...
The key with retrospectives is to focus on potential improvements, not on problems.
As you rightly say, "John was not performing well during the sprint" is not great language. However, the team might be saying things like:
"We noticed that John got blocked on that first story. Is there some training we can give John to help him out in future sprints?"
I recommend to change the focus of your retrospectives. Instead of finding ideas, try to focus on how to implement a single idea. Let's say, you have three parts of the meeting: finding ideas, what is the next step, and how to implement that step.
In the first part, you do the idea collecting - nothing new here -, but in the second part you pick only one ...
There are two parts to the Scrum Master role:
Helping the team to resolve impediments
Ensuring that Scrum is being followed
The second part often gets neglected, but it is very important.
If the team does not see value from the Scrum approach they will quickly stop following it. The Scrum Master should coach the team to ensure they understand why it has ...
Technical Debt is Often Invisible
The problem with technical debt isn't just that it's there. The bigger problem with such debt is that it becomes a "missing stair" that everyone steps around and never talks about. In other words, it becomes invisible work that eventually acts as an unexplained drag on the project.
The law of transparency says "No ...
What I find an effective way to keep those kinds of "behaviour change" actions under the attention of the team is to hang them next to the kanban board, large enough that they can be read from a distance. And once in a while remind the team about those actions when you think they might have lapsed.
If your Sprint was "accidentally successful," then the Sprint is still a success. It just means that future Sprints might not succeed without process change.
Why This is a Good Question
When using iterative, agile processes such as Scrum or Extreme
Programming, what conclusions can be drawn from successful or
This is a ...
Not just in retrospectives, but in most workshops and meetings, it is very wise to have a facilitator that is separate from the team. This role is for meeting control and does not participate in the meeting content. If you commingle roles, you are degrading the effectiveness of the facilator. So I would answer your question with a no. Bring in a separate ...
I am a little unclear as to what your actual question is here. My advice though would be to have a clear goal/focus for the retro - probably something around accounting for capacity when half the team is out. Action items might be something like get everyones schedule prior to next planning so we can ensure our commitments are actually doable and they are ...
A large part of the context is missing so I'd stick to your "requirements":
Explain why you're timeboxing
Focus on the actions to take, they should be very precise (long-term plans are not a 20 minutes job), actionable, and there should be a clear way of measuring whether the goal has been accomplished or not
Let the team come up with a list of action (...
As you said the team was out of office for half of the sprint and there is little to show at the end of sprint so that means at least the team did good job in including the stories that can be completed in actual sprint( which is one week). So give them +1 for that.
You do not need to change the usual way how the team has been doing retrospective in ...
There is no need to change WIP limit to match the actual capacity. You can monitor its changes and bring that information to a retrospective meeting and see what is going on.
It is fine to have lower WIP than the limit; it means that you have more resources available than needed. When the same column exceeds the WIP means that there are cases when the ...
Mike Cohn blogged on this quite recently.
His comments included trying out different retrospective formats and having a Scrum Master from a different team run the retro.
Mike does emphasise that even a Scrum team that has been together for 10 years gets benefits from retrospectives.
First of all it's a good sign that the team gave you feedback about it. It means they care.
Second. As a Scrum Master your job is to make sure things required in the Scrum Guide happen:
The purpose of the Sprint Retrospective is to:
Inspect how the last Sprint went with regards to people, relationships, process, and tools;
Identify and order ...
I would imagine it is related to the 12th agile principle:
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly".
Reflecting is essential to agile, a retrospective is one way to do it. I've also seen teams that use Kaizen, blameless post mortems, lessons learned, and other practices.
You can define the topics to be discussed up front, based on data collected and affinity diagrams as you suggest. That would make it easier for participants to prepare. But you can also have the participants suggest topics at the beginning of the meeting, and do a dot voting and prioritization. Or use open space technology to have people organize themselves ...
Is this a standard or good practice in facilitating a retro to 'censor' known issues like this?
Yes and no. I feel it's wrong to censor anything, especially talking about impediments at a retrospective. On the other hand, discussing the whole issue again and again and again when nothing has changed is unproductive and wasteful.
As an example: in my old ...
As others have said, there are many ways to structure the core meetings in a Scrum environment. I am a Product Owner and the overall manager of the development group (among others) although there is a "team lead" between me and the developers (he is also the Scrum Master).
As Product Owner, I am present for all Sprint Retrospectives. It is important for ...
We've been doing retrospectives for a long time and that question is also what we had in our mind. We tried to check the status of the action points of previous retrospectives for many sprints.
We noticed that most of the actions took too much time to complete or never completed at all. That is the main problem we face and I am sure it is common for many ...