【Self-organization I】¶
Among many agile frameworks (Extreme Programming, Kan-ban, Lean, etc.), Scrum has become prevailing and dominant over the past decade. Many organizations from businesses to government agencies adopt scrum as they move away from traditional waterfall methodology to agile methodology. Some follow agile and scrum strictly and religiously, others mix it with waterfall in a hybrid attempting to reap the best of both worlds.
Ken Schwaber, one of the two co-developers of Scrum process, both among the 17 initial signatories of the Agile Manifesto, wrote in his book “Agile Project Management with Scrum”:
For Scrum to work, the team has to deeply and viscerally understand collective commitment and self-organization. Scrum’s theory, practices, and rules are easy to grasp intellectually. But until a group of individuals has made a collective commitment to deliver something tangible in a fixed amount of time, those individuals probably don’t get Scrum. When the team members stop acting as many and adopt and commit to a common purpose, the team becomes capable of self-organization and can quickly cut through complexity and produce actionable plans.”
This echos one of the 12 principles behind the agile manifesto:
The best architectures, requirements, and designs emerge from self-organizing teams. The key phrase here is “self-organization” as a noun or “self-organizing” as an adjective.
Even though many agile and Scrum practitioners are preaching “self-organization” and trying hard to improve the effectiveness of the scrum teams through self-organization, the results are mixed.
From many years of practicing agile and Scrum in both small scale and large scale information technology projects ranging from private to public sector, I witnessed teams struggle to form cohesion and to deliver the outcomes promised by Scrum. Many of the projects are short-term ranging from a few months to a year or so, by the time the team has gone through the forming, storming, and norming phase and you start seeing the light at the end of the tunnel, the project deadline is approaching which leaves little time for the performing phase. Much of the fruits from the initial team learning and development effort goes underutilized or even untapped.
This leads me to think about “self-organization”:
What exactly is “self-organization”?
Can a scrum team achieve self-organization?
If yes, how can the team achieve it?
If not, what are the impediments?
Can the team achieve some level of self-organization under some circumstances?