Defining Team success: the what, the how or the why?
I believe it’s important to go back to basics and frequently revisit how you define success for your team. After all, our focus with attention and through intention matters.
When I ask software development tech leads what success looks like for their team, I hear lots about the behaviours and practices they’re adopting (inputs), some more about code quality and velocity (outputs), and not so much about their customer’s experience (outcomes) from interacting with their software. Whilst I’m a massive advocate for continually refining the inputs that make the journey a success, I think it’s critical to get clear on the destination.
Understanding Success: the shift from outputs to outcomes
In sports, one definition of team success can be as clear as winning the game. Points on the scoreboard. Outputs.
The traditional idea of success in software development is classically defined as delivery on time, on budget, on value (McKinsey) and according to specification (Standish). These however remain a limited view of a team’s outputs and unfortunately are still too often deferred to as the yardstick.
In the agile age of customer capitalism, we see the shift in marketplace power from the seller to the buyer. Why then are we still constrained by such narrow thinking for defining software development team success?
Shore and Warden argue for an expanded view, naming three types of success to be considered in The Art of Agile Development. Interestingly, ‘team’ success is not explicitly classified. They propose that the holy grail of success is the intersection of:
Organisational Success: return on investment driven by revenue, cost savings, and other sources of value such as customer loyalty, brand , competitive differentiation, IP etc.
Personal Success: individual intrinsic motivations within a team; personal success for developers defined as an improved quality of life resulting from increased technical quality, greater influence over estimates and schedules and team autonomy.
Technical Success: a standard of excellence that meant your software wouldn’t eventually collapse under its own weight.
For an alternative view in The Age of Agile, Stephen Denning proposes that making money and corporate survival depend not merely on satisfying customers, but delighting them. Umair Haque expands on this in The New Capitalist Manifesto. He highlights that shared prosperity and success comes from offering a continuing supply of new value for customers and delivering it sooner. Fundamentally, it’s a shift from defining success as outputs to outcomes.
An output can be defined as being extrinsic. It’s a tangible thing, a product, service, profit, revenue, cost etc.
An outcome can be defined as being intrinsic. Specifically, it refers to the benefit your customers receive from your ‘things’. An outcome led approach starts with truly understanding your customers needs: their constraints, priorities, challenges and issues, desired behaviour changes and the difference your solution brings to their lives.
Customer Obsessed
Is this obsession with delighting your customer the yardstick of your own team’s success? If it is, are you clear on who your customer actually is? I ask because of a recent experience with a multinational customer where more than half of the software development teams using Umano couldn’t answer this question. Customers of software development teams can often be internal, or the organisation’s end user. Regardless, serving your customer in a way that alleviates some pain of theirs and amplifies a greater quality of life is the ultimate definition of team success, raison d’être and ‘Why’ you exist.
Take back responsibility for reframing your software development team success.
An organisation can consistently delight its customers if each individual team is focussed on that goal. This means that each team’s work goals must be defined in terms of customer outcomes, not merely outputs. Once the goal of each work team shifts to that of delighting customers, the definition of success for a team moves from “things delivered” to understanding “the quality of the customer experience”.
“What we have tried to do…is emancipate the heart of the engineer, which is to serve others. We engineers exist to produce something that the world will enjoy, something that will delight people. All of these things that we call Agile or lean, or any of the processes that have a name, that’s what they’re really about when they’re done well: How do we serve others?”
– Richard Sheridan, CEO-Menlo Innovations
So how do we make sure this continually remains our focus? Our customers depend on it. Our teams depend on it, and so too does our organisation.
Umano is on a mission to help self-directed teams succeed by providing real-time feedback with data-driven insights that help agile teams to continually improve and stay ahead.
Sign up here to access your complimentary Umano account and see how your team’s agile sprint practices are tracking.
Join our slack community to learn from others and be a part of the data-driven movement to improving team performance.