Agile Development in a Nutshell
The traditional approach to software development is the waterfall model, where the project flows through the sequential phases of conception, design, construction, and testing.
With this linear model, making changes to the specifications is exceedingly complicated and costly once the implementation has started. Since the beginning of the 21st century, agile development has become a strong contender to the waterfall model.
‘Agile’ was quick to become a bona fide buzzword, but people often get excited about the term without really understanding the concept. This may cause unnecessary friction at the beginning of a project. The client might be further confused by one supplier talking about Scrum, another about Kanban, and a third one about Lean.
Peculiar-sounding roles, such as Product Owner and Scrum Master, may also pop up. Simply put, agile development is a method that allows for construction to begin before the system is fully specified down to the tiny details. For obvious reasons, agile methodology doesn’t work with, for example, building construction. But it’s great for software development as it allows for both minor and major changes to be made to the functions and the architecture of the software throughout the project.
Scrum and Kanban are ways of managing agile projects. A professional software development supplier is able to adapt their operations to fit the needs of each project and client. Ensure that the supplier describes their operating model to you, at the latest in their tender. If you aren’t sure what a specific term means, don’t hesitate to ask. It’s not unusual that the definitions given by your supplier and Wikipedia differ significantly.
A backlog is a prioritized list of use cases and functions intended to be implemented in your product. It functions as the basis for a shared vision of the project contents and helps the client to review and prioritize the implementation of the project. Backlogs can be kept electronically or with Post-Its on a task board.
Agile development at its core is very simple: a developer picks a task from the backlog and starts working on it. When the task is completed, it’s labeled as done and another task can be selected. Repeat until the project is finished!
The backlog often goes through considerable changes during the project. A diligently maintained backlog is a prerequisite for agile project management. Project implementation is often split into one- or two-weeklong iteration periods (sprints). After each iteration, the development team and the client meet in sprint review sessions to discuss the results of the previous iteration and to plan for the next one. Meeting face-to-face (at least at the beginning of the project) boosts communication. Quick daily conference calls are also something we highly recommend. During these 5-10 minute meetings, the client and the development team briefly go through the previous day’s events and possible issues that have emerged.
Many suppliers also use some type of an online communication tool to allow the client to follow and take part in their internal discussions.
Agility and agile pricing models are futile if the project is not terminated after it no longer creates value. Developing new features just because you still have budget left is a fundamental mistake. This problem is often caused by corporate budgeting practices: if you don’t spend your entire budget, you’ll get less the next year. This kind of thinking must change for agile methods and pricing models to prove their true value.
The best practice would be to agree that the client is entitled to put an end to the project after each sprint. Does this sound harsh? In reality, a well-maintained backlog and regular meetings between the client and the supplier give early indications that the project is coming to an end. On the other hand, swift changes in the client’s line of business may suddenly render the project irrelevant. In preparation for such an event, the parties may wish to agree upon a reasonable one-off compensation.