Personal notes from Jurgen Appelo’s “Agile Management 3.0” presentation at INRIA, France, on March 27th, 2012
Switch branches/tags
Nothing to show
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information. Added transcript. Mar 29, 2012

Agile Management Conference


Jurgen Appelo

  • @jurgenappelo

Upcoming conference in Barcelona, end of August, 2012.

Management 3.0


Agile does not remove the need for an actual management.


Agile is the middle ground between programming (chaos) and software engineering (order). It's acknowledging the complexity, between anarchy and bureaucracy.


Data from State of Agile '11 (VersionOne survey).

Barriers to Agile

From the VersionOne survey, the speaker draws the conclusion that most of the time, Agile failures derive from management.

Conversely, 77% of Agile tentatives are started by managers.

Management as a monster

Management methods are usually squares and rectangles. But management is about human beings, and does not fit peg holes.

The speaker presents his vision of management as a biological, 6-eyed “monster”.

Energize people

Motivation is key.

Effective: 2-years with 0 turnover after Scrum introduction.


  • Motivator cards: write down key motivators, ask team members to order them. Proves that management cares about motivation, and allows it to lead accordingly.
  • Happiness index: materialize happiness and the fact that management cares about it.
  • Bell: hang a bell in the office, ring it when there is something to celebrate.

Empower teams

7 levels of authority, from authoritative decisions to full delegation.

This concept frees the manager from the thought of delegation as a binary switch, either full control or full trust.

Artifact: delegation board, with pictures of responsible person(s), at the corresponding level of delegation.

Delegation | 0 | 1 | 2 …… | 7 |
   Area 1  |   |   | pic1 ……… |
   Area 2  |   |pic2| ……… |   |

Align constraints

Protect people: as a manager, sometimes you need to intervene when some team members don't work properly with others. Enforce human and technical guidelines.

Agile “values” are a small subset of all human virtues, and your team may have different ones. This is very important as a team building tool, especially to focus on missing values, not the ones that come naturally.


  • Virtues list, from which the team can select (voting, consensus…) its defining values.
  • Team identity: name, logo, mascotte, website… Leverages peer pressure via pride.
  • Goal setting with stories, pictures, video

Develop competence

Don't hesitate to bring in external (or bring in internal) coaching. Coach ≠ manager!

The role of the manager is to find out who needs coaching, and then to delegate it. It is not your role to coach.

Training and certification: a certificate does not mean anything, but it can play some role. Analogy with the driver license: licensing does not mean competency, and can actually be dangerous in the beginning, since it can lead them to believe they are competent.

Supervision / “patrol”: the simple presence of the manager is usually enough to trigger responsibility.

Grow structure

Main problem with most agile methods: scaling. What's valid for one combination of team/project/client may not be valid when you manage several ones.

Self-organized teams:

  • let the team organize itself…
  • …but give some constraints: skills diversity, team size…

Improve everything


  • “impediments door”, or improvement backlog: a list of all impediments, the “manager's backlog”, prioritized by the team.


Split a big organization and its hierarchy and teams as several independent organizations.

The other way around, for small organizations, projects flow through teams (5±2 persons). Team builing and team responsibility is more important than projects acquisition. The teams may then face different POs, as long as they don't fight over interleaving priorities.

Most important: at least one year with a stable team.

Performance measurement

First of all: what is performance? Income? Turnover? …

Measure from the perspective of the stakeholders: for a client, it could be cycle time (mean time from bug spotting to fix); balance with team members’ important metrics, suppliers’…

The metrics obsession is a view from Management 2.0: a dashboard of metrics that would give a “pilot” all information, so that he can drive the whole organization on his own.

Reference: Management 3.0, by Jurgen Appelo

Why 3.0? Beyond a selling argument:

  • 1.0: command and control, as if organizations were machines that could be driven.
  • 2.0: more recent, where management was extremely theorized… over a mechanical view of organizations.

Complexity thinking


Temptation: reductionism, modeling.

Many problems:

  • dehumanization;
  • objectivation (believe one can be objectively judge an organization);
  • alineation;
  • prediction (need for control);
  • attribution (blaming people for problems);

Opposite view: see the whole. But how far does the whole go? Where is the boundary?

“Thinking in Systems” (ref. book): the limits depend on the question one wants to answer.

“All models are wrong, some are useful” // “All models are useful, some fail earlier than others”.

Complex adaptive systems (CAS)

A software development team is a CAS, just like many other systems.

Complexity theory is about the dynamics of change in a system.

Complex ≠ complicated.


  • Diversity of models: complexity can not be answered with a single model, whether it is Scrum, or Kanban, or whatever. Multiple weak models are stronger than a stronger one, and applying a one-size-fits-all practice is not viable.
  • Feedback (metrics…) should be given to the whole team, not only to management (information radiation).


  • “360 degrees evaluation”: peer evaluation, since only the complex system can evaluate itself.
  • CHAMPFROGS (10 intrinsic motivations).
  • Coevolution and subjectivity: as wrote previously, the simple presence of the manager influences the behavior of others. Work closer to others.
  • FedEx day: learn a new skill (a technology, …), try to deliver something in 24h to present to others.


  • Ashby's law of requisite variety.

  • “All models are wrong, some are useful”.

  • Steven Reiss, “The 16 basic desires…”.

  • E.L. Deci and Richard

  • Drive: the Surprising truth, Daniel H. Pink.

Change 3.0

(parts of this session were included where relevant in the previous session transcript)




Should the answers for each group be planned or can they be JIT?

Agile ➝ adapt, JIT.

“listen to feedback” ⇒ How much do you accept to modify your offer to fit the majority?

Compromise, no answer here.


How to leverage peer pressure while at the same time integrating newcomers properly?

Let a properly self-organizing team choose its new members, and it will take care of integrating them correctly.