According to this survey, the most common concern about Agile adoption is a loss of management control.

What are the different arguments one can bring to address this specific concern? How do you help the management trust Agile process and give up this control they like to have on their teams?

  • 1
    Are agile and management control mutually exclusive? Jan 16, 2012 at 17:50
  • @DavidEspina Agile is innovative in which it allows teams to self organize. Task attribution is done in a 'pull your own work from the todo list' fashion instead of the traditional manager assigment. Many small managers see that as a loss of control, and thus loss of personal power in the company. Which is to be honest true in some regards, but that's for the greater good.
    – xsace
    Jan 16, 2012 at 18:42
  • Agile claimed team self organization as a new concept? If you are experiencing some resistance to team self organization, it has nothing to do with Agile and more to do with less than reasonably talented managers. You can have a butt load of control over a team that self organizes. It appears you are more describing someone who needs to micromanage versus someone who knows what a proper management control is. Jan 16, 2012 at 18:59
  • 2
    @DavidEspina I'm describing no one actually. I was providing you an example for the most common concern according to that survey, a loss of control. Of course this concern is worng and demonstrate some limits in the management ability of whoever holds it. But that's not the point, I'm looking for answer about how to address it.
    – xsace
    Jan 16, 2012 at 19:08
  • This is an historical question. While it could be rewritten to be less of an opinion poll, especially with the addition of some concrete specifics, that would invalidate most of the answers. I suggest that this question be closed as "too broad" or "opinion-based" to show that it is no longer in line with acceptable Q&A here, while leaving the question and its answers for future visitors if they find it useful.
    – Todd A. Jacobs
    Aug 27, 2015 at 23:29

8 Answers 8


How do you help the management trust Agile process and give up this control they like to have on their teams?

The only solution I've found so far is that you have find a manager who has a good press inside the organisation, but likes to try out new approaches. You don't need the most open minded one, because she may not be that well connected, which is wrong for the purpose.

Most of the managers I had the pleasure to work with never believed in organisational changes which came from their developers. They only considered ideas from top or from a trusted member of their network. So the first step is to find the right person with a middle sized network inside the organisation. After you find her, do a small Agile experiment and when it is successful make it visible to others and to the executives and keep going.

After a while, the manager who started the experiment will become more popular and successful inside the organisation and the members of her network will come by and ask for the recipe. They'll find out that the popularity and the success weren't achieved with control, but with empowerment. Some of them will try it out some of them will never.

The funny thing is that developers talk to each other and will learn that there are projects where they can make a difference, be better at what they are doing etc so they'll ask for a transfer and the managers who still want to use control as a management tool they'll have less manpower in quantity and quality.

Actually, I know an IT manager who is using empowerment and almost everybody from his organisation want to work with him, so the other managers have started to learn more about empowerment, because they don't want to lose their people.

The network is very important. I knew company where the change manager wasn't really popular and nobody really cared what he was doing, but right after having a different guy in position with better connections, things started to happen.

  • +1 for developers talk to each other and will learn that there are projects where they can make a difference, be better at what they are doing etc so they'll ask for a transfer and the managers who still want to use control as a management tool they'll less manpower in quantity and quality.
    – IsmailS
    Jan 19, 2012 at 5:25

As a project manager, you can continue to give management the control they are looking for in the form of governance and feedback loops.

If you want to use Agile for your development team but management still wants reports and metrics, put a governance wrapper around your agile process.

Find out what kind of metrics they want and how they would like to communicate feedback back to the development team. Then, craft a set of artifacts and processes that will meet their needs while still allowing your development team to operate with Agile.


The main problem with surveys is that people say you what they know and - at the end - you know what they said...

The pointed survey describes the normal state of affairs. At the beginning:

  • there is no experience with agile methods
  • company philosophy/culture is different than agile
  • some people naturally oppose to change
  • the knowledge about agile is limited

If the company will not overcame the problems they will appear in the leading causes if failed agile projects.

If they succeed in dealing with it, the problems will appear in the barriers to further agile adoption section.

Concern about loss of management control appears because one's knowledge about agile is limited as well as agility in the company culture is limited. Therefore, it may difficult to imagine what agile management must be, and how agile changes the management scope.

