Self-organisation without self-regulation, a recipe for chaos

This post is from the series of posts on Self-Organisation.

First time I experienced an Agile lego game it was playing the Leadership game: we had been asked to form 3 teams and then we had been given a goal to pursue. We worked in time-boxed iterations, and at the end of each iteration we reflected how to become more effective, even with the freedom to move to another team if that could be more useful.

In other words we had been asked to Self-Regulate: team members have early and frequent feedback in order to perceive the connection between actions and the consequences and based on that react and adapt their behaviour and their actions as needed to reach the desired goal.

Self-Regulation is a required element for a well functioning self-organisation. Indeed one of the principles of the Agile Manifesto state:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Lean principle Amplify learning suggests to increase feedback via short feedback sessions to support the continuous improvement, to better understand customers and project's needs, to learn how to better satisfy those needs and so adjust efforts for future improvements accordingly. Kanban is a Lean tool that helps here in many ways.

Why it’s  important to reflect, as individual and as team, at regular intervals?
This is because when our actions have consequences beyond our learning horizon, it becomes impossible to learn from direct experience.

What it means to become more effective?
For a team it means for example getting better in 
  • Completing team projects (i.e. quantity, rate and quality of the outcomes)
  • Fulfilling member needs (i.e. rewardingness from membership or from a member, commitment from members and to members)
  • Processing information and generating meaning (i.e. contribution of information from members, proportion of information held in common or uniquely by single member, proportion of information relevant to the tasks or socio-emotional)
  • Managing conflict and developing consensus (i.e. distribution between task and procedure and interpersonal conflict, expressed versus unexpressed conflict, escalation and de-escalation dynamic, level of implicit and explicit consensus)
  • Maintaining the structure and integrity of the team as a system (i.e. team social and task cohesiveness, patterns of interaction, of influence, of participation and of affect)
  • Motivating, regulating and coordinating member behavior (i.e. behavioral coordination about team norms and about errors and its speed/delay of the feedback)

Managing without impeding self-organisation

From the series of posts on Self-Organisation.

I used to play football and basketball with friends every now and then in the afternoons after school. We formed 2 teams with the
same size and with players filling the basic roles required for the game.

We were free to self-organise guided and constrained by the teams size and roles. Teams size and roles defined our 

This excerpt from Joseph Pelrine training material describes 

They define the edges of the system, who is in and who is out. By changing the barriers of the system, who is included and who is not, you change the dynamics in the system. In a sense, a boundary is the opposite of an attractor – people will shy away from it. “Barriers” is a more appropriate term than “boundaries”

Boundaries and barriers can be rigid or elastic, and the elastic ones are more resilient.  They are useful when:
1) They are good, beneficial, fit for purpose
2) The team is capable to benefit from them

Boundaries and barriers can be set by an agile manager or a coach. And also originate from external factors such as company strategic direction, company policies, budget, technology, partners, clients, and project goals and priorities. An agile manager and a coach can set and tweak and visualize boundaries and barriers to guide and safeguard the team:

to direct and influence the emergence of behaviors toward positive directions, 
to amplify the emergence of beneficial behaviors and to reduce or revert the non beneficial ones.

So managers can influence the outcomes without micro-managing and without impeding self-organisation.

Let people self-organise

From the series of posts on Self-Organisation.

When you have attended a workshop, training or other events that involve group activities you probably have heard something like:

now form two groups/teams and then ...

In this sentence there is the 1st prerequisite to self-organisation: let people do it.
It start with a purpose: some work that needs to be done.

A principle of the Agile Manifesto states:

The best architectures, requirements, and designs emerge from self-organizing teams.

Another principle from the same manifesto states:

Build projects around motivated individuals.
Give them the environment and support they need, and trust them to get the job done.

While it seems easy to let people do it, in some organisations and for some managers that can be a challenge.

The traditional organisation of work put a clear distinction between who is responsible and who is accountable. It require a distinction between who designs the solution, who implements it and who tests it. Some managers are expected to plan, assign and monitor the execution of  every single task. 
This approach let those who implement the solution without authority, with limited information and with limited possibilities of cross-functional collaboration. These are obstacles for self-organisation.
Scientific studies and experiments [1] show that for complex challenges a different organisation of work, where self-organisation can happen, is more effective.  

Some managers assume that workers dislike work and will avoid it when possible, and prefer to be directed to avoid responsibilities
In some cases this can be the result of poor recruiting. In other cases this is just a preconceived perception [2].  

To conclude, let people do it means that
  • the organisation is dealing with challenges that benefit from a different organisation of work where self-organisation can happen
  • recruiting select individuals that like their careers and are willing to take part in responsibilities
  • managers have ways to manage the team and influence the outcome without impeding self-organisation
The last point will be developed in the next post about boundaries and barriers.
[1] The Agility Advantage, David S. Alberts.
[2] Theory X and Theory Y.

Motivations and prerequisites for self-organisation

