How to improve your product team’s processes
Process change can be hard. I’ve found most teams over time tend to settle into patterns that are more comfortable than they are effective.
If you’ve been in multiple product development teams in any capacity, or maybe on one product team for a long time, you’ve likely encountered a ton of different processes and ways of building software and working as a team. You’ll have some good examples of processes that worked well from your perspective, and many more that didn’t.
Maybe you’ve seen a process that’s worked well for a previous team, and you’ve tried to implement that process in your current team, but have been met with resistance, pessimism, or apathy. Maybe your last 10 sprint retros have had a lot of the same issues raised over and over, but resulted in little meaningful change?
If this is the case, you’re not alone. Process change can be hard. In my experience, I’ve found most teams over time tend to settle into patterns that are more comfortable than they are effective. Teams also change over time. People come and go, and the dynamics of the team and what works well for people don’t stay the same.
Every team is different, and there’s only one process I’d suggest to every team:
Build a habit of regular experimentation
People are much more likely to agree to an experiment rather than an immediate change that they have no personal experience with (or have had a bad experience with in the past). Most people can live with even a terrible process for a matter of weeks. Framing improvements you want to try as an experiment with an end date really takes the sting out of it. Making it a regular habit means you don’t forget to do it, and are in a state of continuous improvement as a team.
Set a recurring meeting for your product team every six weeks. The purpose of this meeting should be to:
Agree on one or two process changes to run for the next six weeks.
Decide whether to stop or continue the previous process changes.
A few tips on how to make this as successful as possible:
Make sure you agree on what success/failure might look like for each experiment. This can be as simple as a survey, or if you have a more measurable metric, this could also be used. If it’s qualitative feedback or a vote, make sure you agree up front what the criteria are to continue: if it needs a unanimous decision, or just a majority, for example.
Each experiment should (and probably will by default) have an owner who will help set it up for success, make any tooling changes if needed, and be there to help anyone who has questions.
Don’t be over-ambitious. One or two experiments at a time should be the max you decide to move forward. Anything more will just result in the process feeling a little chaotic. Have a persistent backlog of suggestions you can pull from in future so they don’t get forgotten.
You can either collect ideas for experiments ad-hoc, or run the recurring meeting like you do a sprint retro (if this is something you do).
If you’re getting people to generate ideas or identify pain points in a retro style workshop, it might help to scope your discussion down to a particular part of the process or some existing processes you have. Some of the question prompts below might help focus a discussion:
- How frequently do we meet as a team?
- How is scope defined and agreed for the work we do?
- Who is involved in discovery and research?
- What is the typical flow of a ticket through our system?
- What does "Great" look like for the things we ship?
- How do we prioritize work?
- How do we manage bugs within the system?
- How do we write and manage documentation?
- How do we estimate effort?
- How do we ensure small improvements can be made with minimal overhead?
The experiments don’t need to be scientific or super rigorous. Think of them as a tool to help people embrace change more easily, and to give people a safe space to question conventions and suggest new ideas.
If we stay comfortable and keep doing what we’ve always done, we’ll never improve.
Originally posted on Medium.