Principle Twelve | Fish Percolator

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

This is the last line of Principles behind the Agile Manifesto — the twelfth principle of twelve — placed at the end as a reminder that nothing is ever decided, complete. Not even the Manifesto itself.

But sometimes we spend so long developing and documenting our processes and ways of working that we forget we can change them.

Maybe you’re doing Kanban or Scrum and it’s not quite working for your team but you feel you can’t change because it’s what other teams do?

Maybe you have a cumbersome change management process that worked when you were an IT-heavy organisation but is now getting in the way of a rapid development lifecycle?

Maybe you’ve been allocating points values to stories but you’re not really sure what that data is used for, if it is at all?

Maybe you have a culture of endless meetings without agendas or minutes? Or a proliferation of similar-but-not-quite-equal Slack channels, each only getting a handful of messages a week?

These are just some of the examples I’ve seen over and over in my time at different organisations.

People doing things that aren’t good for their teams just because of inertia: the processes seemed like a good idea once (or they grew organically) and no one is speaking up about them not working today.

How to actually review ways of working

Here are my tips for how to ensure your ways of working get reviewed regularly, and the team is always operating effectively:

I like to use “Principle Twelve” as a verb, like: “Let’s Principle Twelve this situation”. Whenever I spot something that’s not working effectively, I kick up the conversation about whether it’s actually appropriate.
You might already have regular retrospectives (“retros”) in your calendar, but are you including dedicated retros or workshops to talk about ways of working? Even if you think things are working well, creating an open and inclusive space for everyone else to vent their frustrations might unearth things you weren’t expecting.
Forget standardising your practices. Sometimes doing the same thing across multiple teams can help, especially with people moving between teams and anything that happens across multiple teams, but ultimately each team should feel comfortable setting its own ways of working, as each team will have its own needs.
And, perhaps most importantly, prioritise team health and having fun. If a process isn’t fun and it’s quoted as a factor in morale dips or mental health, then it isn’t working, no matter how theoretically fast it would make your team. Your team is paid to think and if their thinking is clouded by misery then they will be working much slower than they could be.

Are you already doing all of the above regularly? Let me guess, your team has already discovered the secret ingredient: delivery managers. In simplistic terms, delivery managers differ from project managers because their primary responsibility is removing obstacles. A good delivery manager will apply Principle Twelve regularly to every aspect of a team’s operation.

If you don’t have delivery managers, you can - of course - hire them, but you can also send your existing project managers or team leads on training to learn these skills. A good place to start might be reading the GDS definition of a delivery manager.

How is your team at adapting its ways of working? Does it get stuck in the weeds of documented processes or is it constantly adapting? Can I help? Let me know!

Fish Percolator is a technical leadership consultancy based in Yorkshire.

If your team is not running as smoothly as you'd like, you have long gaps between releases or bugs in production, or your people are not excited about coming to work every day... we can help!