During this 
information age some projects can face higher levels of inherent complexity. 
As ambiguity, uncertainties and unknowns increase, our ability to predict is diminished, no matter how good you are and how hard you work.
Change can be faster and sometimes viral, levels of interdependence can be higher and available information can be incomplete and fragmented.

Working practices, people skills and expertise, tools and work organisation must all adapt to and fit specific project needs. Cross-functional 
self-organising crews and teams that work together from "concept to cash" have a higher capability to absorb and deal with more complexity, can respond to change faster and better, are more resilient to failure and misfortune, can organically grow and scale and naturally encourage shared commitment and cooperation of motivated individuals toward a common purpose.

It is common to see teams that are not allowed to self-organise at all, while other teams self-organize in total anarchy. 
The challenge is a self-organisation that works. And that requires the discipline of well-functioning self-regulation and useful barriers.

The following points are 
3 fundamental prerequisites for a team's self-organisation:

1 - Empowerment: Let people do it
2 - Boundaries and barriers
3 - Discipline of Self-Regulation

I will go into more details in the next posts on these prerequisites.

See Also:

- On Understanding Software Agility - A Social Complexity Point Of View by Joseph Pelrine, Europe’s leading expert on Agile software development. 
- Adaptive Software Development: A Collaborative Approach to Managing Complex Systems by Jim Highsmith, executive consultant at ThoughtWorks and coauthor of the Agile Manifesto.

The 5th value of the Manifesto for Agile Software Development

There is one more important value in addition to the other 4 values of the Manifesto for Agile Software Development and its evolution:

Critical thinking and independent judgment over the cult of personality and cult leaders

It promotes scientific skepticism over cargo-cults. It promotes a pragmatic and contextual approach and plurality over simplified and absolute truths and orthodoxy.

Can you spot dysfunctions in IT and in the Lean and Agile community that this value can help to mitigate?

Professional software development between science, sound experience and beliefs

Is Computer Science a science that can currently support software development's decisions in the day-to-day work?

Is sound experience enough to take decisions in software development?

This is what I discovered from the reading list about the current state in:
- Computer Science, research and academia
- Professional Software Development and IT industry

And the following are my
- Conclusions

The 6 forgotten design principles & Conway’s Law

Component and services enable reuse and encapsulation of responsibilities and implementation details.
They come into play when a monolithic application and a monolithic code-base is not enough anymore.

These are the 6 forgot OO design principles about packaging cohesion & coupling that suggest criteria to group classes and responsibilities in components and services :
REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release.
CCP The Common Closure Principle Classes that change together are packaged together.
CRP The Common Reuse Principle Classes that are used together are packaged together.
ADP The Acyclic Dependencies Principle The dependency graph of packages must have no cycles.
The Stable Dependencies Principle Depend in the direction of stability.
SAP The Stable Abstractions Principle Abstractness increases with stability.

When the code-base grows massively and so the number of people that work at the code-base, another principle that comes in to play is the Conway’s Law: 

 organizations which design systems . . .
  are constrained to produce designs
  which are copies of the communication structures
  of these organizations.

The Conway’s Law puts in relation the components and services and the structure of teams that work at different components and services.

There are 2 well known and very different examples of putting in practices the OO principles and the Conway’s Law in order to deal with big code-bases and large teams.
One is the trunk based development used by Google and the other are the 1-pizza teams used by Amazon where every component and service is assigned to one small team.

It's important not to get confused: in both cases we are talking about  cross-functional teams  that take care of the implementation of business features. We are not talking about components teams (i.e. front-end teams, business logic teams and data-base teams) or any other types of specialized silos-like teams.


[ITA] Edward Snowden: l'informatore dietro le rivelazioni sulla sorveglianza della NSA

Segue la traduzione in italiano del articolo pubblicato online dal Guardian la sera del 9 Giugno. Essendo un argomento importante che riguarda tutti gli utenti Italiani di Internet e dei servizi internet di aziende Americane (Google, YouTube, Microsoft, Skype, Apple, Yahoo!, Facebook) lo ho tradotto. (Clicca sul titolo per continuare a leggere).

Let's Self-Organise: the prerequisites for real self-organisation

It is common to see teams that are not allowed to self-organise, and few other teams that do it in total anarchy.

The challenge is a self-organisation that works. And that requires also a well functioning self-regulation and useful barriers.

Here follow the 3 fundamental prerequisites for teams self-organisation:

1 - Let people do it
2 - Self-Regulate
3 - Boundaries and barriers

And here are the remaining prerequisites.

Dealing with uncertainty, unknowns, risks and change

More traditional approaches to projects management, products development and software development life cycle management focus on what is

known & knowable

Everyone have different innate abilities and preferences among

reflection and planning Vs reaction and adaptation 

and different levels of tolerance to

 uncertainties, risk and change
while what matter is a balance and a tolerance that is good for the specific project/product and context.
What practices and skills are useful to deal with unknowns, how much risk and uncertainty is convenient for each specific product/project, what is a good balance between planning and reaction/adaptation in each specific context ?