Each project is different and each client has different needs. Scott Logic has the flexibility to fit in with client requirements - but often we are asked to take on ownership of the process of software development, as well as the day to day mechanics of cutting code. We have the experience to show that certain techniques can be utilised to greatly increase the chance of project success. These techniques are variously called Agile, XP, Scrum or Lean... whatever you call it, this new way of developing software has slowly but surely trickled down into everyone's way of thinking - everyone wants to be agile... but there is less agreement about what this means in practice. At Scott Logic, we have taken certain ideas from the Agile/Scrum/Lean/XP world and are happy to recommend them to clients as techniques which can make a real difference to both the quality and time to delivery of a software project.

Rapid and Constant Feedback: To the Client....

The software development industry has a reputation problem, and generally speaking it deserves it. Teams promise to deliver on a certain date, then they vastly overrun. Functionality and requirements that were expected are not delivered, or are inadequate. Despite massive investment in QA and testing teams, bugs can continue to appear or even reappear. Why is this?

In recent years, the software development industry has started to take a look at itself and put its house in order. While we should rightly regard the concept of "bug-free software" with scepticism, what is critical is that the project sponsor feels informed of progress and in control at each stage of the process. Scott Logic recommends a project life cycle which consists of a series of short iterations - periods of time, perhaps a few weeks long depending on the project, at the beginning of which the team will set out what it intends to do, and at the end of which it reports back to the project sponsor what it has achieved. Clients should feel comfortable with the reporting of progress of the project and the control of it, without necessarily being overwhelmed with day-to-day micromanagement. As an iteration starts, they should be able to set priorities - up to and including radical changes if necessary - and be given an honest high level view of the state of the project.

Another advantage of iterations is that it enables teams to calculate their velocity - a measure of the productivity of the whole team. As the number of past iterations increases, the past performance of a team can be used to predict future performance, and this gives us increased confidence in our estimations as they are refined throughout a project. It is also useful in measuring longer-term progress against a deadline or project plan.

This diagram is an example of a burn down chart, which is a graphical representation of work left to do versus time. It is useful for giving a visual representation of the state of the project and for predicting when all the work will be completed. It shows the sort of higher-level information that can be generated and distributed to interested parties if a development team employs short iterations and measures their progress.

...and to the Development Team

While feedback loop of one week may work well from a management perspective, it is far, far too slow from the point of view of a developer. The more developers on a team, the more chance of people treading on each other's toes - it is incredibly easy for one developer to inadvertently break the code of another, even within a single day. This sort of integration problem is a constant bugbear in team-based software development, causes morale problems, and is a nightmare to manage. A solution is to tighten the feedback loop until a developer can be as sure as they can be that their check-in isn't going to make the build bad. The difference between a "good" and a "bad" build will differ from project to project, but could be as simple as "it compiles"... or complicated to the extent that unit tests, code analysis, integration tests or even system tests are completed on each check-in. The larger the team, the greater benefits will be realised with the implementation of this sort of Continuous Integration on a separate build server.

Make Everything as Simple as Possible, (but not simpler)

It's often tempting to over-complicate software systems. Scott Logic emphasises delivering business value over building generic solutions. Software should be driven by requirements from a customer, not based on assumptions of what might be required. Using smaller design documents followed by frequent iterations which steadily delivering more functionality allows the team to refocus and re-evaluate the design as we go along, rather than doing a big design up-front.

Testing, Deployment and Automation

Test driven development isn't a panacea, but those who use it have found it an excellent way to drive the design of well written, loosely coupled and object-orientated code. Other benefits are

• Reductions in defect density
• Built-in code documentation, as the tests specify the developer intent at the time they wrote them
• Increased confidence in the code because of the safety net provided by the tests - meaning we can maintain and refactor code and have a great deal of confidence that we haven't broken anything
• Helps to prevent regression from one release to another

One important element of agile methodologies is the requirement for frequent releases. The work to migrate a system from the development environment into test or live should not be left until the last minute, but addressed early in the project life cycle - and as far as possible be an integral part of the work done by the team. This means that the scripts which create the end-product should be documented, tested and maintained as the system develops, as a matter of course. Rather than allocating time to release software, it should be demonstrably ready to release and ship at all times. While there is often a practical limit as to how often we want to release in practice, automation should allow us to demonstrate that the software is releasable at any point, at short notice.

Communication and Continuous Improvement

There is sometimes a tendency to see software development as a lone activity. This is far from the truth - Scott Logic believes that great software takes more than just technical excellence, it's also about people, and as such it is vital to encourage communication throughout a software team. Daily stand ups enable the team to discuss progress and address any blockages. Iterations provide a natural point for progress to be measured against the plan, but also an opportunity to look at how the process is working and make changes improve it. A process should be allowed to grow and develop with the team, and alongside the software that is being created.

Summary

Scott Logic has the ability to fit into any client's requirements and current development practices, but we believe that agile ideas have a lot to offer a modern software development team. Rapid feedback via iterations and continuous integration, simple architectures, test driven development and communication are some of the most important concepts that we recommend. All of these best practice ideas are easy enough to articulate, but in practice they require regular reinforcement and vigilance, and for all team members to focus on the quality of the product as a whole, rather than just their own code.