Classification of Organizational Paradigms

Referring to my blog “Being Agile at Organizational scale”  I’d like to classify the various organizational paradigms.

I propose a two-dimensional matrix with the following axes:

  • Management focused (top-down) vs. Team focused (bottom-up)
  • Dependent (waterfall like) vs. Emergent (agile like)

In this matrix, a command-and-control culture was at the dependent-management edge.  Self-managed teams were at the team-emergent edge.

I’ve started to put the agile organizational pattern into this matrix:

  1. Autocratic (classical stereotype)
    Management focused,  top-down, waterfall-like thinking
  2. Radical Management
    Get rid of top-down communication, enabling self-organizing teams.
  3. Rightshifting
    Do the right thinks, get the best of classical vs. emergent elements. Management as enablers.
  4. Holacracy 
    Based on collective wisdom, dynamical management
  5. Management 3.0
    Requires management to understand emergence in complex systems
Classification of Organizational Paradigms

Diffusion of innovations

From Wikipedia http://en.wikipedia.org/wiki/Diffusion_of_innovations

Diffusion of Innovations is a theory that seeks to explain how, why, and at what rate new ideas and technology spread through cultures. Everett Rogers, a professor of rural sociology, popularized the theory in his 1962 book Diffusion of Innovations.

Diffusion of an innovation occurs through a five–step process:

1. Knowledge: In this stage the individual is first exposed to an innovation but lacks information about the innovation. During this stage of the process the individual has not been inspired to find more information about the innovation.

2. Persuasion: In this stage the individual is interested in the innovation and actively seeks information/detail about the innovation.

3. Decision: In this stage the individual takes the concept of the change and weighs the advantages/disadvantages of using the innovation and decides whether to adopt or reject the innovation. Due to the individualistic nature of this stage Rogers notes that it is the most difficult stage to acquire empirical evidence

4. Implementation: In this stage the individual employs the innovation to a varying degree depending on the situation. During this stage the individual determines the usefulness of the innovation and may search for further information about it.

5. Confirmation: Although the name of this stage may be misleading, in this stage the individual finalises his/her decision to continue using the innovation and may end up using it to its fullest potential.

The rate of adoption is defined as the relative speed with which members of a social system adopt an innovation.

Diffusion of innovations

Summary of the Agile Manifesto

The agile manifesto is about presence over past:

  1. Interactions/individuals are now – processes/tools originate from past decisions.
  2. Working software works now – comprehensive documentation is (mostly) out of date
  3. In customer collaboration you know his current requirement – a contract manifests past decisions
  4. A change is happening now – a plan is (mostly) out of date.
Summary of the Agile Manifesto

Being Agile at Organizational Scale

There are many books and posts about agile teams. Doing Scrum or Kanban is a state-of-the-art in software development. But, how does it scale in big organizations? How can agile methods cross department boarders?

I’ve found some answers on the web. In upcoming blogs I’ll go into more details.

Here’s my list of the methods with links to further reading:

Please give me some feedback, if I missed some relevant approaches.

Mirko Blüming

 

Being Agile at Organizational Scale

How the Agile Manifesto translates into Scrum

„Agile“ has evolved into a best practice for software development and has been described by the values described by the Agile manifesto(http://www.agilemanifesto.org/ ):

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

In the following Blog I’ll describe how these values translate into the Scrum artifacts. Scrum artifacts are underlined.

Individuals and interactions over processes and tools

In Scrum the team size and sprint length is limited, such that the team can manage their tasks on their own. From a project management point of view the teams works as a whole.

All necessary organization and rules originate from the interactions within the team. The team decides about responsibilities and will manage (external) disturbances collaboratively. The Scrum master helps the team to resolve impediments and assures the (self given) rules are obeyed.

Interactions are amplified by reducing the usage of tools. That’s why Scrum teams prefer Scrum boards with paper cards for task planning and tracking over than (electronic) tools.

Working software over comprehensive documentation

The second value reminds you that the first goal is to create working software that brings value to the customer. Since the subject of the documentation often changes faster than comprehensive documentation can be created too much documentation is just a waste of resources. Agile teams favor delivering software early and often (ideally using continuous integration) to ensure requirements can be validated.

However, documentation is important for further development and maintenance – the challenge is to find the right balance between the necessary documentation and the creation of paper that is never read again. The retrospective after each sprint helps to consider also long term consequences.

Customer collaboration over contract negotiation

The customer is represented by the Product Owner, a role define in Scrum. The product owner understands the customer and has profound business expertise. He is available to the team at any time such that interaction is the main source for alignments.

To avoid any kind of negotiation, the backlog (= open task list) is sorted by the product owner according to the customer priorities, so the customer gets always first what he needs most.

However, this requires a thoughtful and reliable product owner.

Responding to change over following a plan

In Scrum the development is done in sprints, i.e. time boxed. Each sprint is a kind of a small project with a planning, implementation, and review phase. After each sprint the team is re-aligned to the customer needs when they take the topmost items from the backlog.

As most of the project plans are outdated as soon as they are published, it’s just consistent to abolish traditional project plans – only the time of the next sprint is considered. This is counter to traditional project management goals of controlling change and keeping to a plan.

The burn down chart visualizes development speed and progress. In doing so unnecessary work is avoided and the risk of failure is controlled.

How the Agile Manifesto translates into Scrum