Scrum* is arguably the most popular of the Agile methodologies. It seems to be popular because it is lightweight while being structured. However, it is designed to interface with and compensate for the structural issues inherent in most large organizations.
The end goal of all Agile methodologies is to ship the greatest amount of useful, high quality software at a sustainable pace.
Scrum assists with this in the following ways:
– The ‘locked room’ iteration reduces or prevents distractions so the team can focus on their work.
– Requiring stories to meet specific, defined criteria in order to be ‘Ready’ or ‘Done’ adds clarity and reduces time wasted in clarification
– Channeling all outside asks through the Product Owner reduces distractions for the rest of the team
– Having the team perform the estimates provides a sense of ownership
– Having subject matter experts on all relevant subjects and from all relevant departments in the organization reduces the amount of time the team spends waiting for clarification
– Daily standups
There are more, but I think you get the point. Scrum is all about reducing distractions and time spent obtaining clarifications. Scrum also uses the crutch of iterations of a defined length to help reduce distractions from the rest of the organization, to help outside stakeholders get used to the idea that creating software takes time, but more importantly, to get outside stakeholders used to the idea that context switching takes time and has a cost.
I call the defined iteration a crutch, because there is another Agile methodology which does not have fixed iterations. I’m talking about Kanban, which is very similar (at least in my experience) to what I described above for Scrum, except that instead of Scrum’s timeboxing tasks to two weeks, Kanban focuses on enforcing a limit on the amount of work in progress.
For teams outside of operations and firefighting**, this requires more trust between the team and the organization, and likely a much more persuasive Product Owner to interface and control the conversation with the rest of the company.
But requiring a Product Owner to do this interface still feels like a crutch. What if everyone in the organization just knew what to do, and you didn’t need to separate out wrangling over priorities in order to stop distracting programmers?
Valve seems to be doing this:
http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf
Their ethos is that they once a person has gotten through their very intensive hiring process, they are empowered to make all the decisions required to ship products. They seem to have found a way to gain the benefits of Agile without all of the crutches of the methodologies above.
We will explore more of this, and some possible steps in a future post.
Comments and topic suggestions below!
*In all of this, I am making the assumption that the team is running Scrum by the book. There are numerous obstacles to this which are outside the scope.
**Many operations and firefighting teams naturally gravitate more towards a Kanban approach than a Scrum approach, as they tend to have more volatility in their tasks, and possibly smaller tasks are required to make outside-world-visible results.