Self Organizing Teams – what does it really mean

Waterfall, CMMI, Agile, Scrum – it’s really all the same
February 22, 2017
Employees, Contractors, Consultants – Oh My!
February 22, 2017

Self Organizing Teams – what does it really mean

 

Where does the concdept of self-organizating teams come from?

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

Principles:
#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.

Unfortunately many companies fail to truely enable self organizing teams

Even worse, few of these companies have an understanding of why!  Yet, the answer is simple!

Entropy [gradual decline into disorder] is a natural state of affairs, to increase (or even maintain) the level of organization require energy and work.

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.

So what can the team do?

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:

  • Software Engineering Principles, Patterns and Practices
    • Ensuring designs follow SOLID principles
    • Adopting consistent design and implementation patterns
    • Working effectively in a concurrent environment
    • Hierarchical Testing to constrain Risk
    • Actively Managing Technical Debt
    • Automated Build, Release and Deployment
  • Work Planning and Execution
    • “Right size” User Stories [PBI’s]
    • Independence of User Stories whil conforming to DRY principles
    • Statistically Accurate Estimating
    • Detailed Task Decomposition
    • Root Cause Analytics
  • Effective Tool Utilization
    • Visual Studio Extensions
    • Git vs. TFVC
    • TFS/VSO Customizations & Plug-ins
    • Third Party Tools
  • Architecture & Design
    • Component Based [Package Management]
    • UI and Host agnosticism
    • Reusability
  • Interactions and Feedback
    • Rapid OODA loops
    • Team Internals [Pairing, Swarming, Mobbing]
    • External Communications

..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.

Conclusion

This leaves us with 3 key takeaways:

  1. The details of team organization are quite complex, and the difference between a highly effective organization and one that simply exists without specific investment is likely to be significant when viewed from an ROI or business perspective.
  2. The elements that influnce an effective organization are (at least in part) highly technical, so the initiative and responsibility must rest with the team and can not reasonably be mandated by management, the product owner, or even the Scrum Maters / Agile Coach.
  3. The vast majority of teams will benefit from leveaging external expertise specific to the domain of achieving an effective team organization.

Leave a Reply

Your email address will not be published. Required fields are marked *

FREE CONSULTATION
Loading...