Pattern of the Month: Management by Exception

Agile practice is often contrasted with the traditional "Waterfall" model. Instead of passing work through stage-gates - such as analysis, design, implementation, and testing - Agile teams will deliver multiple small finished increments into production. Since empirical evidence of value will always be at hand, the "leap of faith" concerning a project can thus be reduced. Each increment will be a valuable feature which allows for experimentation and learning, the adaptation of a plan, and perhaps an early return on investment. An Agile product is built cumulatively so that things are allowed to evolve.

The roles, events, and artifacts of an "agile" organization, therefore, differ substantially from those of a more traditional Waterfall enterprise. So used are we to thinking in terms of this contrast, and of the differences in philosophy and mindset which distinguish the two approaches, that we might sometimes assume they share no common values at all. There is, however, one principle which traverses both stage-gated and Agile methods.

Any system of organized production must respect the tolerances within which its resources can be expected to operate. In a Waterfall environment, for example, an executive board is likely to delegate the day-to-day running of a project to a project manager. That manager will operate within agreed project tolerances of time, cost, risk, and scope. As long as those tolerances are not exceeded then he or she will be trusted by the board to take appropriate corrective action as necessary. If, however, the manager believes that those tolerances are likely to be exceeded then an exception will be raised, and the problem will be escalated to the board for consideration. It will be up to them to make a decision about what to do. The essential point is that they only become involved when necessary. This arrangement is known as Management by Exception.

The same principle of Management by Exception is implemented in Agile practice, although it is driven by the needs of teams doing the actual work, rather than the concerns of a management layer. At its most basic level, the members of a development team will operate within the parameters of professional respect and collaborative trust. They will be allowed to get on with their work without being micromanaged. If a team member believes that a risk, issue, or impediment has arisen which his or her peers ought to know about, then they will raise the matter accordingly. In lean practice, this exception is sometimes referred to as raising an andon flag. In agile software development, a team member may call an ad-hoc huddle, or scrum, in order to raise and resolve the matter, a pattern of behavior also known as a Swarm. Any team member may call a huddle or scrum for any reason at any time, and they will be trusted as professionals to do so with the appropriate discretion.

The team may further escalate an exception to a servant-leader such as a Scrum Master if they are unable to resolve matters in a timely manner or would otherwise lose focus. Note that in Scrum, if an impediment is such that a Sprint Goal is unlikely to be met, then an exception ought to be raised with the Product Owner. He or she may then make a value-based decision on whether or not to cancel the Sprint.

Management by Exception is Pattern of the Month at agilepatterns.org

Management by Exception

Intent: Delegate authority to act within specified tolerances, and only involve others if those tolerances are exceeded.

Proverbs:

• First, try and fix it yourself.

Also Known As:

• Escalation (especially in a line management context). Note that the term Management by Exception is sometimes used to describe fire-fighting.

Motivation: Localize responsibility, avoid micro-management and the unnecessary seeking of approval.

Structure: A workstream (such as a project) can only operate within certain tolerances. Tolerances might be constraints on time, cost, resource, quality, scope, or any other variable within a workstream’s environment. The conformance of a workstream to those tolerances is measurable by inspection. A manager (such as an Agile team member) will have the authority to inspect and adapt his or her workstream within the prescribed tolerances. If the tolerances are exceeded then an exception will be raised.

Applicability: Management by Exception is suitable for teams with clearly demarcated responsibilities, operational tolerances, or constraints.

Consequences: Management by Exception empowers parties to operate within certain tolerances. Raising an exception transfers responsibility and accountability to others should those tolerances be exceeded. However, it is usually most efficient to resolve problems as close to the source as possible. It is therefore important that the allocated tolerances do not unduly limit an Agile team’s freedom of operation.

Implementation: Agile projects usually exhibit tolerances on scope rather than time, cost, resource, or quality. Team empowerment is recognized in DSDM, Scrum, and XP. All support Management by Exception.

See Also:

• Inspect and Adapt

• What is Management by Exception?, by Steven Bragg

• What Management by Exception Really Means, by John Spacey