When velocity elbows out value — the perils of scaled product development.
Recently I spent some time as a caretaker product manager for an agile delivery team.
Delivering someone else’s roadmap to someone elses timeframe, within a product area I knew little about, with a team of whom I knew the names, but little else. Not the ideal situation, but I did get some fresh insights, into a scaled agile dilemma, which as a coach, I think I have some times missed.
The scene
The team was one of five working on the same overall product, each team accountable for a specific scope/goals and prioritising their own roadmap.
It’s well documented that teams work most efficient, when they are settled, all focussed on the same goal and can perform whatever task that will help deliver that feature/product fast and to a high quality. So far so good.
But what happens when the team is fixed, not completely cross functional and the highest priority requires a skill that only part of the team has?
The crime — when velocity wins.
A story planning session uncovered that the highest priority items, let’s call them 1,2,3,4 — all required a skill that only a few in the team had.
Too often this is what happens next: the product manager scrambles around for tasks that can fill the time of the team members not skilled for the high priority items. Thinking more about keeping the team productive, than what is most important to do.
Which means that instead of the whole team working on priority 1, part of the team is now working on priority 5 — splitting effort and focus of the team.
All of the joint meetings/conversations now take a bit longer, because we are working on two vastly different features, the tech lead’s thoughts are split on two solutions and the other developers can’t pair or collaborate. From a product perspective the priority 1 feature estimated to one sprint’s effort — ends up taking two, because only part of team is working on it.
The fight back.
This was how this team usually worked. Frustrated about this approach and the impact on the team’s focus and the product delivery timeframe, and challenged them to make a change.
For the next sprint we had one focus and I did not take into account, whether this would create enough work for everyone.
Our grooming and sprint planning meetings were mostly done in 15 minutes. Everyone were thinking about one thing, which meant that daily stand up updates were super relevant for everyone. The slack channel was a hive of relevant ideas and information. We could now solve problems and come up with alternative solutions as a group.
Most importantly we delivered quickly, what we estimated to be 3 weeks of work was delivered in 2 (and we had people on holiday).
So what did the people without the ‘right’ skills do? Well, they did what they could: testing, pairing, trying to code in a new language, and most importantly they helped with finding solutions.
When the team was focussed on just one thing — everything just became easier.
Will the result always be this good? Maybe not, I was lucky to have a team happy to experiment and try new things.
Where to from here?
As much as the Spotify model of settled teams is a good way of scaling agile product development, it does throw up challenges, if the team is not fully cross functional.
We need to continuously review the composition of teams to ensure that as the product evolves that the team structure and skillset is still right — and in the same way that teams continually strive to improve their processes, they should also continuously strive to improve their skills.
Even if a team is at a peak in terms of performance, it doesn’t aid the greater good, if they are not focussing on what brings the most value to the business.
If your team is not/cannot be fully cross functional, then you need to review how you organise your teams in terms of scope and membership:
- Consider consider cross team secondments to share skills
- Decide the high-level roadmap and priorities at portfolio level and let the team pick the work that suits their set up
- Use ebbs and flows in workload as an opportunity to up-skill or cross-skill
A settled team shouldn’t mean a static team and it needs to evolve with the product it is delivering — and how we organise ourselves should continue to evolve in the same way as we evolve our processes and products.
leanasabean.wordpress.com/2017/08/07/when-velocity-elbows-out-value-the-perils-of-product-management/
