For the purposes of this article I will refer to managers with an agile mindset as “agile manager”. In doing so, I am using this term interchangeably to refer to Scrum Master, Product Owner or Agile Line Manager. The actual position that applies depends on the specific context in that moment. It may be the team’s agile process manager (Scrum Master), the team’s agile product manager (Product Owner) or the individual’s agile disciplinary manager (Agile Line Manager).
Self-organization and levels of delegation
In combination with agility the paradigm of “self-organization” is referred to very often. However, what does this mean? What does it have to do with trust and control? First of all, trust is needed whenever I give control to others and am not sure about the outcome. When I know exactly what will happen, I do not need to trust people. So, trust has something to do with uncertainty and vulnerability. If I give away control, even partially, but remain accountable for the results, it makes me vulnerable. So, I obviously need self confidence and trust in my own abilities to be able to judge whom to trust and to be able to deal with whatever comes from giving away control.
To set the playing field for self organization, I need to make clear which decisions I delegate to teams and to what extent. An approach I have found very useful is the practice of delegation boards from Management 3.0. By setting up a delegation board I basically define which tasks I delegate and to what degree. I make it clear with teams and individuals what they are allowed to decide. Likewise, it clarifies what remains either partly or fully my responsibility. This is an important step in building an agile mindset. It helps to establish a relationship built on mutual trust.
I trust the teams and individuals to take the decisions for which we jointly agreed the delegation level. I also trust them to come to me for issues beyond those defined on the delegation board. On the flip side they trust me that they are entitled to decide according to the defined level of delegation. They also trust me to respect their decisions according to the agreed level of delegation.
Theory X and Theory Y
Another very important factor when considering an agile mindset is how we view people. Theories X and Y developed by Arthur McGregor (Theories X and Y) propose two different models concerning people’s motivation.
Theory X postulates that people have an intrinsic human motivation to avoid work. Therefore, they need constant extrinsic motivation and control to counteract. A manager’s most important task is to exercise the control to keep people working.
In contrast Theory Y assumes that people are willing to work. They exercise self-control and self-direction to achieve the company objectives. The determining factor for the degree of self-control and self-direction is the commitment to the objectives. The main task for a manager is therefore to maximize the commitment to the company objectives and to remove impediments.
In the agile world the belief is that people behave according to Theory Y when given the chance. When setting up agile project teams as an agile manager you should build the teams around motivated and capable people. You should trust them to be able to do their job. Remember, agile teams work in a self-organized way. As an agile manager believing in Theory Y and trusting your people you need to constantly ask team-members and yourself: What do we need to be able to do our job better tomorrow? Besides needing your help to remove all kinds of impediments what your teams need most is trust. And you need it too. Trusting your people is the most important point to be able to eliminate the desire for micromanagement. Trust is also needed to unlock your colleagues’ full potential.
Trust your people to do their work
While an agile team is working, there is no line management or project manager control dictating how people should do their job. It is the team’s accountability to deliver what they have committed to at the beginning of an iteration. To be very clear about this: Commitment does not mean promise. A team cannot make a promise. No one knows what unforeseen circumstances could influence the team throughout the iteration. Team members could fall ill, or something else completely unexpected could happen. Commitment means an agile team is expected to do everything within its control and influence to deliver what was considered achievable at the beginning of an iteration. In addition, if circumstances arise, that are beyond the team’s zone of influence, then the team is responsible to make these visible to the relevant agile managers.
So, where does this all lead us to? As an agile manager, I first of all need to trust my team(s) that they will do their job. But there is more. I also need to allow the team enough space for trying out new approaches, and thereby allowing them to make mistakes. I need to trust the team to learn from these moments, and find ways to avoid them in the future. Even if something unforeseen happens I need to trust the team to be able to handle it and to ask for help if things go beyond their sphere of control. If I take back control at the moment things go wrong, I take away precious learning opportunities from my teams. In addition, I remove accountability and most significantly trust. In doing so I destroy any chance of enhancing my people’s commitment towards achieving the company objectives.
An agile mindset also requires a safe-to-fail environment. What that means is that I acknowledge the simple truth that people make mistakes. That means I need to set up an environment where people are not punished for mistakes, but can learn from them as fast as possible. My goal is to make use of the ideas and creativity of all team members for finding solutions.
Of course, teams may need some guidance in doing so, especially inexperienced teams. Giving this guidance is my job as an agile manager. I need to trust the overall team to get things right and do all I can to help them. This might mean, for example giving a team specific input based on my own personal experience. Having done this, I make sure the ownership for resolution remains with the team. I will ask them how they will now proceed for themselves with this new input.
Trust, control and the agile mindset
So, no control at all? Not quite so. Control remains part of the game, the difference is that it is practiced differently. If I do not control how people do their job, what is it I control? The answer is “outcomes”. As an agile manager, I can inspect (control) the resulting product increment at the end of an iteration. I have the opportunity to check (control) that it fulfills both feature needs and quality criteria agreed upon at the beginning of the iteration.
While I give teams the freedom to decide how they organize themselves, I can take influence (control) on the results that are produced. If something needs adapting with the result (control), then the team responsible for the work is required to react. They need to learn from the situation and enhance their approach to making commitments they can live up to. The job of agile management here is to give the team the help and encouragement they need to do so.
In the end, it is not trust or control but trusting control. To build an agile mindset trust is a vital component. It is the basis to allow agile teams to work in self-organized fashion. As an agile manager, I need to trust my people and believe in their capabilities and their commitment, to unlock their full potential. If I stick to micromanagement and control closely how people do their job, the overall result will only be as good as my individual person. On the other hand, it is also important that I execute control. I need to make sure that we reach the agreed goals, for example, an iteration or release. I also need to make sure that these goals are always clear, especially when we make changes during the project.
This may sound like a challenge, but it is absolutely worth the effort! My experience from more than 20 years in software development shows clearly that empowered, self-organized agile teams in safe-to-fail environments, create not only better, but also faster results than teams suffering from micromanagement.
For more information on an agile mindset please see
For Detailed information on delegation boards, please take a look at our experiences in the following blog:
To see how an agile mindset can operate in practice you may also take a look at the following blogs: