Adopting Agile

Without a universal definition of agile, it can be difficult to separate those who are truly practicing agile, and those who have it wrong. While agile has grown immensely popular over the years, there are still some who have yet to convert. We took a look at each of these groups.

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

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.