Showing posts with label Self-Organization. Show all posts
Showing posts with label Self-Organization. Show all posts

Saturday, June 20, 2009

Resources on Self-Organizing Teams for Agility

In the past several blog-entries I've been focusing on the agile principle of self-organization, what it means, and what it implies for teams. So far, I've written about Agile Self-Organization versus Lean Leadership, Self-Organization and Complexity, and Agile Self-Organizing Teams.

For some online resources (articles and presentations) on self-organization and self-organizing teams, I recommend the following:

I'll be taking a break on this topic (Self-Organization) for awhile, and then returning to it again later to talk about Swarm Behavior, Collective Intelligence, Social Creativity, Group Coherence, Group Decision-Making and Holocracy/Sociocracy.
Posted by Brad Appleton at 1:08 AM 0 comments
Labels: , ,

Tuesday, June 16, 2009

Agile Self-Organizing Teams

The previous blog-entry on self-organization was lots of jargon and technical mumbo jumbo that didn't say too much about what that means for teams of people. So let's shift from talking about self-organizing systems in complexity science to talking about how it applies to self-organizing teams in an agile context.

A self-organizing team is a team that is led and organized by it's members, to attain goals and objectives specified by management within the constraints of its environment:
  • Management can shape and "nudge" the team and its members, but management doesn't try to dictate the details of "what" the solution is nor the process of how to create it.
  • The team is responsible for not only leading and organizing itself to achieve its goals, but also to monitor and adapt its behavior to correct/improve its own performance.
  • This means the team can change how it leads and organizes itself in order to respond to feedback and constraints from its environment, which also implies that ...
  • There is no single central "leader" for the team over the lifetime of the team/project - the "leader" is not a static assignment, but rather a dynamic role
  • So the person(s) leading any given moment may change, depending on the particular decision, activity, or problem being addressed in any particular context/situation.

By themselves, self-organizing teams are neither "good" nor "bad." They simply "are." They require a supporting management environment (the "fitness landscape") and organizational culture that establishes, communicates, rewards and reinforces the "right" set of values and principles. Without supportive management and the proper leadership culture, there is a very high likelihood that a self-organizing team may be unable to create good results or effective processes (or both). In fact, it's not uncommon for a newly formed & "empowered" self-organizing team to fall into many of the same dysfunctional patterns of behavior that it was most trying to escape from within the "management" that only recently "empowered" the team.

An "agile team" is (supposed to be) a self-organizing team that is guided by the agile values and agile principles (given by the agile manifesto) and is supported by a trusting and empowering style of management. With management supporting their agile values/principles, Agile teams "self-organize" to collectively decide and do what is needed in order to: make and meet commitments, develop a quality product, respond to feedback, and adapt to changes.

So an Agile Self-Organizing Team is:
  • Autonomous: There is no single central decision-making authority. Control is distributed collectively to the team.

  • Adaptive: The team dynamically adjusts as needed across roles, functional specialties, and other boundaries, in order to solve their own problems and improve their own performance.

  • Accountable: The team collectively shares responsibility for results, and members hold each other accountable for outcomes.
Here are some choice quotes regarding self-organizing teams ...

“The team makes most decisions, while every member could step in and become leader in specific areas and situations. People are highly capable, committed and self-driven.”
—Andriy Solovey, What is the best leadership style for the software team?

“This causes a shift in the roles of managers from planning, controlling, directing, and managing to new roles like building trust, facilitating and supporting team decisions, expanding team capabilities, anticipating and influencing change.”
—Diana Larsen, Exploring Self-Organizing Software Development Teams

"Responsibility-Based Planning and Control: Respecting people means that teams are given general plans and reasonable goals and are trusted to self-organize to meet the goals. Respect means that instead of telling people what to do and how to do it, you develop a reflexive organization where people use their heads and figure this out for themselves."
—Mary Poppendieck, Implementing Lean Software Development

In Learning is the Bottleneck, Amr Elssamadisy & Deborah Hartmann write:
"Human psychology aspect adds that self-organized teams:
  • are more responsible for end results, self-disciplined and self-driven
  • avoid dependency on the formal leader qualities
  • motivated, initiative and willing to act
  • enjoy work more
  • better insured against groupthink, conformity and diffusion of responsibility
  • not shifting judgment and decisions to others, better in finding alternative and balancing options
  • every member is in charge, ready to step in as a leader and have incentive to develop leadership skills
A self-organized team is possible when people carry shared purpose, principles and values. They support and respect each other. And they want to succeed. The [Agile] team works together to respond to changes that happen together. They collectively do what needs to be done to build the software."

In his 2001 paper Agile Processes and Self-Organization Ken Schwaber wrote:
"Agile processes employ self-organizing teams to handle the complexity inherent in systems development projects. A team of individuals is formed. They organize themselves into a team in response to the pressure of a deadline, reminding me of the saying, "Nothing focuses the mind like a noose!" The pressure cooker of the deadline produces cooperation and creativity that otherwise is rare. This may seem inhumane, but compared with non-agile practices for dealing with complexity, self-organization is a breath of fresh air."

This is what Kevin Kelly wrote about that problem in his book Out of Control:
"When everything is connected to everything in a distributed network, everything happens at once. When everything happens at once, wide and fast moving problems simply route around any central authority. Therefore overall governance must arise from the most humble interdependent acts done locally in parallel, and not from a central command."

Roger Lewin wrote in Complexity: Life at the Edge of Chaos:
"Complexity science implies that CEOs and managers must give up control -- or rather, the illusion of control -- when they are trying to lead their organization to some goal. But they do need to create the environment in which creativity can emerge. The message of complexity science is not simply to stand back and wait for the right solutions to emerge. Too little control is just as misguided a business strategy as too much. Some structure is necessary. The degree and nature of control that CEOs establish in their companies strongly influences what emerges, in terms of culture, creativity, and adaptability."

Mishkin Berteig writes in Team Self-Organization:
"In agile teams, this concept of self-organization is taken quite far. Team members collaborate to get work done. No one orders a team or an individual to do specific work. The team members volunteer for work that they see needs doing, even if it is not something that is in their area of expertise. An agile team is constantly promoting learning in its people. Agile teams are also cross-functional so that the team can get work done without relying on external services. The team therefore represents a complete work unit capable of taking a function valuable to customers from start to finish, from idea to deployment."

In Why Agile Principles are Important, Simon Baker writes:
An experienced agile software development team is a highly social group that is self-organising around these principles and acts with coordination and collective behaviour. This collective behaviour comprises:

  • Collective mind where individual team members develop shared understandings of the team's tasks and of one another, and come to understand how their work contributes to the work of the team thereby facilitating team performance.

  • Swarm intelligence which gives a team the ability to adapt to changes, and robustness which enables them to still perform and deliver even when one or more members fail.

From Of ants and men: self-organized teams in human and insect organizations
To cope with today’s complex, fast-paced, and ever-changing business environment, companies need to shift their overall structure to produce adaptive, highly responsive organizations. The use of teams, particularly self-organized teams with their reactive, emergent properties, may be one way of achieving this goal.

In other words, insect societies often harness the power of self-organization such that with the appropriate set of feedbacks, interindividual interactions, and proximate mechanisms, group-level adaptive behavior simply emerges. No one directs the foragers where to find food, the network of trails and interactions takes care of that; individuals are not allocated to tasks, the reverse is true: the tasks allocate the workers.

McMillan-Parsons (1999) found that the teams fitted Stacey’s (1996) description of self-organizing groups or teams as ones that arise spontaneously around specific issues, communicate and cooperate about these issues, reach a consensus, and make a committed response to these issues. Further, ‘research suggested that self organizing teams have a strong sense of shared purpose, strong personal commitment, display creative and spontaneous behaviors, have high levels of energy and enthusiasm, and that an inherent order emerges from their activities’.

Importantly, in self-organizing teams the members self select and there is no-one checking to see if they have the necessary range of attributes. In her study, McMillan (1999) discovered that members of the self-organizing teams studied learned new skills and developed new attributes to meet the needs of the team.

One characteristic of such organizations is adhocracy. These large, mature yet high-performing companies manage to generate the flexible and adaptive properties of smaller entrepreneurial organizations—in short, to “be big and yet to act small at the same time”. Using teams is one key means of achieving that, for, as Flory (2002, p. 9) remarks, self-managed teams, ‘are fast moving, fast learning groups, flexible, highly autonomous and have a well-developed pro-active attitude and sense of responsibility. These characteristics are the very reason they are brought into life as answers for organizations to respond to a fast moving world.’


Self-managed Teams Self-organized Teams
Part of formal organization structure Not part of formal organization structure
Formal, temporary, or permanent Informal and temporary
Not spontaneously formed Formed spontaneously around issue(s)
Indirectly controlled by senior management Boundaries influenced by senior management
Managers decide ‘who’ and ‘what’ Team members decide ‘who’ and ‘what’
Replace the hierarchy Often in conflict with or constrained by the hierarchy
Empowered by senior management Empowered by the team’s members
Strongly shared culture Cultural differences provoke and constrain
Some sense of shared purpose Strong sense of shared purpose
Order created via recognized processes Inherent order emerges
Behaviors influenced by procedures and roles Spontaneous, creative behaviors
Strong sense of team commitment Strong sense of personal commitment
Some energy and enthusiasm High levels of energy and enthusiasm
Decision making is mainly a planned process Decision making is mainly a spontaneous process
At least one member’s primary role is organizational All members’ primary role relate to the task


In my next blog-entry I'll give links to several other resources on Self-Organizing Teams.
Posted by Brad Appleton at 12:16 AM 1 comments
Labels: ,

Sunday, June 14, 2009

Self-Organization and Complexity

In my previous blog-entry I talked a little about how self-organization is a key aspect of software agility. In this blog-entry I'd like to explore in more detail just what "self-organization" really means.

Self-organization comes from complexity science and the theory of complex adaptive systems (CAS). A system is "self-organizing" if, left to its own devices, it tends to become more organized over time. This is in stark contrast to the concept of entropy from the laws of thermodynamics whereby a closed system tends to move to a state of increasing disorder in the absence of outside influences.

In a complex adaptive system where self-organization occurs, we necessarily have an open system rather than a closed one. The theory goes that if a complex system possesses the necessary emergent properties in an appropriate fitness landscape, then the system will yield emergent behavior, exhibiting system-wide "patterns", that increases the "order" or organization in the system. Hence the system has become self-organizing as a result of this emergent behavior & structure.

Some of the emergent properties of self-organizing systems can include:
  • Autonomy,
  • Adaptability,
  • Decentralization,
  • Dynamic reconfiguration,
  • Positive & Negative Feedback
  • Cooperation & Information exchange
The theory of complex systems suggests that self-organized systems are:
  • better in selecting optimal state and local decisions
  • robust
  • effectively adapt to environment and use feedback loops
  • often come up with emergent and unexpected solutions
  • self-regulated and better cope with perturbations
According to James Highsmith,
“There's no hierarchy of command and control in a complex adaptive system. There's no planning or managing, but there's a constant re-organizing to find the best fit to the environment. The system is continually self-organizing through the process of emergence and feedback”

The Emergent Phenomena Research Group at Brywn Mawr says:
"In self-organizing systems, global order (i.e., complex aggregate structure/behavior) results (emerges) from the local behaviors of simple agents following simple rules specifying conditions under which those agents act (interact) in such a way that the results of the agents' actions are fed back as input to the operation of the rule system at some future time step. "

