It’s not because they’re not working hard enough
The fully-staffed, cross-functional, multi-faceted team. Photo by Haste LeArt V. from Pexels
Many technology leaders I coach express frustration with their Agile teams.
They don’t feel they’re delivering consistently, not pushing features out at the promised cadences. Or the teams are not held responsible for making commitments because they’re “Agile.” So the natural reaction is to move the people (“Resources”) around more, push harder, maybe add a few additional developers.
Unfortunately, all these approaches make things far worse.
The effect of a pure Project Thinking focus
When leaders focus only on Project thinking:
📌 When Will It Happen?
📌 Who Will Do It?
📌 What Else is Like This?
📌 How will we do it?
Directly traceable from the “When” and “Who” questions they’re constantly asking, they tend to believe the “ Individual Resource” is the unit of measure.
Increasing Utilization at all costs
All systems in legacy Enterprises are created and maintained with an obsession on Utilization — keeping all workers busy 100+% of the time.
To do this, a Subject Matter Expert (“SME”) or tech specialist (Database Administrator, or “DBA”) role gets split, with one person fulfilling the role on as many as 5–10 teams simultaneously. In order to keep that person busy, we’ve now exploded the number of external Dependencies. Who gets to decide, across the 5–10 other work streams, which should be prioritized first? Is it up to the individual? What happens when five or more teams, or 50+ people, are blocked from moving forward waiting for the same person to address their tech need?
Across the many legacy Enterprises that have moved to Agile delivery methods, measurement remains on factory-focused Output goals:
📌 Hours worked
📌 Story Points completed
📌 Stakeholder-requested features delivered
We only get more of what we measure for
Because increasing individual utilization or questioning deep siloed specialization is never raised, it therefore seems entirely logical that simply adding more fungible developer “resources” will increase the team’s ability to deliver more of what they’re measuring for — Story Points & Features.
But introducing more people to a team actually destabilizes the Storming-Norming-Performing cycle, massively sabotaging the team’s ability (definitely in the short term, if not longer) to deliver “any” intended results until they’ve re-stabilized.
But the software engineers were never the real constraint in the first place.
So the real underlying bottlenecks don’t get addressed, and there’s no lens through Project Thinking and seeing Individuals as the Unit of Value Delivery that will ever cause leaders to look there, massively increasing risk that anyvalue will get delivered at all.
Project Thinking isn’t all bad
There are times when execution are important, and it’s important to realize it’s not an either/or situation–only to understand how the focus on Project Thinking may be impacting our teams’ in ways leaders don’t see as important.
A potential shift of thinking and focus
Leaders who shift to including Product Thinking in their focus:
🎯 Why is it important?
🎯 What are our goals?
🎯 What else could happen?
🎯 How will we differentiate?
Become open to the possibility of seeing the Team as not only the unit of measurement, but the engine of engagement, creation and achievement, and use a new set of success metrics:
🎯 Throughput and Flow Efficiency — Delivering sooner
🎯 Value delivery towards Outcome-focused goals
🎯 More customers succeeding in ways that work for them and our business
The impacts of Product Thinking and seeing the Team as the unit of Value Delivery
As they grow in size, teams within megacorps and startups tend to implicitly bias more towards Project Thinking and not enough Product Thinking.
Product Thinking is a mindset and a process that, once you see, you cannot unsee it.
Shreyas Doshi
The Product Thinking shift
When leaders shift to the priority (“Why is it important?”) and strategy (“What are our goals?”) lenses of Product Thinking, several important shifts take place. The primary concern moves away from keeping people busy — to making sure teams are set up to deliver the highest-priority work done soonest.
The impact of this shift becomes two-fold — how teams are staffed, and what gets measured.
Measuring Teams instead of The Individual
When Leadership puts different systems in place measuring Teams instead of Individuals, the following three steps emerge:
When we fully-staff teams with “T-Shaped” people…
Moving away from siloed areas of expertise, by encouraging hybrid, “T-Shaped,” “Pi-Shaped,” or “Comb-Shaped”skillsets, people on the team can expand their interest and engagement by learning and becoming proficient in other skills areas.
The software engineer who has Quality Assurance Automated Testing experience, or DBA skills. The UX Designer who can do some front-end coding. By decreasing specialization means…
…Dependencies get reduced…
The can reduce their reliance on narrow specialists outside of the team. They take increasing control of their destiny, and can manage their time across the full range of tasks that need to get accomplished.
…and the right metrics start to move
Once leaders staff their teams full time, and encourages their people grow skillsets across the team, and start to measure their teams for Throughput or Flow Efficiency, they’ll see that a higher percentage of teams will improve in their ability to go from idea and working tested software sooner.
Shifting to an Outcome delivery focus
When fully-staffed versatile teams are tasked with delivering client-centric and business success Outcomes, (typically in the context of a well–implemented OKR engagement), leaders can further eliminate the need to micromanage traditional factory measurements of hours worked, velocity, and number of features delivered.
Measure the Team, and move to an Outcomes-Delivery focus
Once leaders balance their Project Thinking with Product Thinking, they can fully-staff their teams, and measure by a different set of metrics, from those suited to factory work to those suited for responding quickly in an uncertain environment to rapid value delivery, achieving both people and Outcome goals.