Lately, I’ve been trying to work out a set of “primitives” for retrospectives that can apply to a range of project approaches, IT systems and organisational cultures. The idea is to have baseline concepts (primitives) that can be used to guide thought and discussion. To aid my thinking I decided to present the early thought model here so as to formalise the idea and seek feedback. Retrospectives are not solely an agile concept and don’t even need to be formally held. You may run a retrospective with the project team every n days/weeks or as a personal reflection with your morning coffee. I’d like to lay out and develop some areas for such consideration. I’ve come up with three primitives:
My feeling is that these three interconnected concepts have utility to teams working on delivering an IT system. You may talk any combination of scrum, waterfall, microservices, legacy, cloud and so on but I think those three primitives are core to the work you do. I’ll delve (briefly) into these in the coming sections and would enjoy your critique via comments to this post. For each primitive I’ll also provide an essential question as the organising focus.
Essential question: How well is the team working together?
This is a people question and it’s vital. The people in a project and how they interact will determine its outcome. How you define “team” is dependent on many things but it’s a pigs and chickens thing - you should primarily include those who have skin in the game in your evaluation but be careful of ignoring the chickens.
Essential question: How well are we moving in the right direction?
Vectors have magnitude and direction and projects should too. However you describe “scope” (magnitude) you need to make sure you have the right amount - too much and you get crushed. How well you’re tracking (direction) is also important. Some projects are based on a set of deliverables so you evaluate how well the work is going in terms of meeting those deliverables within the agreed timeframe. Other projects are time & material based so you evaluate them in terms of how well they’re meeting client expectations. In both cases your project’s vector is important but is evaluated in different ways.
Essential question: What gets in our way?
Waste reduction is very much from the Lean playbook but is broadly applicable. Analysis of this primitive asks us to look at formal and informal contexts that soak up time and resources without providing any real return on the outcome. Some things get in the way that we can remediate. Some things seem annoying but are critical. Take security penetration testing for example - having to wait for a centralised security team to run the test suite may be wasteful if the project team could run it themselves on-demand. You should still run the test but need to determine if the process can be improved.
Using the primitives
It’s important that the primitives aren’t seen as negatives and are evaluated from different angles. Non binary approaches such as the thinking hats are useful here. You’re seeking to improve, not to blame.
Each primitive is also abstract so you need to determine how they attend to the work at hand. For example, “where do we experience waste?” is not a very useful question. Instead, a project experiencing a lot of system failures (a waste) might ask if their delivery pipeline needs a tune-up.
The team/individual would consider each primitive using the well-trod questions:
- What are we doing well?
- What have we improved on?
- What needs improving?
It’s important to note areas for improvement and track progress in resolving them. Naturally, the team can’t solve everything so prioritisation is the key. It’s also important to celebrate not just the delivered units of work but also the improved work processes.
I’ve outlined three retrospective primitives and how they can be considered. I’m still thinking through possible additions. I also recognise that there’s a coupling across those that I have listed. For example, low cohesion is wasteful as information isn’t flowing through the team.
I’d enjoy your feedback.