In The Science of Self-organization and Adaptivity, Francis Heylighen writes:
Self-organization is basically the spontaneous creation of a globally coherent pattern out of the local interactions between initially independent components. This collective order is organized in function of its own maintenance, and thus tends to resist perturbations. This robustness is achieved by distributed, redundant control so that damage can be restored by the remaining, undamaged sections. ...

Self-organizing systems are characterized by: distributed control (absence of centralized control), continual adaptation to a changing environment, emergent structure from local interaction, robustness/resiliency (able under change and can quickly repair, correct, adapt/adjust), non-linearity, feedback (both positive and negative), self-sufficiency and closure/coherence. ...

Organizational closure turns a collection of interacting elements into an individual, coherent whole. This whole has properties that arise out of its organization, and that cannot be reduced to the properties of its elements. Such properties are called emergent.

Every self-organizing system adapts to its environment; Systems may be called adaptive if they can adjust to such changes while keeping their organization as much as possible intact.

From Software Development is Complex Adaptive System. No Doubt
Emergence is the way complex systems and patterns arise out of a multiplicity of relatively simple interactions. Small actions of agents lead to unexpected emergent system behavior and it is impossible to predict system behavior based on the behavior of an individual agent. Small errors pile up and may cause huge problem.

There's no hierarchy of command and control in a complex adaptive system. There's no planning or managing, but there's a constant re-organizing to find the best fit to the environment. The system is continually self-organizing through the process of emergence and feedback.

A system in equilibrium does not have the internal dynamics that enables it to respond to the environment and will slowly (or quickly) die. A system in chaos stops functioning as a system. The most productive state to be in is at the edge of chaos where there is maximum variety and creativity, leading to new possibilities. A set of simple rules allows edge of chaos and powers creativity, flexibility and success.

And last but not least, from Conditions for Self-Organizing in Human Systems :
Self-organization is the spontaneous generation of order in a complex adaptive system. It is the process by which the internal dynamics of a system generate system-wide patterns. Some of the emergent patterns in a self-organizing system are coherent, and others are not. Coherence is a state of the system in which:
  • Meaning is shared among agents.
  • Internal tension is reduced.
  • Actions of agents and sub-systems are aligned with system-wide intentionality.
  • Patterns are repeated across scales and in different parts of the system.
  • A minimum amount of energy of the system is dissipated through internal interactions.
  • Parts of the system function in complementary ways.
System-wide patterns in which the parts are aligned and mutually reinforcing (coherent) are more stable than other self-organized patterns. Because of the mutually reinforcing dynamics of a coherent pattern, the effort required to change the pattern is greater than the effort to maintain it, so coherent patterns are more stable than incoherent ones. When the system reaches a state of coherence ... tensions within the system are reduced, and the available energy of the system is aligned and focused on system-wide behaviors, rather than diverse and disruptive behavior of individual agents or sub-system clusters. ...

In human systems, the process of self-organizing is particularly important. Teams, institutions, and communities include individuals or groups of individuals that function as agents in self-organizing. As the agents interact, patterns of behavior emerge over time.These patterns form and reform spontaneously and continually at multiple levels within the system. Individuals work together to form teams. Ethnic identity groups establish relationships and micro-cultures. Functional departments engage with each other to do the work of the organization. At all of these levels, agents interact naturally to form patterns of system-wide behavior. ...

The CDE model is a set of the three conditions for self-organizing of human systems: Container, significant Difference, and transforming Exchange. The path, rate, and outcomes of self-organizing processes are influenced by these three conditions, which are co-dependent such that the function of each of the conditions depends on the others in nonlinear interactions in the system. A change in any one of the conditions results in a change in the other two over time.

Also see the following:
In my next blog-entry I'll talk specifically about self-organizing teams. Some specific characteristics and/or results of self-organization that I'll be delving into more deeply in subsequent blog-entries are:
  • Swarm Behavior (a.k.a. Swarm Intelligence)
  • Collective Intelligence (a.k.a. Collective Mind)
  • Social Creativity
  • Group Coherence
Posted by Brad Appleton at 12:17 AM 0 comments
Labels: ,

Friday, June 12, 2009

Agile Self-Organization versus Lean Leadership

Getting back to the agility cycle ... recall that I started with the business agility cycle and used that to derive the software agility cycle. There isn't a great deal of difference between the first two steps of the business-agility cycle and the software-agility cycle, other than the fact that much of the former takes place at a higher-level of organizational management and strategy.

The biggest difference between the two cycles happens after those first two steps. In the business agility cycle we then decide-communicate-act, suggesting that it is the higher-ups who make and communicate the decisions and the lower-end of the organizational food chain (the "worker bees") that execute the organization's strategic solution.

If that seems a bit command-and-control, its because it is (a bit). It's also likely necessary in larger organizations where it is virtually impossible to avoid having 2 or more layers of management. There, the "communicate & act" steps are really the process of providing focus, and communicating objectives and constraints to the knowledge workers, and letting them apply principles of collaboration and self-organization to solve the problem (like in the software-agility cycle).

So the key difference between business-agility and software-agility is the extra emphasis of the latter on "the people factor" and on the notion of dynamic self-organization of knowledge-workers as empowered, self-organizing teams. This difference between agility at the business-level versus software-level is also the key difference between Lean-vs-Agile:
  1. Lean focuses more on flow whereas Agility focuses more on adapting to change (this is true of both software agility and business-agility). As it turns out, focusing on flow requires being able to adapt to change; and focusing on adaptiveness and responsiveness requires a focus on flow. So here, the end-results may be quite similar

  2. Agile software development emphasizes a very hands-off management style of not just trusting and empowering the team(s), but often to the extreme of basically saying "leave us alone and don't interfere" to management (and in return promising extreme transparency and frequent tangible end-results).

  3. Much of this is due to the fact that the scope of Agile development is limited to software projects and teams, whereas Lean is targeted at enterprise-wide scale across the whole value-stream.

That is not to say that Lean (or business-agility) don't emphasize trusting and empowering workers and teams (they do). But they don't have the underlying inherent attitude of "just trust us and stay out of the way." The "trust" often doesn't seem to extend as far in the other direction with Agile development (e.g. not trusting management direction to the same extent that management is asked to trust the team).

I think this stems from the fact that software agility started more at the grass-roots level, with developers and teams struggling to create good, quality software in the face of what was all too often a fundamentally broken management framework for the governance, visibility, and lifecycle of software development projects. Because they were working and trying to get support from the bottom-up, they needed to be shielded from and unshackled by all the dilbert-esque "pointy haired managers" and their big, bad governance framework with its "evil" waterfall lifecycle.

And in that context, the advice of "just get out of the way and trust us and we promise to deliver working software every 2-4 weeks" is actually a very effective strategy to employ. When management doesn't "get it", their attempts to steer, direct and intervene are often the equivalent of "friendly fire" (which, despite well intentions, still yields calamitous results.)

But Lean comes from a history of a much more enterprise-wide scope, often even using a top-down deployment strategy. So when it asks management to trust and empower workers and teams it expects the corresponding change in its leaders and their leadership-style, and for them to still play a strong, active and participative role with their projects and teams.

Agile teams often get a "bad rap" for having this isolationist attitude toward management. And sometimes that "rap" is warranted. But when the leadership "gets it" and understands and values the "new" paradigm of why+how agile works, and why+how the "old way" didn't, then it probably is time for the leadership to play a different, more active role while still trusting and empowering teams (and still enabling self-organization). This is the view that Lean takes toward management, and is a big part of why it is better received by management and is more broadly applicable for scaling agility "up" and "out" in larger enterprises.
Posted by Brad Appleton at 12:52 AM 9 comments
Labels: , , ,
Subscribe to: Posts (Atom)