VSJ – May 2006 – Work in Progress

Two years ago, Brian Swan of Exoftware made a very well received presentation to the IAP Symposium on the principles of Agile software development. Here, his colleague Sean Hanley develops these ideas for a wider audience.

The last 40 years of the 20th century saw lean manufacturing and concepts such as ‘Just-in-Time’ revolutionise the manufacturing industry. Indeed, they have become de facto standards. Many such principles readily apply to the software industry. These concepts are captured within Agile software development methods.

History: Software development has a long legacy featuring of a number of processes and methods. Most common of these is the waterfall method where requirements gathering, design, development, testing and deployment are distinct steps – one step cannot be started until the previous one is completed. The waterfall method is not “bad” per se, but really only suits projects where the requirements are fixed – where the end result is definite and exact. However, in most modern projects, change is inevitable given that markets and needs constantly shift. Many teams have found that by using waterfall methods, they are, in fact, failing; failing to deliver value, quality, on time and on budget. This is at a huge financial and human cost.

So lightweight processes that address the need for this level of flexibility and that encourage a craftsmanship approach to software development have emerged.

What is Agile software development? Agile is an umbrella term for a group of methodologies (Extreme Programming, DSDM, Crystal, Lean, Scrum etc.) that share similar values and principles, such as delivering high value, high quality software early and often. They are lightweight approaches that encourage continuous learning and are marked by their ability to create increased business and IT collaboration.

While each of the methods that form the family of Agile processes has a similar goal, they achieve it through different practices. We have taken the best practices that we have seen work from all the Agile processes and put them together for clarity.

Values, Principles, Practices: Agile begins with a set of values that drives down into principles and then into core practices. This means that teams get a value-based process and system that is a translated into actual practice. The values of Agile centre on what makes any team tick – people. By focusing on people-based values, Agile immediately realises that you can have any process in place but if you don’t address people issues, you’ll never succeed. The principles then take the values to the next level, detailing some basic ideas the process is based on. Then come the practices. These are not new by any means. In fact, they represent some of the best practice in software development today. What makes Agile different is how these practices are put together.

The figure shows a basic representation of Agile best practices that we have distilled. The central circle shows practices that a pair of programmers works on daily. Moving outwards, the next ring shows practices that are performed by a team of developers. The outer layer gives us practices done together as one team – customers, developers, testers, business analysts etc.

Each practice relates directly to the core Agile values shown at the four corners: Communication, Feedback, Courage and Simplicity. That is, each practice gives us a concrete way to action Agile values and make them part of the process.

Developer Practices: In the inner circle we have developer practices that are carried out every day. Take for example, Test Driven Development (TDD). Nobody argues against the importance of automated unit testing to create robust maintainable software, yet almost nobody does it. Very often it is because developers have never been taught how. TDD teaches them how to drive their development through tests. This means quality is in-built and code is delivered already tested. Importantly, this also acts as an enabler to Refactoring, which ensures that we keep our code as clean as possible and provides valuable design benefits.

Why is TDD important? Well, where in the process of software development would you least like to find defects? At the end, before you deploy. And yet testing is scheduled at the end of the software process, where changes are the most costly.

Other practices in this circle include Pair Programming and Simple Design. Simple design really refers to simple, evolving design. So rather then designing up front for what we think we need, we design for what we know we need, keeping it simple and allowing it to evolve. Pair programming involves two programmers working on production code as a team. While many people have bemoaned productivity loss, studies have shown an overall improvement in productivity and quality.

Team Practices: Working outwards, we have team practices. For example, countless studies have shown that a key indicator of project success is the ability to deliver working software early and often. So we need to practise things like Continuous Integration, which involves knowing how to create a development environment that allows us to continuously build our software, integrate it and test it in an automated fashion. Other practices such as Coding Standards and Metaphor focus on creating a shared language amongst the team (both developers and the business). This is a vital ingredient in ensuring that communication is clear and productive. Practices such as Open Workspace and Collective Ownership look at creating a shared team vision. One of the goals of Agile is to create a sense of shared ownership and vision of the project for the whole team. Sustainable Pace fits into this team idea in that it discourages “hero” type working hours and recognises that teams are made up of people who cannot and should not work excessively – especially to the detriment of the project.

Project Management and Planning Practices: Finally, we come to the outer ring and project management and planning. Here we look at Release Planning, Small Releases and Iterative Development. Agile looks at developing release plans that are relatively small (usually three months) and comprise iterations (two week work ‘packets’). User Stories or requirements are written, estimated by developers and then prioritised by business people. The top priorities get into iteration one, which is broken down further into tasks, which pairs of developers sign up for. Acceptance Tests are defined by the business and ensure that developers know exactly what a given story is supposed to accomplish. In this way there is an overall plan that drives down into weekly and even daily plans. At the end of the iteration, the business re-prioritises and the process begins again.

Studies have shown that because of this high level of feedback, incremental development cycles are better because they produce software that matches customers’ needs and is more predictable than the traditional waterfall approach.

The other practices such as On-Site Customer and One Team are about close IT and business collaboration.

Software Craftsman: Software development should take a craftsmanship approach – a thinking, knowledge-based trade, part science, part engineering and part art, with people at the centre.

If we can agree this we need a process that supports craftsmen to do the best possible work. That means getting rid of obstacles in their way and valuing their craft.

Take, for example, the 1977 the Gossamer Condor, the first man-powered aircraft. When the Smithsonian museum in Washington DC asked for blueprints for the plane, the team responded: “We’re paid for flying figure eights, not drawing blueprints.” An excellent point: we are paid as software engineers to build software – not write documents. Yet, in most companies, software developers spend a lot of their time doing just that. Some documentation may of course be required but it should be thought of as “only what is needed.”

Agile processes like eXtreme Programming also provide the basis for teaching good software development practices like unit testing, test driven development and refactoring. They provide the structure for mentoring and cross learning and encourage continuous learning. Importantly, they are structured yet flexible enough for small teams to deliver really great software – and teach them something in return.

Agile methods are the most lightweight, flexible and people-based approaches that teams can use. As we have seen in our own work, more and more teams – both large and small – are learning how to extract the most value from them.

You can contact Sean at shanly@exoftware.com

[Interesting project or development? Let us know at eo@iap.org.uk!]

Comments are closed.