I took a training class on Scrum a few weeks ago taught by Kert Peterson. I had used agile methodologies before and had a good understanding of the roles (product owner, scrummaster) and mechanics of agile (release planning, daily scrum meeting, etc) going into the class.  Anyone can get this by reading any of the popular books on Scrum and agile. What I really learned was the “Tao of Scrum.” As Kert said “Scrum is very easy to understand, and very hard to implement.”

One of the core components of Scrum is the concept of cross-functional self-organizing teams.  Ultimately, the team decides what needs to be done and who does what.  More importantly, the team is ultimately responsible for the entire project/product deliverable. I think here lies the hardest part of Scrum.

In a large organizations it is likely that disciplineary silos exists. With Product Management, Development, Quality Assurance, and Documentation all reporting into different managers. It’s easy to assign resources from these groups to a new Scrum team. It’s very hard to break down the preconceived notions of who does what on a self-organizing team. It is easy to get everyone to attend the daily scrum meeting, it’s much harder to get everyone to buy into the idea that they as group are responsible for the product. It’s much more likely that the team members will retreat and concentrate on their disciplinary silos.

When you assemble a Scrum team, I would ask the following questions. Will the developers help QA with testing? Will the QA members help write some documentation? Will the Product Manager help out with UI design? Creating a team where everyone is willing to help out with different tasks means they get the “Tao of Scrum.” Without this, attending the daily meeting doesn’t mean much.