So, I’m reading Agile Software Development with Scrum and it just struck me that what they’re really describing here is how to build high performance teams.

Of course, this shouldn’t be such a surprise. Aren’t high performing teams going to be the goal of any development process? But, still, it struck me as refreshing. I’m so used to processes describing all the details of development – how to document requirements and model designs and test the code. But here, so simple, the process is instead about how to enable teams to be in a position where the team can determine the best methods for these things. The focus, for a change, is not on the technical aspects – that side of things that we all know is really the easiest part – but instead on the people and management aspects – you know, the really hard part.

I’m not very far into the book yet, so it’s possible that all of those technical details come later. But, I kind of don’t think so. I did get so far as to read this:

And I think this essence sounds an awful lot like the the recipe for creating those elusive high performance teams that we all want to be a part of. Let’s see, here’s what I took away:

• Provide clear goals (Sprint Backlog)
• Actively remove all distractions, impediments, and obstacles from the team (Scrum Master)
• Enable the team to focus on meeting these goals in the way they see fit (self-organizing, fully autonomous, cross-functional teams)
• Frequent team communication to develop a shared understanding as well as facilitating a little healthy peer pressure/competition (Daily Scrums)
• Quick and frequent wins (Executable Product Increments at the end of each Sprint)

Yep, sounds like the characteristics of every high performing team that I’ve ever been on. Who’d have thunk? A software process that sounds rewarding to us hax0rs…