Learn more about Velocity Partners offshore software development company
Jeff Sutherland used to characterize gaining Scrum or agile maturity as a team reaching a high-performing (or hyperproductive) state. He shared stories around these teams on his blog and via conference presentations (see references). He’s making the point less today than he was a few years ago, but agile maturity and the inherent results, is still an interesting question.
One of Jeff’s colleagues in 2008-2010 timeframe was . Scott is an experienced agile coach. Here’s the intro to a blog post and paper that he developed in 2008:
Scott Downey, MySpace Agile Coach, has a way of bootstrapping Scrum teams to a high performing state in a company that is about 1/3 waterfall, 1/3 ScrumButt with project managers, and 1/3 pure Scrum with only Scrum roles. Scott consistently takes teams to 240% of the velocity of MySpace waterfall teams in an average of 2.9 days per team member where the team includes the ScrumMaster and Product Owner.
So I thought in this blog post it would be interesting to explore the notion of a high or hyper productive agile team. What does it look like? Is it the goal? Does pure productivity matter, and if so, what does delivery look like? Is it sustainable?
I’ll start with sharing three of my own indicators and then punt the ball to all of you.
3 of my own
Swarming
It’s so incredibly easy for agile teams to work on too many things at once. To focus on keeping individuals busy, for example making sure the developers are coding, rather than focusing on getting Features-Stories-Work…done. So instead of serially working and handing things off to different functions, you’ll get phenomenal throughput by swarming around the work and focusing on getting it “Done” as soon as you possibly can. The Kanban notion of a WIP limit (work in progress) reinforces this notion of multiple team members (with different skill-sets) combine on the work.
Stretching, trying new things, and occasionally…failing
Too many agile teams “play it safe”. I see teams all of the time who worry about their Sprint commitments in Sprint Planning sessions. They calculate hours and seconds and only commit when they feel it’s a safe bet that they can deliver the work. I’d much rather have then trust their team and their gut feel…and give it a go. It makes me smile when teams plan “stretch items” as part of their Sprints. It tells me they’re attempting to go “above and beyond” what they perceive as their capabilities and capacity. I like that. Sure, sometimes they fail to deliver. So, what? Often they exceed everyone’s expectations.
Courage
Courage is one of the or attributes. To me indications of it include: less filtering of communication, telling it like it is, and challenging each other as team members. A big part of this is humility—to show a willingness to say “I don’t know” or show a sense of vulnerability. Often it includes the ability to admit it when you need help and not waiting too long to ask for it. And courage extends beyond the team to organizational leadership who show the courage to trust and support their teams. It’s easy to “go along with the flow”. It’s hard to truly be part of a high-performance, self-directed team and to engage in your teams overall dynamics and continuous improvement efforts.
Now it’s your turn
I want to encourage comments where you share your own ideas as to what are the key ingredients to making a high/hyper performing agile team. Please consider a broad view that might encompass:
- Technical skills & practices
- Soft skills
- Behaviors
- Specific agile techniques or practices
- Tooling
And if you don’t have a pattern, but know what inhibits high-performance (an anti-pattern) then please share those as well. In fact, I often learn more from “what not to do” when I’m coaching.
Thanks for sharing with the community. Stay agile my friends,
Bob.