August 26, 2006 – Power of Self Directed Teams
About 18 months ago, we adopted a self-directed process called Scrum in part of our development team – the part that focuses on end user applications. Most of the team was a little apprehensive, but they are solid folks and they put it in action.Â
Â
Recently, we made the move to transition the whole team to Scrum, something I should have done long ago. Initially, I believed that complex pieces of server-side software had longer life cycles, longer testing cycles, and therefore perhaps the Scrum process wasn’t a good fit. I was wrong. What we could have seen are the same benefits on the server-side that we’ve seen on the client. So, now we are rolling it out team-wide. So what are some of those benefits?
The most important benefit is the placing of ownership where it needs to be – at the team level and ultimately at the individual level. Whether they are taking a turn at Scrum Master, or just part of the team, each person owns reporting on their progress, the whole team owns the sprint backlog delivery, and has the power to say no to things not in the Sprint.
Team planning and ownership of the deliverable by the team – each Sprint (we use a month), the team signs up to a number of developer days, test days, and Tech writing days available. We estimate the line items in the backlog and allocate the available days. Its all team driven, and as such, the team owns the plan for the Sprint delivery. In addition, the team demonstrates the deliverable from last Sprint – a powerful way for them to show accomplishments.
Peer-to-peer accountability – another significant benefit. With Scrum, there is no place to hide from missed deliverables, poor quality, and lack of skill. Any team member can take any item of the backlog and work on any piece of the system. As such, Scrum breaks down artificial barriers. And, with daily scrum meetings on what was accomplished and planned for each day, it is pretty easy to tell if someone isn’t pulling their weight.
Forcing the business to define priorities – Scrum forces a booked plan, reconciled to business priorities at the beginning of each Sprint, monthly for us. It provides a systematic way to pull in all the business inputs (sales, marketing, support, et al) into the planning process – and enforces that this is there only chance to get input into the development cycle until next Sprint. (Not really of course, but it does force the conversation.)