The term "Agile" in the
context of software development is no longer an alien word, with many companies
professing to do, think or indeed be
Agile. While on the surface this is great for the software industry, it can
bring problems as there is no single definition of Agile or definitive process
that everyone follows. Carrying out projects and transitioning to Agile can
therefore end in disaster if perceptions and expectations differ. This is where
training, communication and motivation are so important in the successful
adoption of Agile processes.
In order to better understand
issues associated with transitioning to Agile, we can break people down into three
general groups - the "know-it-alls", the "non-believers" and the
"non-committals".
The
"know-it-alls"
One of the biggest
challenges when undertaking a project using Agile methods is getting all
parties to think in a consistent way and have the same understanding of the
process. In Valtech's experience with its clients, those involved usually have
a pre-conceived idea about Agile but it isn't necessarily the same as their
colleagues, which can be detrimental to a project. This goes for both the
customer and partner delivering the project. It is vital that everyone is "singing
from the same hymn sheet" from the outset. The first stage of any Agile
roll-out must, therefore, be training. The challenge here is to get as many
people involved as possible - from project owners, architects and testers,
through to end-users - to ensure that everyone knows how the particular project
will run.
Advertisement
A recent Valtech project
with a firm in the travel industry illustrates the point. During the initial
training phase of a project, the software architect wasn't present and his understanding
of Agile terminology differed slightly from the rest of the team which caused
problems further down the line. Although the words used were often the same -
both parties talked in terms of iterations - each understood the same word to
have different meanings. Valtech uses the word "iteration" to describe short
bursts of activity lasting between one and two weeks which result in a working
software feature. The client, by contrast, assumed that "iteration" meant a
completely new version of an application - something that would take far longer
than a single week to develop.
The
"non-believers"
As well as having
pre-conceived ideas, a lack of understanding or an unwillingness to take part
is also a hurdle which many Agile projects face in the early phases. For many,
waterfall methods are the de facto way of running software development projects
as "that's the way it's always been done". Agile methodology, however, can be
considered a series of mini waterfall developments, with significant emphasis on
early and constant customer feedback. Where it can be more difficult to convert
the non-believers is when it comes to the level of buy-in and commitment that Agile
methodology calls for and the lack of detailed spec and scope at the start of
the project.
Traditional software
designers typically want to work to a fixed price and have the spec up front. Vielife,
a company we worked with recently, had already spent a large amount of money on
detailed requirements and design before coming to us for help with the project.
In fact, the managing director was adamant that there was no room for manoeuvre
in his original requirements.
Yet, within a month of using
Agile methodologies, the budget was cut by 10 per cent by convincing him to cut
down the specification that had been produced beforehand. We tackled it in the
same way that you would if you were buying a new car on a limited budget: you
might like the idea of a sunroof, but the reality is that you wouldn't use it
very often and could certainly drive to work perfectly safely without one. By
focusing on the fundamentals - the engine, chassis, and seatbelts - you can
often get rid of the optional extras. The beauty of Agile is that these extra
features can always be added on at a later date if budget allows.
One month later, the
direction of the development had changed by 30 per cent from original
requirements. It had transpired that the company was in the process of being
acquired and the MD realised that if he could reduce the cost of the project,
it would make the company all the more attractive to buyers.
The "non-committals"
The third group of people
we generally see are those who like the sound of some of the aspects of Agile
but not others. Typically, developers like the emphasis on quick results, but
fail to ensure true involvement from the business - the "customer" if you like.
This half-hearted approach won't work when adopting Agile methods - it needs to
be either all or nothing and everyone in the business has to embrace the
principles of Agile, not just those working on the code. Breaking a project
down into iterations will have little value or success without undertaking
scrum meetings involving the users at the end of each stage, for example.
The importance of training ...
The main way to combat all
of these challenges is through consistent training to ensure everyone is
starting from a level playing field. This goes for all involved, from project
managers to users through to the CEO. Our own training and certification
program gives clients a thorough introduction to Agile
methodologies and seeks to consolidate the many different interpretations of
Agile methods across the industry, into the most pragmatic approach. Our
consultants also undertake the same training and the emphasis is on sharing a common
language to avoid antagonistic behaviour where each party believes his or her
understanding of terminology and principles is the one that the whole team
should abide by.
Depending upon requirements, training can be from
one-hour to 12-week courses to introduce the philosophy behind Agile
methodologies and provide attendees with hands-on experience of iterative
planning and daily scrum meetings.
... combined with motivation
In addition to ensuring
consistency of understanding and processes, managing the stress associated with
a new way of working and the continually changing aspects of Agile development is
equally important. Such were the conditions of a recent
project that, once again, involved
vielife.
For this project we employed the Scrum agile methodology
where the customer became part of the development team and frequent, intermediate deliveries with working
functionality were provided so that continual assessment could be carried out.
This way of working was very demanding as each iteration and its evaluation
came with a new set of pressures as the customer sought to achieve more during
each phase.
However, at the end of each
iteration of the project, the demos became a release valve. They were made into
as much of an occasion as possible with treats such as cakes, beer and ice
cream being brought in to celebrate successes. Psychologically, the demos
became an arena in which the team could "score goals". Like taking a penalty,
the level of adrenalin peaks in the time leading up to the demo and is then
released as the client applauds the team's effort and the group feels that its energy
and stress has been worthwhile. This worked as the biggest stress alleviator in
the project.
We also introduced monthly
team building events, such as go-karting as fun-filled stress-free breathers to
revive the team. We found that treats like these events and the demo-day treats
were valued as they rewarded success and allowed the team to release adrenalin
before moving on to the next iteration.
Agile
remains an emerging methodology with no industry standard best practice. It's
therefore important to invest in training and team-building activities in order
to ensure everyone tackles each project with a similar approach. Just because
we speak English in the UK
and US doesn't mean that we shouldn't try to learn a few words in another
language when we're abroad. The same applies to Agile: being open to new skills
will create a better culture of respect between team members and lead to
greater project success. About the Author
Jonathan Poole is CEO at Valtech. He holds over 15 years of
cross-market sector experience. Previously, Jonathan was the Operations
Director of ATM Technology Management, running a variety of service contracts
throughout the UK.
In 2000 he became an Associate Director of CMG PLC managing and designing
global business solutions as well as developing service solutions for the UK market
incorporating offshore and near shore facilities.
Articles 
The term "Agile" in the
context of software development is no longer an alien word, with many companies
professing to do, think or indeed be
Agile. While on the surface this is great for the software industry, it can
bring problems as there is no single definition of Agile or definitive process
that everyone follows. Carrying out projects and transitioning to Agile can
therefore end in disaster if perceptions and expectations differ. This is where
training, communication and motivation are so important in the successful
adoption of Agile processes.
