Development methodology: Agile and Scrum
2 May 2012, by Chris Harris
A development methodology is a set of processes which can be employed to ensure quality, timeliness of delivery and confidence in the success of the project.
Every software project requires a development methodology of some kind, and picking the right one, and using it correctly, is vital to the success of that project.
There are a number of management methodologies employed in software development, with different strengths and weaknesses, and differing suitability to certain types of project. We pick the most appropriate methodology and create from it a set of processes tailored to the needs of a specific project, adding features from other methodologies if appropriate.
Sometimes the customer has a preferred methodology which we are very happy to accommodate. Left to our own devices, however, we recommend use of an Agile methodology based on Scrum. I’ve outlined the way we use Agile and Scrum below, but if you want more general information on how it’s used, these articles describe Agile and Scrum further.
High-level development process
Our typical Scrum based Agile approach breaks a project down into a series of ‘sprints’ of 2-4 weeks. The project functionality is divided into a set of ‘user stories’ each defining a piece of functionality from a user perspective.
Each sprint begins with a prioritised plan of which user stories will be worked on during the sprint, and the acceptance criteria for each story. It ends with a tested, working demo of those stories to the customer for feedback.
This approach has a number of benefits:
- Having demonstrable software from an early stage allows stakeholders to see the progress of the project.
- Regular customer feedback allows flexibility in refining or changing requirements as the project progresses.
- Frequent milestones and releases keep motivation high within the development team.
Low-level development process
Development work should always be split into small tasks, perhaps a couple of hours to a few days in length.
Every day the entire team will participate in a 15-minute, chairless meeting, during which they will summarise what they did yesterday, what they’re going to do today, and what might prevent them from doing so. The key benefits of this are:
- To increase communication between the team
- To provide more visibility of issues and progress
- To allow the team to assign tasks efficiently
- To alert the project manager to any potential issues ahead of time
Turning a set of customer requirements into a technical specification is an art in itself, and as such deserves an article in itself. Suffice to say for now that it is a vital step that should never be left out.
For one thing, part of the software developer’s job is to ensure that the software will solve the business problem that the customer hopes it will solve.
In addition, the more precisely you can determine the intended behaviour (including all possible use cases, error handling, user interface etc.) before you start, the more time you will save in the long run.
Developers should be encouraged to consider their unit tests at the low-level design (LLD) phase. This helps to focus on the genuine customer requirements and to expose any shortcomings in the design.
The best unit tests are automated and regressable – i.e. the tests themselves comprise code which exercises the feature in question. This also aids the system testing, which should happen prior to any release.
Testing takes place throughout the development process, driven by the sprint cycle and the regular releases to the customer. This ensures that quality is baked into the software from the start.
Softwire are extensive users of peer review to ensure quality of output. We peer review almost all of our code, documentation and designs.
The intention is for peer reviewing to happen at as many stages as possible. If a specification and low level design has already been checked over by a colleague, they’re unlikely to find any major issue with the final code. The code review itself will therefore consist of only a small number of simple mark-ups.