Software Development and Agile Thoughts from my mountain lair high above Denver, CO.

Monday, July 26, 2010

Autonomy. Mastery. Purpose.

Many thanks to Steve who helped out with this. I actually re-purposed our internal post for here and left out 99% of his work (no offense, just wanted this to be "my" post rather than posting your stuff Steve without permission...and I'm too lazy to ask ;-)

Here's my list of recommended best practices for the three different roles in scrum:

Scrum Master

Product Owner

Team Member

Yes that’s right. The lists are empty. Well, why is that you may wonder? Funny you should ask…

First of all "best practices", besides being a rather hollow business-speak term, are things that don't really work everywhere for complex pursuits like software development. Principles can help guide you, examples of what other people have tried might prove inspirational. But "best practices" as typically bandied about today are not really right for broad Scrum adoption in a corporate setting. Go ask any of the signatories of the original Agile Manifesto.

Standardization and one-size-fits-all mentality is a very command-and-control approach to applying Scrum and completely at odds to what it’s really trying to tell you. Most intelligent, thinking people (that is the kind we want working here, right?) don’t "own" things that are foisted upon them. They might tolerate them. We want people to own things. That’s how good stuffTM gets done.

Experimentation, discovery, retrospection and continuous improvement are at the heart of scrum.

Really we’re missing the point if we try and find and mandate best practices for Scrum within a large corporate environment.

So what should we be doing?

Again, funny you should ask...

In his book, Drive, Daniel H. Pink explains how intrinsic motivation is key when it comes to work with even the most rudimentary cognitive component. People are looking for three things: autonomy, mastery and purpose. Given what my company does (help bring novel drugs to market as quickly and safely as possible) we should not be short on purpose. We just set things up to afford people as much autonomy and opportunity for mastery as we can and we’re golden. There's no point writing more on that when instead you can watch this excellent presentation of the research behind this in the following short video.

If you’re sitting there wondering if you can spare the 10 minutes needed for this video just watch it. If you play any role in managing or influencing teams of people creating software, watch it. If you care about how to truly motivate them, watch it. If you still think that we should be adding more and more process and templates and documentation and best practices to “enforce” adoption of a “standardized” form of scrum, watch it.

We have to trust the teams to learn and grow, not dictate exactly how they will implement Scrum.

OK, if you really want a best practice for Scrum here is one: DON'T BE LATE TO THE DAILY SCRUM!