4

Our Product/Tech team has been transitioning towards Agile project management in the last year or so, and we hold daily standups, weekly planning meetings and biweekly retrospective meetings. We also use a Kanban board.

As the team's Scrum Master, I've been trying to make the retrospectives more actionable, as some team members have pointed out that we often end up discussing the same issues that don't get solved. I'm worried about the impact of this on team members' morale and desire to participate, so I've tried several approaches to make things more concrete, such as 15% solutions, and limiting the number of action items that we commit to doing to the bare minimum (i.e. 1-2). We've also been adding those items to our Sprint board to give them visibility. This has helped quite a bit with ad hoc, concrete action items.

What I'm struggling with right now is what I call "intangible" action items, i.e. items that are linked to habits or behavioural change and/or are recurring in nature. Here are some examples:

  • When pulling a PBI into Building, take some time to think about how it will be reviewed so that it doesn't create bottlenecks in the Ready to Review column
  • When estimating roadmap items, multiply by 2 so that we provide more realistic estimates
  • During the scoping phase, map out dependencies so that we can plan the work better

I could of course put all of these in a document and share it, but it would probably end up on the proverbial shelf and never get implemented. From my experience, even when these solutions emerge from the team to tackle very real problems, because of their intangible nature, they quickly fall by the wayside when things get busy. Hence my question: How do you make sure those action items get implemented? How do you keep track of them?

  • 1
    Good question, asked well. But I would urge you to take a second look at the issue "roadmap items, multiply by 2" - this sounds like a potential dysfunction and perhaps there is a further learning opportunity still to be discovered. Good luck :) – onedaywhen Jul 26 '18 at 13:51
  • @onedaywhen The solution you mentioned was meant to signal to the PO/PM that the amount of work that is currently being crammed in a quarter is too much for what the team can deliver while operating as a sustainable pace. Can you expand on what you saw as a dysfunction? I'm not sure what you mean, and I suspect it could be because this is one of our blind spots. – Balala Jul 27 '18 at 18:23
  • As I am reading it, your team makes an estimate that they consider to be 'unrealistic' (a fantasy? dishonesty?) then doubles it to make it 'more realistic' (less fanciful? more honest?). Why not just stick to making realistic estimates in the first instance? If requirements aren't detailed enough to make a realistic estimate, why not push back on that? If work is being pushed on the team months in advance by people outside the Scrum Team, why not do the Scrum thing where items are pulled into a Sprint by the Development Team during Sprint Planning? – onedaywhen Jul 30 '18 at 9:53
6

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.

  • I like the idea of making them visible on or next the board. To make sure they're legible, I would probably try to find shorthands (1- or 2-word summaries of each policy) for each one. And instead of going through those policies all the time (one very boring way of making sure they're remembered), focusing on what I've observed is lacking is probably a better approach. – Balala Jul 26 '18 at 11:21
1

There is also term "built-in quality". It means, that the process policies you describe, should be as closer to place where they are needed, as possible. For example, set WIP limits on your board, like in Kanban. Or call columns correspondingly, or put a short note with oncoming rules on it.

1

This are my two suggestions:

  • Action items derived from a retro need to find it’s way into a document
  • You can add a task into the current sprint to address issues raised in the retro and it should be marked as completed only if you found a true way to get rid of the issue forever

It seems like you don't think that getting this into documents would work, but I believe that you need to convince your team that documents represent agreements. They are not meant to be static, they are expected to change in order to respond to the needs of your project.

  • I'm not necessarily opposed to putting them in a document, I'm just worried about the team forgetting about these things they agreed on, because they're not "tangible" or visible enough. How do you make sure the team follows them? – Balala Jul 26 '18 at 11:16
  • I like the idea of creating a task on the board when there isn't a clear solution. I could see how it could easily be translated into an internal user story. – Balala Jul 26 '18 at 11:17
  • I think that your team just needs to get used to go to the documents. Make sure they understand their value and that they are structured and not too long. For example, you can have a document for ways of working, another one for discussion policies, perhaps another for emergencies, etc. – Roberto Anzaldua Jul 26 '18 at 11:19
1

If it's behavior change, then my experience is that shouldn't take more than a couple of sprints/weeks before the new behavior becomes a habit. My suggestion is to treat them as any other action, put them on your task board and follow up regularly.

If after some time they still need a lot of attention, then there's a deeper problem. The recurring action might be a retrospective smell that needs attention.

Does this make sense?

  • 1
    Yes! I also like the "retrospective smell" metaphor. I'll give this a try. – Balala Jul 27 '18 at 18:30
1

The best way to implement such changes is directly in the system itself.

For point 1: You could modify the DoD for the column before building to include "prepare review criteria" or even make it an extra column before Building.

2: (Aside from the fact that I am sure there are better alternatives to estimating) I would modify the system that uses the estimate. For example if you multiply it by 1000 to get a price, start multiplying it by 2000 instead.

3: This too is either an addition to the DoD of the Scoping column, or an extra column before or after it.

1

A "Shu" suggestion: Make these issues visible on a dedicated Retro Issues Backlog. When the issue re-surfaces put a red dot on it or when it persists put a yellow dot on it. When a new dot appears, ask the team to brainstorm reasons or conditions that allow new dots. Ask other teams if they have the same situation or how they deal with it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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