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

Prozess der integrativen Entscheidungsfindung (Kurzformat)

Es gibt verschiedene Formate für die Moderation von integrativer Entscheidungsfindung. Das folgende beschreibt den
„Kurzformat“-Prozess, der angewendet wird, wenn ein Mitglied des Kreises sowohl eine Spannung aufzulösen hat als
auch einen spezifischen Vorschlag anbieten kann als einen Ausgangspunkt für die Integration:
Vorstellung des Vorschlags: Der Vorschlagende nennt die aufzulösende Spannung und einen möglichen Vorschlag,
um diese zu addressieren. Klärungsfragen sind nur erlaubt zum Zwecke des Verständnisses dessen, was
vorgeschlagen wird. Diskussionen und Reaktionen werden vom Moderator [A.d.Ü: engl. ‚Facilitator’, für das es kein
passendes deutsches Äquivalent gibt] sofort abgeschnitten, insbesondere Reaktionen, die als Fragen getarnt sind
(z.B. „Meinst du nicht, dass uns das in Schwierigkeiten bringen wird?“)
Reaktions-Runde: Der Moderator fragt nacheinander jede Person nach einer schnellen Bauch-Reaktion in Bezug auf
den Vorschlag (z.B. „Klingt großartig“, „Ich mache mir wirklich Sorgen über X“, etc.) Diskussion oder Überkreuz-
Gespräche jeglicher Art werden vom Moderator rücksichtslos abgeschnitten – dies ist ein heiliger Raum für jede
Person, um ihre Reaktionen zu bemerken, mitzuteilen und sich von ihnen zu lösen, ohne um sich den möglichen Effekt
der Mitteilung sorgen zu müssen.
Verbessern oder Klären: Der Vorschlagende bekommt, nachdem er den Reaktionen zugehört hat, eine Gelegenheit
um jeglichen Aspekt seines Vorschlags, von dem er meint, dass er Klärung bedarf, zu klären oder den Vorschlag
basierend auf den Reaktionen in minimaler Weise zu verbessern (es sollten nur triviale Verbesserungen in dieser
Phase versucht werden, auch wenn bereits auf klare Mängel hingewiesen wurde). Diskussionen werden vom
Moderator abgeschnitten.
Einwands-Runde: Der Moderator fragt nacheinander jeder Person, ob sie irgendwelche Einwände gegen den
Vorschlag, so wie er formuliert wurde, sieht. Einwände werden kurz genannt ohne Diskussionen oder Fragen; der
Moderator listet alle Einwände auf der Tafel auf und schneidet jegliche Art von Diskussion in dieser Phase ab. Wenn
die Einwands-Runde ohne sich zeigende Einwände ausgeht ist die Entscheidung gefunden und der Prozess endet.
Integration: Wenn Einwände auftauchen, tritt die Gruppen am Ende der Einwandsrunde in einen offen Dialog ein, um
die Kernwahrheit jedes Einwands in einen verbesserten Vorschlag zu integrieren. Sobald sich ein verbesserter
Vorschlag zeigt, der funktionieren könnte, unterbricht der Moderator das Gespräch, nennt den verbesserten Vorschlag
und geht zurück zu einer Einwands-Runde.

 

Quelle:

http://www.ii-frankfurt.de/fileadmin/user_upload/images/DIA/Info-Material_Seminare/Leading_Edge_Organisation_-_Holacracy_2007-06__deutsch.pdf

Prozess der integrativen Entscheidungsfindung (Kurzformat)

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

Agent Oriented Programming Languages

Agent based programming is an interesting approach for simulation and modeling – look on articles about agent based modeling (ABM) – e.g. http://www.pnas.org/content/99/suppl.3/7280.full

There is also the agent oriented programming paradigm (AOP) – see Wikipedia http://en.wikipedia.org/wiki/Agent-oriented_programming.

Unfortunately, the list of AOP languages is long, most are proprietary, decommissioned, and it seems to me that there did still no main stream emerge:

  • 2APL / 3APL
  • AFAPL
  • Agent0
  • Agent Factory
  • Agent Sheet
  • Agent Speak
  • ASPECS
  • BRAHMS
  • Breve
  • Concurrent METATEM
  • CArtAgo
  • DigiHive
  • GOAL
  • Jack
  • Jade
  • Jadex
  • Janus Project
  • JIAC
  • NetLogo
  • StarLogo
  • Steve
  • SOAR
  • SPARK

That’s a lot – maybe you can help me to find even more.

Many of them are similar and implement a belief–desire–intention software model (BDI) – http://en.wikipedia.org/wiki/Belief-Desire-Intention_software_model

In some later Blog I’ll give some feedback on the languages I’ve tried myself.

Agent Oriented Programming Languages