Management by Exception

A core idea of Agile is to build good teams and trust them. This implies a change which is hard for hierarchical organisations to adopt - do not hold decision-making and responsibility at a central point.

Like many things we use in agile, Management by Exception has a long and respected history. The first book about this approach was written in 1942 and it is mentioned within current (Prince2) project management approaches.

The basic idea is simple - managers should only need to be aware of things which impact their effective management and which requires some action from them. Everything else is detail which they do not need to know about. They must trust the teams to raise any issues that need senior management input.

In practice that is a big change for hierarchical organisations and hard to achieve - mostly due to the changes in mindset, power, responsibility and control within an organisation. These changes are essential to making this work properly but take time to achieve. It almost always involves redefining (and sometime eliminating) roles.

{{pics of communication and decision models}}

There are many people affected by delivering work - the teams doing it, the partners involved in delivery, the stakeholders who are impacted and the senior management with overall responsibility. All these people need to be informed about what is going on, but they do not (and should not) need to know all the details. A key point here is to identify all the different audiences involved in the work, what they need to know (and the way in which they need to know it) and any implications or impact it has for them. This also helps each audience identify any actions they need to take, while reducing the overhead of unnecessary communication.

Being agile, we encourage openness and visibility of everything. That is not the same as sharing everything with everyone. Giving people access to all information at all levels (from corporate goals to what an individual or team is working on today) is a desirable openeness, but if everyone had to look at all that information all the time, then they would be overwhelmed. Instead, we make that information avaiable, but use exceptions to inform different audiences about what they need to know. Everything should be available, about you should not be looking at it unless there is a need. Exceptions tell you what you need to look at.

Key ideas for senior managers

At the senior level, most people have a small number of very simple questions:

• Will I get the thing I requested?
• Will I get it on time?
• If not, why not and is there something I can do do fix the problem?

That is pretty much it. Does not look hard on the surface. As long as there are factual and honest answers to these questions then everything works very smoothly. Unfortunately, in hierarchical organisations there are multiple layers of people who are neither senior managers nor solution deliverers and have reasons why the message they give to senior management might not accurately reflect reality. Additionally, this requires devolving decision-making (and responsibility) to teams and individuals. That does not happen overnight - everyone has to change the way that they think and work to make this effective.

Here are some key things we need to get right:

• Trust - build good teams and trust them to do their stuff and also to raise issues with you if there are problems. That is not instant and is not an easy process. Building trust takes time and effort. If everone is moving to a less hierarchical model then there is a lot for everyone to learn
• Empowerment - enabling everyone, at all levels, to make decisions (and take responsibility for them) is essential to effective agile. You cannot just tell people they are empowered - it is necessary to explain what this means, educate people as appropriate and really live by that approach
• Clear Ways of working - Clearly define ways of working for individuals and teams in an accessible format. Big flowcharts hiddent away in a corner are not a solution to this. Define ways of working in a clear way and expect them to be updated (by almost everyone) over time. This makes sure everyone knows what they can expect from everyone else. Specifically, for management by exception, we need to be clear about when an individual or team cannot deal with an issue by themselves and need to request help from others. We also need to clearly define how people ask for assistance and how it is handled. Making this clear is central to making Management by Exception work well. If everyone understands and follows the processes for managing exceptions then we can trust the process without having to know all the individuals involved
• Good communication - This applies generally to agile, but with Management by Exception there are some specific things. While all detail should be available (see next point), ensuring people are aware of exceptions and changes that might impact them helps people to focus on what matters and avoid being overloaded or swamped by the available information
• Ability to dive into detail - People do not need to know everything. They do need to have clear access to the 'headlines' on things that affect/impact them. They then need the facility to find out more detailed information that is relevant to the exception that has been raised. This enables them to make decisions in an informed way based on actual data

Key ideas for solution deliverers

If we put senior managers at the top of the organisational hierarchy, then 'solution deliverers' are at the other end - doing the hands-on work which results in effective improvement and interacting closely with the consumers of the product.

There are some important changes for being a solution developer in the Agile world. Most people need some re-education and training. There are some (only a tiny number in my experience) who will never be able to work in an Agile way (even with training). It is most effective to relocate them to less agile roles.

These are some major changes in thinking for solution delivers: >/p>

• Not my problem - There is no such thing. You have your own specific area and responsibilities, but there is also a responsibility to the overall effective delivery of an appropriate solution. Awareness of what other people do, how it relates to you and how it relates to the overall solution is essential. You can (and should) help others resolve any problems they have and help to decide when exceptions need to be raised because something is not resolvable at this level
• I did what I was told - As part of responsibility for your work, it is important to look at the work itself. 'I did what I was told' is not an escape clause. You should check what it is you are being asked to do an ensure that you agree that it has value and fits with delivering the overall solution. 'Pushing back' on work you believe to be inappropriate is an essential part of your responsibilities
• Ownership of your work - The work you do is your responsibility - including managing progress and things which impede that progress. You have a responsibility to agree/accept that work, deliver it, recognise impediments to deliver and raise any issues with the appropriate people at the appropriate level
• Ownership of product - Not quite the same as owning your work. This is about understanding the overall objectives/values by which the organisation and team are working, and keeping an eye on these things. If you think there is something counter-productive going on then it needs to be raised through the appropriate mechanisms
• Understanding the big picture - To do any of the above, you need to understand the big picture of where things are going and why. Part of your role is to maintain your understanding of this big picture. The tools make it easier but part of your role is to keep uo to date with what that big picture is. This enables you to fulfil your role (inlcuding all the points above). The organisation should ensure that this is clear and available. You should raise issues if thatbig picture is not visible or clear to you, sine it prevents you making well informed decisions
• Knowing when to raise exceptions - For all the above, you first identify an issue, try to resolve it, and then raise it according to the ways of working (normally with your team first, then a team ageeement to raise an exception). This is an essential skill