Look at the other concerns: lack of upfront planing, lack of documentation, lack of predictability... In environment where requirements change often:

  • one can not upfront plan much
  • maintaining the documentation is the pain in the ... or is pointless at all
  • the predictability one have is an illusory one

The same is for loss of management control. Agile shifts management from tasks one probably didn't want to do anyway (direct task assignments) or tasks that were almost pointless (most of upfront planning) into a more strategic release plans and productivity improvements.


These people never had control in the first place, it was just perceived control. Losing control is not really what people fear, they are scared of change, they are scared of trying something new, of taking a risk. The best way to answer this question is to change the question and to help people realize that success is not about control it is about value and the best way to reinforce that is directly without being but it will go away once you start delivering value.


As Ken stated - the management only has an illusion of control.

To produce quality code, the developers have to do what they know is right.

Non-agile development is often an illusion of order...

You have design, implementation, testing, but wait - the requirements need changing a bit and then a bit more, until finally the life cycle management in unreal.

Agile management simply accepts the truth - projects change as you work on them.

Agile also allows you to control when the project will be complete - something traditional ALM does not allow...

A tradional ALM requires time-buffers to address uncertainty and the projects often still take longer than planned.

Agile lets you decide what is most important to implement at each iteration and stop with a work product at any point - far more control than any non-agile method.

Agile provides many organised points of intervention.

As of the self organization of the teams - if you want an efficient team then this is a must. In fact even in non-agile ALMs the teams self organizes in some ways as a natural process of formation and maturation of the team - each team member shows what he is good at and the members find ways to communicate and work together.

For completion, I recommend getting management to read Getting Agile with Scrum.


I'd start improving Software Quality:

  • Automated builds
  • Automated test
  • Transparency on ongoing development (for example jenkins)

Measure the quality before the Agile adoption and after and improve it!

If the software is becoming more reliable and aligned within the business requirements the management is much more secure about the project control.


In reality agile enables management to have more control not less control although as the report documents this is not necessarily how management feel. You can change these management feelings but it does take time. I suggest the following

  • Use the review sessions to get management engaged in the process and really show that the team is making progress on the high value features.
  • Use prioritisation by business value to demonstrate that the team are working on the highest value tasks first, this will start to show that the team understands that the project is about delivering value rather than ticking off requirements.
  • Actively seek out management feedback on the deliverables so far and add their suggestions to the backlog of things to implement - try to deliver some of these in the next iteration to demonstrate that they have input into the process
  • Produce documentation as you go along, user documentation, technical specs, UI mockups and show that these are being produced. This will remove the 'lack of documentation' concern and help to build management buy-in to the process
  • Use burn charts to show predicted release dates based on actual data, make these really visible and display current progress against these. Management will really like the predictability and forcastability (not sure that is a word) of the timelines. The burn chart based forecasting of dates is a great way to gain management trust in the process

Ultimately it is not the self organising nature of agile teams that worries management it is the apparent lack of forward planning. You need to use the tools in your agile kit to show that you have a clear plan for the future, albeit based on having a fixed cost/time rather than fixed scope.

If the self-organising team concept is really a problem, you could try to temper that down and have the agile project manager (be that a scrum master, product owner, domain expert, whowever) take a slightly more lead role in helping the team organise. Looking at an agile process more like DSDM Atern may also help if you have a real problem, as that provides a more structured project management role onto an agile process.

Changing how people feel is always a long and painful process so this will take time but nothing works better than being able to demonstrate successful delivery of a project that solves a business need on-time and on-budget. So above all else, make sure your project delivers. If you nail that even the most worried manager will become a convert.


In our company the Agile methodology has been applied since 2004. Luckily, its necessity was realized and it was introduced by the founder of the company.

In this interview he says:

"I read “Peopleware: Productive Projects and Teams” by Timothy Lister and Tom DeMarco which seemed to me a world of difference from all the other books I had read about product management. The book reinforced my understanding of major principles for collaboration and effective project management: trust people’s ability to make decisions, respect and empower team members instead of enforcing centralized planning, hierarchies and resource management."

You might want to read or recommend this book to the managers whom you need to convince that the Agile methodology would radically increase productivity as a reward for the lost illusion of control they might have now.

As Nathan Wilson, Gartner, put it: “Give up the illusion of control to find control.”

Not the answer you're looking for? Browse other questions tagged or ask your own question.