English
Agile-Management-3.0-by-Jurgen-Appelo---Conference-transcript
文件大小：
unknow
资源说明：Personal notes from Jurgen Appelo’s “Agile Management 3.0” presentation at INRIA, France, on March 27th, 2012
Agile Management Conference
===========================
Speaker
-------
**Jurgen Appelo**
- noop.nl
- jurgenappelo.com
- @jurgenappelo
[Upcoming conference](http://ale2012.alenetwork.eu) in Barcelona, end of August, 2012.
Management 3.0
==============
Management
----------
Agile does not remove the need for an actual management.
Agile
-----
Agile is the middle ground between programming (chaos) and software engineering (order). It's acknowledging the complexity, between anarchy and bureaucracy.
Benefits
--------
Data from [State of Agile '11](www.versionone.com/state_of_agile_development_survey/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.
Artifacts:
- 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.
Artifacts:
- 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 ###
Artifacts:
- “impediments door”, or improvement backlog: a list of all impediments, the “manager's backlog”, prioritized by the team.
Scaling
-------
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
-------------------------------------------
http://www.management30.com
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
===================
Abstraction
-----------
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.
Methods
-------
- 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).
Artifacts
---------
- “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.
Research
--------
- 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)
Reference
---------
http://www.management30.com/how-to-change-the-world/
Questions
---------
3/interactions
--------------
**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.
4/identity
----------
**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.
本源码包内暂不包含可直接显示的源代码文件，请下载源码包。
