5 Reasons Why Agile Development Must Be Driven from the Top

5 Reasons Why Agile Development Must Be Driven from the TopAgile development is often initiated by the development team itself. Whilst they may find some good advantages, the most profound benefits of agile software development will not be realised unless it is driven from the top.

Here’s why:

1. Multi-disciplined teams

One of the key concepts of agile development is the idea of multi-disciplined teams – “one team“. An agile development team needs all the skills necessary to complete its task from cradle to grave. From initial request to delivery to market, the team should be able to deliver without reference to another team.

Having multi-disciplined teams reduces coordination, creates clear ownership and responsibility, speeds up delivery, and empowers the team. As I said earlier, profound benefits, but benefits only possible to realise often by making changes to the organisational structure, which usually need to be driven from the top.

2. Co-location

Another key concept of agile software development is co-location. Ideally the whole team will all be located in the same place – not just the same office but literally sitting side by side in the same room or space.

Having co-located teams also reduces coordination, speeds up communication, fosters closer working relationships, creates the opportunity for continuous collaboration, enables face-to-face communication, means you can get better visibility of progress etc by putting things on the wall, and strenghtens team spirit.

These factors, over the course of a project, can make or break it. Co-location often requires management intervention, in order to move people around so they can all be together. Sometimes it may be even more fundamental than that – moving people from offices in different cities and physically reorganising the company. So again, it really needs to be driven from the top.

3. Product ownership

A common problem in large organisations is that there are many stakeholders for any given product. It is also common for development teams to be developing and maintaining multiple products. The effect of this is that many people make requests, and to each of the stakeholders, their request is naturally the most important.

With so many requests coming from so many directions, how does a development team prioritise and manage expectations. Usually, it’s a case of who shouts loudest! This is not the best approach for the business, as it’s sometimes those demanding the most attention that get priority and not those that drive the most business benefit. It also creates an unpleasant working environment, where the default system for getting things done is to moan, shout and escalate. It’s not the most motivating way to work, and it’s not the most effective.

A development team needs a clear Product Owner, at least for each product if not for the whole team. The Product Owner needs to be the one person who prioritises on behalf of the business, and needs to have real authority to make decisions and stand by them. The team need to know that this is the one person they should listen to the most.

Having clear and empowered Product Owners transforms a teams’ performance by enabling them to work on the most important requests, cutting out a lot of noise, creating a more positive working environment, motivating the team, and strengthening business relationships.

The trouble is, in large businesses, there is often not one person who naturally holds this position and has this level of authority. The role of Product Owner needs to be explicitly assigned to someone and communicated clearly to all stakeholders. As this role often spans business units, this usually needs to come from the top.

4. Agile project management/Stakeholder expectations

With agile project management, stakeholder expectations need to change. Where they may be used to seeing a full requirements document and/or specification up-front, they shouldn’t expect to see that in agile. Where they may be used to seeing a detailed project plan in the form of a gantt chart, they shouldn’t expect to see that in agile. Unless they know that, understand why that is, and really believe in the benefits of agile and why there is a need for change, this will potentially cause you problems.

Since these stakeholders are often senior managers and directors of the organisation, these steps are an important part of selling agile and where the real change management challenge is. This needs to be carefully managed and the message needs to reach all key stakeholders, at all levels of the organisation. In order to secure real buy-in, this usually needs to be driven from the top.

5. Different values

Agile development has different values to traditional project management methodologies. Unless people understand what these values are, how they are different to previous way of working, they will struggle to adopt or embrace some key aspects of agile software development.

People need to understand that whilst they will have less predictability and won’t be able to see a clearly defined fixed scope, instead they will get a high-performing team that can deliver software faster and to a higher quality, and that they’ll get much more visibility and flexibility that’s more likely to meet their changing expectations, and with less bureacracy.

Everyone needs to know that it’s okay to lack that perceived clarity from the outset in favour of flexibility and the other benefits that come from adopting agile development. They need to know that agile principles and practices mitigate risk in a different way – not with detailed planning and analysis and strict control, but through visibility, transparency and frequent delivery of working software in small incremental iterations.

People need to know that these values are supported from the top; that it’s not only okay to behave in line with these new principles, it’s expected.


Adopting agile development will help with many issues. But without these things being led from the top, you will only be partially successful and you will only see a small fraction of the possible benefits.


Photo by lepiaf.geo

6 Responses to “5 Reasons Why Agile Development Must Be Driven from the Top”

  1. drew says:

    Kelly, I have been in a very similar position recently to the one your post describes.

    Given that we'd cracked the co-location of the team and had a very smart and involved Product Owner, the points regarding project management and stakeholder expectations really rang true, sadly to the point of almost jeapordising the entire project.

    Hopefully, influential IT managers are still reading blogs such as yours…

    Thanks for the great post!

  2. Pawel Brodzinski says:

    I wouldn't treat these things as agile-exclusive. Co-location is a single trick which yields much gain in productivity no matter if you're agile or not.

    With cross-functional teams their work is usually more efficient although on the high level it is more difficult to manager them.

    As far as you have a right person strong product ownership will always trump distributed responsibility.

    But yes, all these have to be driven from the top. Otherwise teams will struggle to change reality around them and would likely have to focus on maintaining whatever they managed to achieve instead of constant improvement.

  3. Marev says:

    Agile Development must be driven by Leaders, not Managers…

  4. Mendelt Siebenga says:

    All I see here are reasons agile development should be supported from the top. No surprise there. Agile requires changes in management as well as changes on the work floor, there should be support on both sides.

    In my experience the most successful agile adoptions are those that are driven from the work floor and supported by management, not the other way around.

  5. Apeksha Bobde says:

    I suppose Agile always faces issues like Co-location problems, rapid turn-over issues with the teams. I got an informative resource that could be of help to all of us..


  6. Bathroom Basins says:

    This blog is really great, I have lots of questions and there area ton of answers here. Though I'm not sure I 100% agree with this post it is extremely well written, thanks

Leave a Reply

What is 2 + 3 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)