I'm the portfolio manager in PDS and I oversee our projects and programmes, which vary between technical infrastructure programmes, bespoke development projects, and detailed procurements.
No single method of delivery fits the breadth of our work so we have a flexible toolkit that allows our managers to use the most suitable approach. However, there's one principle that applies across all our projects which I'm going to talk about in this blog post.
Reflection as a tool for change
Some principles are process driven, like having robust control over financial management. Others are driven by culture like nurturing an environment where teams feel 'safe to fail' and are encouraged to experiment and try things out.
One of the cultural principles that I see often is regular team reflection. This can add value, no matter the type or scale of project.
In our team, we regularly take the time to look back. We look at what's been happening recently, explore how things went, and look at what adjustments we can do to make things better. Retrospectives are common in agile teams, but in other ways of working, it's often left until the end of a project before a 'lessons learned' exercise happens.
In its most basic form, a retrospective asks three questions to a team:
- What went well for us during the last sprint/fortnight/whatever period makes sense to you?
- What didn’t go so well?
- What should we do differently?
The idea is to have some actionable tasks by question three to help incrementally improve the team’s ways of working. The real outcomes are far broader.
Having a conversation where low-level success stories are shared and celebrated can be transformational for the morale of a team. Providing a safe space for the cathartic act of discussing frustrations can also bring a team closer together. Especially as it can generate ideas for practical solutions that may otherwise have been missed.
Guidelines for being reflective
There are a few guidelines that I've seen work well when organising a retrospective:
Everyone is encouraged to contribute
Some team members might need encouragement to join in, but it's really important that everyone’s voice is heard. The quieter people in a team can often be the most observant and reflective.
Use an external facilitator
Having someone from outside of the team run your retrospective allows everyone to contribute on an equal footing. Someone who doesn’t know the detail of what the team are doing will often ask basic questions that may help to expose assumptions or offer a new perspective that the team wouldn’t have been able to do for themselves.
Dedicate the time
Making dedicated diary space for the session, and encouraging everyone in the team to prioritise the time, is really important. Treating a retrospective as an afterthought can diminish its value in the minds of the team members, which will reduce the quality of their input.
Keep an open mind
Try not to make assumptions about what you're going to hear, and as the leader of a team, try not to steer the conversation. All opinions must be treated as valid – the retrospective session isn’t a place for debate.
We don’t have a single, consistent approach to running retrospectives across all of our projects and programmes and that’s okay. We don’t need to do things the same way for them to be effective.
What we will be doing more however, is making sure that reflection is embedded in all projects, in whatever way works for them. This approach fits comfortably alongside our recent implementation of a quarterly survey to monitor team health and our new praise wall, all of which support our Director's intention of having a happy and healthy team.
Read more about the cultural values in PDS.