27

It sounds like you have team members from high power distance cultures. People may not speak up when the boss is in the room because their values require them to listen and follow, not to advise or lead. You may even notice it happening between junior and senior team members or between yourself and team members. Read more about power distance here: https://...


19

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. ...


15

This is a tough situation. Since the manager does work with the team on the delivery of product Increments, the manager is a member of the Development Team. Because of this, the manager should be a participant in all of the Scrum Events, including the Sprint Retrospective. Because of this, the Scrum Master should not uninvite the manager from any Sprint ...


15

Analysis There is a chilling effect when he is here. Am I overreacting? Should I just try to build up the confidence of the team? or should I ban my boss from the retrospective? In my experience, this is a classic case of missing the forest for the trees, and mistaking process problems for interpersonal ones. Let's enumerate some of the issues that ...


14

There is nothing wrong with this type of scoring. This type of customer confidence score is the same general idea as NPS and a multitude of other score. Whether or not it is healthy is largely dependent on how it is used. First, it is important to understand what this score is and is not. It is a satisfaction score. It tells you about the individual's ...


13

Do other companies do this? Is it considered Agile? Can it show real insight? No. No. No. Why not? Because it's completely pointless. You said you have sprints. I guess they have tickets or stories in them. So you already have an objective measurement how you did. 8 of 10 stories done? 95 of 98 story points finished? There you go. Objective measurement. ...


12

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 ...


11

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 ...


11

There are two things to comment on here: Can the Scrum Master exclude somebody from a Scrum ceremony? Should the Scrum Master exclude somebody from a Scrum ceremony? On the first question, a Scrum Master cannot choose of their own accord to exclude a team member (even if they are part time) from any ceremony. However, they could ask for somebody to be ...


10

Ideal 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. Abstract That is: when an important role needs to be regularly taken by some group member, but that assuming this role prevents him/her to ...


10

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 ...


10

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 ...


9

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 ...


9

...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 ...


8

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 ...


8

If this manager is part of the team and codes and completes tickets in the team's sprint, then he needs to be at the retrospective meetings. Your Scrum Master screwed this one up by uninviting him. As per the Scrum Guide, the purpose of the Sprint Retrospective is to: Inspect how the last Sprint went with regards to people, relationships, process, and ...


7

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 ...


7

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. NOW You do not need to change the usual way how the team has been doing retrospective in ...


7

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 ...


7

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?" "...


7

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.


6

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 ...


6

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 ...


5

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 (...


5

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 ...


5

TL; DR 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 unsuccessful Sprints? This is a ...


5

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 ...


5

The Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen will answer all your questions about retrospectives.


5

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 ...


5

I used to take pictures as well. Another possibility is having some (or many) take notes in a shared google doc. This also work for on-line retrospectives. The key point, in my opinion, are any action points. It's all nice and fine to dig down to root causes, but in many cases it's quite unproductive: many root causes lay outside of the scope of the project ...


Only top voted, non community-wiki answers of a minimum length are eligible