3

My team has certain issues which I have already determined, namely:

  • They are not pairing enough
  • Their cycle time is very high
  • They break timeboxed tasks
  • The team is not splitting QA work equally, they assume the QA guy needs to do it all

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.

1
  • 1
    When you say "I", who are you? Are you the product owner? The scrum master? The team manger? The CIO? A team member? How you handle this depends on your role. Feb 29, 2016 at 20:52

6 Answers 6

1

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.

1
  • I was thinking of doing the Analyse Stories exercise to gather data, so this is more focused
    – TheLearner
    Feb 22, 2016 at 16:58
5

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.

2

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.

2
  • Thanks mate. This sounds like a great idea. My retro's tend to be more action focused, so chilling things out a bit and just talking about things sounds like an idea to make people just feel good about things. Maybe I should take the team to a pub and do it there.
    – TheLearner
    Feb 20, 2016 at 16:45
  • It can get emotional and heated at times as things are brought up but providing a safe open environment that everyone can speak freely really helps.
    – Mamof
    Feb 20, 2016 at 17:24
2

I read two questions:

  1. How to tell the team the observed aspects
  2. How to work on the observed aspects (in order to get them out of the way)

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:

  • Try to find objective observations instead of vague feelings. Focus on general observations on the team instead of single team members.
  • Make a list of things, the team is really good at - don't forget a retrospective can focus on positive aspects also in order to keep them living.
  • Start to tell your observations and ask the team how they interpret them instead of telling them your interpretation also. Ask questions instead of giving solutions.
  • Identify positive and negative topics to work on (Someone at PMSE said more of..., less of...)

After the team discussed your observations, leading to positive and negative topics make a break and afterwards work on the topics:

  • Prepare a list of influencing aspects - not jet causes or actions. Separate between Team Internal and Team External. Visualise everything somehow graphically on a flip chart or similar.
  • Ask the team to extend your list resp. discuss it.
  • Start to search for causes by combining the positive / negative topics with the influencing aspects.
  • Identify actions

As usual, keep the team in motion by involving them using cards, flip charts, etc.

1

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

1

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

2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.