What is Agile

Agile development means many things to many people. To some it means SCRUM, to others, XP, to yet another group it could mean a mash-up of both or even just a home-spun collection of general practices and methodologies. To many people Agile is often simply a buzzword, one upon which meaning is ladled liberally from second-hand conversations or short, pithy, phrases.

To a developer, such as myself, Agile methodologies are both a blessing and a curse. The issue is that while the process may be agile, the written lines of code can be far less flexible.

How it can all fall down

Consider for a moment that someone asks you to build them a television. You go about producing a television according to their description and give them a demo for the sake of getting their feedback on your progress. Their feedback is that they don’t understand why it doesn’t play DVD’s. Now, making a television with a built in media player is hardly revolutionary, so you’d think adding that to the product wouldn’t necessarily be insurmountable. The issue is that you already have a frame, and an outline of the components, none of which account for the needs of a built-in media player. At this point in the project adding a media device into the product involves almost completely starting over. This is an allegory for things that have come up during the course of projects handled with an Agile development methodology.

The trouble comes in with the word ‘Agile’. It is too often interpreted to mean anything goes, and that there are no firm expectations. It is used as a short cut through the, admittedly laborious, process of defining firm specifications, leaving all too much to the imagination or interpretation of both the developers on the project as well as the client pursuing their goals.

How to make it work for you

No matter what type of project you’re working on, the set of procedures you use should work for you, not the other way around. If you find yourself spending more time following protocols than being productive, then you should be looking for another way to do things. In the context of software development, whether it is for a simple website or a complex and rich web application, there are ways to use Agile methodologies that enrich the experience for both developer and customer without imposing burdensome rules and restrictions on creativity.

Agile planning

One way is to actually develop the specifications collaboratively through a phased process of rapid prototyping and wireframes. The development and design teams can work with you to flesh out exactly what you want before a single line of code is written. Once the process is finished, you should have a complete working model of the features and design elements that are critical. The development staff can then take the model and turn it into a full-scale application, with the freedom to make choices about technologies or implementation details behind the scenes.

Agile Discovery

There is not a single person or team who knows everything. This means that during the planning and discussion of any project there will be questions that arise for which there is not an immediate obvious answer. If all goes well the questions will get answered quickly and in a way insuring progress can continue without interruption. Other times questions will arise in the middle of a project due to either changes in expectations or technology. This falls into the category of ‘unknown unknowns’. There are simply too many moving parts to perfectly predict what issues may come up, but that’s no reason not to try to account for them. Building discovery or research points into a project plan can help a great deal in allowing an agile project to succeed.

Agile Delivery

Project management is a game of managing short term and long term goals. Having the satisfaction of meeting short term goals is important to both sides of any given project. Agreeing on what those goals are doesn’t have to happen all at once, but it’s best to have an outline and at minimal, intermediate targets to mark and build progress. This can be done with a simple timeline or with a complete roadmap. The important thing to remember is that this is less for describing anything concrete with respect to features or functionality, and more for the sake of allowing both sides to agree on the amount of progress that has been made at any given time.

Agile in conclusion

The methodology you choose shouldn’t make or break your project. If done right any process should get you where you want to go. The ultimate goal of Agile Development shouldn’t be to make better software, because that can be very subjective, but to make software that better suits your needs both during the process and once it’s finished. We approach each project as an opportunity to provide our customers with the best product, and the best experience, which means that the methodology we employ is tailored to suit you.

That’s what we mean by Agile Development.