Agile 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.

Summary

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.

Kelly.

Photo by lepiaf.geo