A very simple way to enable autonomy for a development team
Many times product managers/product owners and development teams struggle to find out the right balance between the vision for a product, details of each requirement, and involvement of stakeholders in day-to-day activities.
The drive for this is the desire to enable team autonomy: the team should be able to decide as much as possible on their day to day activities while maintaining a direction, usually set by the product manager.
Having an autonomous team has many advantages, here are some of them: Moving fast: because it eliminates a lot of back-and-forth in the decision-making process Sustainable on-the-field learning: because the accountability comes together with lessons learned T-shape development: because the team understands more about the business and get feedback regarding their decisions Technical Innovation: because the team has the freedom to experiment as it is the only one who decides how to do something
It is hard to find ways to enable autonomy and, at the same time, making sure that everybody is going in the same direction, toward a vision of the company.
In case you are doing Scrum #
Recently while re-reading some materials about Scrum, I discovered this article (Six Reasons Why You Need to Pay More Attention to Sprint Goal), and I think setting a Sprint Goal is one of the best ways to support autonomy.
If you are a Product Owner and working within a Scrum Team, then setting the Sprint Goal should be the most important objective of your Sprint Planning. You should co-create this Sprint Goal with your Development Team. Please pay attention to this co-creation word. This is where autonomy starts. If you are not creating it together with your team you are destroying one of the main pillars of autonomy. Autonomy (like free-will) cannot be commanded or imposed.
From the same article here are the main reasons why a Scrum Team should have a Sprint Goal:
- Explains WHY the team is building the increment
- Gives Development Team flexibility during the Sprint
- Defines the outcome of the Sprint, not the output
- Should unite the Development Team to go in one direction
- Helps Development Team focus and take decisions
- Manage stakeholders expectations
- Helps communicate increment to stakeholders
I would argue that having a Scrum Goal is more important than what kind of items the team moves from Product Backlog into Scrum Backlog. Without a Scrum Goal, the team implements functionality after functionality and become more decoupled from the product and from actually creating value for its users. Also, without a Scrum Goal, the team needs constant calibration/confirmation with the Product Owner every time new work is discovered in relation to a backlog item or everything they discover something that needs to be added/removed/changed in relation with a product item.
In case you are not doing Scrum #
In case you are not doing Scrum, it is still good to think about some Iteration Goals: an objective set for the iteration which can be achieved by doing some implementations in your product. I use here the term iteration by making the assumption that you are working in some iterative-incremental way.
As a Product Manager, you should be a partner to your development team and together create an Iteration Goal or a Release Goal, which should be an outcome or objective that you all as a team try to achieve in relation to your stakeholders. And when I say stakeholders, I am referring first to different categories of users that are using (in any way) your product.
Or you can think about Product Goals as defined in this article, which seems like a very good critique of Sprint Goals. But I think most of its points are mostly a critique of some implementations of the Scrum framework.
How to create good Sprint Goals #
Here are some of my favorite ways to create a Sprint Goal
- You can use a Sprint Goal Template - see for example Roman Pitchler Sprint Goal Template
- You can use a mnemonic like the FOCUS mnemonic
- You can learn by looking at some challenges of setting Sprint Goals
While writing this article, I discovered two things:
a. There are not many templates to help you write a good sprint goal
b. Twitter can be a very powerful source of know-how
So here is a little gem of knowledge written Allen Holub (@allenholub) by I discovered via Twitter that I think it might be very helpful while thinking how to formulate/create as a team a Sprint Goal:
The sprint goal is to make your user’s life easier in some small area of the domain, usually by providing a high-quality bit of software (…) The goal is all about your users/customers and improving their ability to do their work or go about their lives in some specific area of the domain (…)
This was a great tweet written by Allen Holub (@allenholub):
IMO, the sprint goal is to make your user's life easier in some small area of the domain, usually by providing a high-quality bit of software. It has nothing to do with specific stories, &c., and has absolutely nothing to do with specific dev tasks. 1/2
— Allen Holub (@allenholub) January 28, 2020
The goal is all about your users/customers and improving their ability to do their work or go about their lives in some specific area of the domain. Even minuscule improvement is a success. The specifics of how you do that are irrelevant. 2/2
— Allen Holub (@allenholub) January 28, 2020