Agile Software

Agile software development is driven ultimately by the pragmatism of many of us who have worked on a large number of software projects. It values the real requirements of a development process over the illusory:

Individuals and interactions

It is teams of people that build software, not processes. The team, which includes customer stakeholders, project management, users and everyone else involved, has a specific makeup with a unique profile of skills and knowledge. Like everything else successful in business, the development approach needs to be built around the people not the other way around.

Working software

It may seem obvious that the purpose of software development activities is, ultimately, some working software. Unfortunately many projects are run with the belief that working software is a side-effect. We take the early delivery of valuable software to be our primary task.

Customer collaboration

We run active design workshops with all customer stakeholders, using paper user interface mockups, use cases, role playing and any other techniques we need to elict the real requirements of the software. We video these sessions as a record of requirements, and generate UML models during the sessions that together act as a shared understanding of the requirements. Written specifications cannot ever hope to capture the richness of this approach, and it results in far far better software.

Responding to change

Things change, during development and after it. Rather than concentrating on a frozen specification and delivering to the specification (but producing nothing useful) we are alive to the change that can happen during a project and we manage it effectively. High levels of communication, simple tracking tools and a healthy dose of common sense keep projects on track, delivering value.

As much as we would like software development to be completely predictable in advance, the reality is (as anyone who has bought or developed bespoke software) that it just is not. This is not due to a lack of planning; successful software works with people, and the interactions between people, processes and computer systems are so complex that attempting to specify them in isolation is doomed to failure.

Our Approach

Guided by the values of agile development, we use a few standard tools and techniques that have proven value:

Video documentation

Written documentation is of little value when communicating between a specialist engineering team and non-specialist functional experts (i.e. the customer). Words are slippery things, with meanings that can vary hugely between author and audience. From such differences of perception are projects destroyed. We conduct requirements capture sessions with appropriate representatives of stakeholder groups, and we video them for posterity. We can review these videos later to find out what was really required, not what we thought we understood (which is so often mistaken).

Vision

Analysis is only part of the process of building good software - a key part is constructing a vision of the software - a great architecture is one that embodies the forces at play in the customer's environment in it's very core.

Problem domain models

Of course, written documentation serves another purpose - it is a visual aid to thought. By heirarchically structuring a specification we impose order - unfortunately, the hierarchical nature of a written document cannot hope to capture the richness of a real problem domain, so much is lost.

We develop rich UML problem domain models (using the excellent MagicDraw software) during analysis workshops that capture as much as possible of the problem, allowing us to see dependencies and complexities, and tease out issues as early as possible, with the people who can help right there in front of us.

Agile solution development

What we do not do is deep solution space modelling. One of the marvellous things about code is that it runs, and as such we can test it. Agile development is test driven - for every unit of code, there is a corresponding set of tests that we use to validate the unit's interface, to ensure it conforms to our expectations (especially in exceptional and corner cases) and, most importantly, to provide cover for refactoring.

With the air cover that complete, automated test coverage provides we can refactor at will, which allows us to ensure the software remains permanently high quality. We aim to be able to take a cut from the development trunk at any time and that it should be of very high quality.

Rapid delivery

We deliver early and often, with testable alpha versions available on the Internet as soon as possible. We iterate through the software, fleshing out parts that are unclear and driving issues out to the surface where they can be properly interpreted.

Professional issue management

When issues arise during development we make sure they are handled immediately and resolved properly.

Too often in traditional development approaches the issues that ultimately cause the failure of a project emerge very early, often in the core of a development team. Someone, somewhere, shrugs their shoulders and says:

"well it's not in the spec... so don't worry about it".

With good communication and good tracking we ensure this never happens here.