Structure and Self-organization

credit to: https://www.coindesk.com/succeed-as-decentralized-autonomous-organization/

 

TL;DR

All systems are open

Self-organization is the behavior shown to best respond to change in an open system

Flexible structures that support empiricism and self-determination theory enhance self-organization

A co-worker recently offered a thoughtful rebuttal to Harrison Owen’s Dancing with Shiva video. If I understood him correctly, the essence of it was this: structure and roles are very important in a complex system to avoid chaotic decisions. Not only do I agree with him, but his point illustrates why Scrum is so darn useful to us who are building software.

Scrum Structure

Scrum defines events, rules, artifacts and roles. It is, “…a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” The self-organization of the Development team is focused by those elements of structure. Basically, bring a group of people together who have all the skills to solve a problem, give them the feedback loops they need to understand the problem and test solutions then get out of their way :). It’s also essential they have what they need to be a wise crowd.

The purpose of the Development team self-organizing is threefold as I see it.

Effectiveness

Given the right information and objectives, a cross-functional, self-organizing team has the best chance of coming up with astonishingly innovative and valuable solutions to even the most difficult problems. Free from being directed to produce specific solutions, the team may bring the force of it’s creative power to bear upon the problem. This is particularly powerful since the Development team is not separated from the work being done and reduces the possibility that their inspection of the work and adaptation in the face of it will be distorted by additional, communication channels.

Efficiency

Free from unnecessary structural concerns or dependencies, the Development team is freed to work in ways that best produce the intended result. This echoes back to the Toyota manufacturing system which established managers as helpers and expected the line workers to provide the guidance of how the work should best be done and improved.

Driven Behavior

Based in well proven “self-determination theory” Dan Pink’s book Drive poignantly illustrates that people are driven by the pursuit of mastery (competence), the desire for autonomy and the pursuit of an important purpose (connectedness). In short, Scrum gets self-determination right. Some might point out that the separation of Product Ownership from development represents a weaker form of self-determination where the worker is not in control of her work. Fortunately, Scrum mandates no such separation. It is quite possible that a Development team member could assume both roles or even that the responsibilities of the Product Owner could rotate amongst the Development team. Scrum only mandates that the Product Owner be a single person, not a committee at any given point in time.

Caution:

Rotating the PO role adds more variation into the experiment that is each Sprint. This is an advanced behavior you should only attempt if your Scrum team and organization has shown a high degree of readiness for such advanced behaviors and has a strong behavior of inspection and adaptation.

The Challenge

Perhaps the most challenging notion in what Owen shares is the statement, “All systems are Open.” Here he is referring to open systems theory. Stated simply it is the notion that an open system is one that has external interactions. In the social sciences, a system that, “…that exchanges material, energy, people, capital and information with it’s environment.” If this is the case, then the open system is exposed to innumerable forces that might throw it into chaos. Owen would tell us that limiting the structure’s capacity to absorb and react to that change makes it brittler and more likely to go “poof.” In contrast, if that system is structured such that it can easily see the chaos, examine it and change to harness that energy it will be better off. In Scrum these actions form the 3 pillars of empirical process control: transparency, inspection, and adaptation.

Maybe the most challenging part of this notion is admitting we can’t understand and therefore control everything. Our own psychologies tend to lurch and rebel at this notion. It isn’t safe and it isn’t comfortable. Even in the face of impending chaos it still may strike us as more comfortable to believe we can predict and control the tidal wave approaching. Owen would say to us, don’t try to control the wave, ride it.

Alternatives?

Many agree or suspect that the traditional organization structures going away or having to adapt to modern, more open systems. Increasingly, more are experimenting with different types of structures. Famously Valve has no managers, Care Evolution has a “CEO” who’s title is “I’m not your boss,” and Zappos has embraced a holacracy. While these may sound good they are not without their own challenges and should not be viewed as panacea. You’ll read about the trouble they’re having if you look them up on Google. I would challenge you to note the troubles you are having in your own, more structured organization. Would you trade yours for theirs? Whatever they appear to be to us on the outside, they are indeed grand experiments that bank on the premises of self-organization, self-management and self-determination.

On a different level is this notion of a teal organization. It’s the observation that organizations can develop to the point they are ready to accept the benefits  and combine elements of all types of organizational structure and behavior. Read up on the other colors, red, amber, orange and green to get a sense of how different organizational paradigms operate.

Have you found another way that works better? What’s working for you?

 

jknight

Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.