Kelly Waters is Web Technology Director for IPC Media, one of the UK's largest publishers of consumer magazines and web sites. Kelly has been in software development for about 25 years and is a well-known narrator of agile development principles and practices, as a result of his popular blog 'Agile Software Development Made Easy!' (www.agile-software-development.com). Kelly is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile
5 Reasons Why Agile Development Must Be Driven from the Top
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.
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.
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
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.
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
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.
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.
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.
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
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.
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.
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.
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.