I’d like to follow-up on the „water in a bottle“ metaphor from the last post, as this metaphor also says a lot about self-organization in the context of Scrum. Many mistake self-organization to mean “The team can do whatever it wants”. However, this is most definitely not the case. Most obviously, the team needs to deliver a product that conforms to the stakeholders‘ needs. Also, a team will be expected to adhere to both written and unwritten rules within the organization, on a technical, organizational and cultural level. For example, the company might want to enforce certain coding standards across all teams to ensure a minimum level of quality and mutual intelligibility of the code between teams. Or the company could have certain rules for handling bug reports from the customer. In these cases, a team cannot simply change these rules with the excuse that they are supposed to be self-organizing.
Also, a Scrum team is obviously expected to follow the Scrum rules. The water in the water bottle metaphor can flow freely within the confines of the bottle, but no further. The walls of the bottle are hard limits, and when the bottle is poured out, while the single water molecules are not controlled directly, the water is not given a choice as to where it can flow.
This might sound very strict, but the Scrum rules are indeed strict rules. This surprises many who have heard about Scrum only through hearsay and who equate Scrum or agility in general with chaos. I always like to emphasize that Jeff Sutherland and Ken Schwaber come from a military background, and while I have no proof that this influenced the strictness of the Scrum rules, I like to claim that it did, just to drive the point home.
Of course, in the true spirit of shu ha ri, a highly mature and experienced team will eventually begin to tailor the rules of Scrum and to shape them in a way to adapt to their specific needs. However, this is really reserved for experienced teams with a deeply rooted agile mindset and a great culture of self-inspection and self-improvement. This is not a first step for a team, but it is essentially the „endgame“ of Scrum. These experienced teams can shape their own framework, but the majority of teams will have adhere to the Scrum rules. And while this does seem confining, there are processes which give even less freedom, as they attempt to plan each developer’s work down to what they are supposed to work on each single day. The Scrum rules are strict, but they give the developers a lot of freedom to organize their own work and to decide how best to deliver great software.