Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
My team has certain issues which I have already determined, namely:
Generally the team is working quite slowly.
How can I have a retrospective to bring this to the surface but not hurt any feelings i.e. the retrospective needs to address the high cycle time essentially and these issues.
There is nothing wrong with giving a team a scope for the retrospective, especially when these meetings does not provide too much for the team. You can set a theme like "speed" or "number of delivered items" and let the team discuss these topics. When the learn how to deal with narrowed scope you can provide them a bigger one. Based on my experience a team can have better retrospecives and improved processes in 2-3 months with this technique.
Remember that the goal of an agile team is to be self organising. To achieve this they have to have the opportunity to identify their own faults and come up with their own solutions.
It can be very tempting to step in and guide the retrospective. But this runs the risk of removing the responsibility from the team to fix their own problems, which can be counterproductive. There is nothing wrong with suggesting solutions, but you want the team to spot the problems.
As a Scrum Master, when I identify problems I will typically try and find some way of highlighting them. For example, if the team is splitting stories across time-boxed sprints I would start to track this and make the results visible. Usually the team starts to address the problem once they recognise it.
Reading through your list, it surprises me that none of these items have been mentioned in the retrospective. For example, has the tester not commented on the the way the QA work is being divided up? Has nobody mentioned that they are breaking tasks across the time box?
Perhaps the format of retrospective you are using does not encourage team members to speak out? This is one of the reasons a common approach to retrospectives is to have the team members write their feedback independently at the start of the retrospective. Then the team as a whole discusses each item in turn. This ensures that everybody gets a voice.
We've experienced a similar problem at the company I work for and it typically falls by to trust among the team. Before you can really address the cycle time issues you need to rebuild the team unity.
Probably the most successful retrospective we've had we started out like any others with a checkin question and reading the prime directive. We handed out stacks of 3x5 cards and sharpies to everyone and set a large bowl in the middle and told everyone to write anything and everything they feel about the team and their current work environment. After everyone was done writing our moderator read each one out loud and stuck it on a white board. By the time the bowl was empty we had entirely filled up a large whiteboard and he asked if anyone saw anything they wanted to talk about.
It was a long 4 hour meeting but when we got out of it every person felt much better about the team and within 2 iterations we were out performing every other team in the department and it was easier to guide future retrospectives to point out any issues because the team felt they could all talk freely.
I read two questions:
In general, investing now in team building and team development might increase efficiency and effectiveness enormously in the future.
The general recommendation for the first question comes from negotiation theory. I don't know the original English expression but it should be similar to: Soft to the person, hard to the point.
I would try something similar to the following:
First, prepare yourself:
After the team discussed your observations, leading to positive and negative topics make a break and afterwards work on the topics:
As usual, keep the team in motion by involving them using cards, flip charts, etc.
It appears that your team has not got the right induction on the process and benefits of implementing the Agile methodology.
I would suggest you pause your engineering activities, formally run a project kickoff covering the process, roles and responsibilities, benefits from the product / project realisation. Later, revisit on your product backlog, and continue your journey.
Please note, the retrospective is always reactive that help in addressing the lessons learnt (costly mistakes).
It might be helpful to do an exercise in the retrospective to come to an good understanding why people are not pairing enough (BTW, what's "enough") and insufficiently collaborating as a team.
You can use questions for this, or a constellation exercise (described in my book) or any other exercise to generate insight.
Focus on first building a shared image with the team of how they are doing now will help you to have a better case to take action. Chances are big that the team themselves decides on what to do more or less. This is where a starfish exercise can be valuable.
@BenLinders
