We’ve already looked at how platform based teams can be deployed in your agile organisation in part 1 of this series. Then in part 2, I showed you how we transitioned to project based teams, and why that doesn’t really work. In part 3, we delved into how feature based teams could work for you, and in this article we’re going to look at objective based product development teams; the way my teams are currently set up.
So what is an objective based product development team?
An objective based product development team is a team that is aligned to a clear objective. The objective, and the way we measure success against that objective, is defined by the business in the form of Objectives and Key Results (OKRs).
Objectives and Key Results
Objectives are what you want to achieve
Key Results are a set of metrics that measure your progress towards the Objective
Read more at felipecastro.com/
We set OKRs each quarter, and we work with the development teams to generate “bets” (or “initiatives”) that might help towards achieving our key results.
Each team is aligned to a single objective for each quarter.
We are still using the exact same team composition as before:
- iOS developer(s)
- Android developer(s)
- Backend developer(s)
- Frontend web developer(s)
- QA specialist(s)
- Scrum Master
- Product Owner
All we did was change the team’s responsibility from a specific feature/set of features, to alignment with OKRs instead.
Why did we make the switch?
As I mentioned in part 3, we had a problem. Some teams were idle, whilst others were overloaded with more important enhancements. We weren’t always working on the most valuable thing for our customers; so we decided to make a change.
Changing our focus to OKRs allowed us to reap the benefits of OKRs and marry those to an awesome agile development process. We combined the best parts of “deciding what to do next”; with the best parts of “delivering it in the best way”.
Rather than stakeholders determining the best solution to a problem, we asked the stakeholders to prioritise the problems to solve. Armed with that information, we turn to the team to build the best solution to that problem.
There are a few immediate benefits of doing it this way:
- You get way more engagement from the teams solving the problems – as they get to define the solution
- We move our focus to outcomes, rather than output.
- We reinforce iterative development; if the solution a team provides doesn’t move us closer to our key results, then the team has to try a different way of solving the problem.
By far the biggest difficulty has been changing the behaviour of our stakeholders. For a long time they have been providing solutions, and asking for dates of completion.
We’re trying to enable autonomous teams, trying to move away from delivering the features stakeholders want, and move towards the goals our stakeholders are trying to achieve.
We’re not asking for free reign to build whatever we want, we still need to follow a great product discovery process; the solutions still need to be viable for the business.
We are asking to be given the autonomy to build the best solution.
Instead of committing to delivering project X by date Y, we want the product teams to commit to iterating towards delivering the key results by date Y.
This is a big mindset change for our stakeholders, it will take time.
What good looks like for us
- Long lived, engaged, autonomous teams iterating towards key metrics of success
- Stakeholders who define a vision with clear objectives, rather that solutions to problems
- Move away from Gantt chart style project planning, and more towards iteration of product features
- Using data to drive decision making and prove our bets have worked
- Focus on outcomes, not output
4 steps to success
- Define the vision. Inspire people on where you want to be
- Agree OKRs for the next quarter; one OKR per team
- Generate bets with the product development team(s). Get them engaged with solving the problems and how we are going to measure success.
- Implement those bets, gather feedback and iterate until the key results are achieved.
I’ve put a lot of thought into how the teams are guided through delivering the best possible results for my department and for our customers. I’m very lucky I work with lots of very clever people who all want to do amazing things. Using objective based product development teams helps the business prioritise the outcomes they desire, whilst also tapping into the huge potential of the the teams tasked with building the best solutions.
I’m 2 quarters into this new team structure ( 6 months), and we’re still trying to get it off the ground, to get the stakeholders onboard. It’s tough to implement, but in the long term I’m sure it will succeed. We’re still learning and adapting and will make further changes if we need to
I hope this article was helpful, if you think this article or series of articles can help anyone else, please share using the links below.
Have you tried something similar? If so, get in touch, I’d love to hear from you! Maybe we can help each other out.
Till next time.