From the Agile Manifesto, we learn (via Principle #11) that “The best architectures, requirements, and designs emerge from self-organizing teams”. This sentiment is reflected in many of the other value statements and principles, including:
Value #1: Individuals and interactions over processes and tools
#5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
#8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
#9: Continuous attention to technical excellence and good design enhances agility.
These items did not simply appear one day in Feburary 2001. Rather they were codified from experiences that go back many years.
Even worse, few of these companies have an understanding of why! Yet, the answer is simple!
The increase does not happen magically because one starts to adopt Scrum or any of the other approachs that align with the Agile Manifesto. Nor is any random organization going the meet the goals of the team. This dichotomy of external goals and constraints [aka “the business”] and the concept of “self” organization has contibuted to the acceptance of the concepts. To have a chance at success the team first needs to understand the goals and constraints. This will provide a measuring stick for the team to evaluate any type of organizational decisions.
The second element of misconception is that the word “self” means “in isolation” or “without external input/guidance”. Nothing could be further from the truth. Rather the term refers to who has the responsibility and the ability to determine the organization – it is not arbitrarily imposed via a cnetralized command and control type structure. There must also be accountability. While there will certainly be alternatives attempted which do not yield the desired results, there must also be clear progress of the overall effort. If a team fails to arrive at an organizational level after an extented period, it may be necessary to disolve the team and begin with a frest start. Fortunately this level of drastic action is very rare.
Before we answer that question, a little diversion. When teams begin to adopt an iterative approach using Scrum or other Agile related means, it is almost universally accepted that there needs to be someone in the role of Scrum Master [well, you can’t do Scrum without one] or Agile Coach [not specifically required, but very helpful]. This role is dedicated to helping the team plan and deliver value in accordance with the priorities established by the Product Owner. If there was ever a perfect Scrum Team and a perfect Product Owner, then the Scrum Master would have nothing to do! Since we live in a less than ideal world, there is always plenty for this person to do, regardless of how good the product owner and team members are in this respect.
One will quickly notice that I did *not* include helping the team to organize in the above. This is quite deliberate as detailed organization of the team is highly technical in many respects, and the Role of Scrum Master or Agile Coach does not include this type of expertise (though the person fufilling the role, might). The depth of technology’s involvement in the organizational process often comes as a complete suprise and warrants further examination.
An in depth analysis of the interactions are far beyond this blog post. On a regular basis, I do consulting engagements with teams that range in duration from 1 week to 3 months to facilitate the development of a detailed organization that is consistent with highly effective use of the technology in place [or with new technology] to achieve the goals. Despite a high degree of commonality across thes environments, the details are as varied as the product types and team personalities are.
Using a hypothetical team that is developing a set of Business Applications in C# using Visual Studio 2013 and TFS 2013 as a basis and are following a generalize approach based on the tenets of Agile, here are some of the reoccuring elements:
..and these are just a few of the highlights. Every single one of the above items has a relationship and interaction with the organization of the team.
Clearly there are a number of items here where utilizing someone with deep experience in the respective and related areas would provide significant value compared to simple raw experimentation by the team members. For any given team it is likely that at least some of these have not even been on the Radar when thinking about the ramifications of different team organizations and interactions.
This leaves us with 3 key takeaways: