When I was completing my scrum master training with Jean Tabaka, we started the course with an interesting discussion on what we thought Agile development and Scrum was and wasn’t about. This discussion illustrated some valuable points for project teams that in today’s business world, have to be more responsive, flexible and creative when delivering software solutions.

Working software is the key measure of success

There can be a perception that there are no project tools, formal plans or documentation in an Agile process. However it is important to note that while the Agile Manifesto is all about

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The use of the term ‘over’ is important because it mean that plans, documentation and tools have a place in an Agile process, but are not necessarily the priority.

By adopting the principles and processes of an Agile methodology such as Scrum, project teams can deliver customer satisfaction and value by delivering working software on a frequent and regular basis (i.e. Sprints or iterations). To an Agile team, working software is the only measure of success.

Changing requirements should be welcomed

In today’s business world, the assumption that system requirements are fixed is no longer feasible, requirements change as business priorities and needs change. So an Agile process which welcomes changing requirements can enhance a customer’s competitive position.
This capability comes in part from;

• Maintaining a stable project team who understand the project goal(s), deliverable(s) and each other’s strengths and weaknesses
• Agreement on length of a sprint/iteration in which to deliver working software
• Planning each sprint/iteration by incorporating the requirements with the highest priorities

A stable project team is allowed to bond, work together and at regular intervals reflect on how to become more effective in delivering software. The best systems architecture and design can be devised by such self-organising teams and members are more motivated in such a team structure. Such teams communicate more effectively face to face rather than using specifications and other documentation.

This relates to the priority placed on individuals and interactions rather than processes and tools and also to the principle of customer collaboration rather than getting bogged down in contract negotiations and clarifications.

Sprints – regular delivery of software

By assuming a fixed time box, usually 2 to 4 weeks, to deliver software iteratively, the team has a fixed deadline to aim for. If any requirements are missed, they can be incorporated into the next iteration/sprint according to their priority. While there is an emphasis on individuals and interactions, tools such as sprint backlogs, burndown charts and product backlogs are very useful in such a process.

Another important Agile principle, emphasised particularly in the Extreme Programming methodology, is the continuous attention to improving the technical design and coding standards which not only improves system performance, but also increases system functionality.

Waterfall vs. Agile

There are assumptions within the waterfall approach that can give rise to problems;

1. In most, if not all projects, it is not realistic to assume that all information is known upfront. Circumstances change in life!
2. An emphasis on documentation doesn’t necessarily help with managing risk and it can generate a focus on delivering requirements that may be obsolete by the time of delivery
3. Changing requirements and changing code is not necessarily expensive especially relative to delivering obsolete requirements
4. Customer sign-off processes are not the only approach to managing risk and can generate acrimony between the customer and the project team

To sum up

Agile development principles are effective as they can provide;

• A focus on delivering working software applications
• An openness to changing requirements as priorities vary and also to re-examine work methods for the team to be more effective
• A commitment to delivering a set of features/requirements at the end of the sprint