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.
{sidebar id=1}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.
