Previously in this series I wrote that the principles of agile software development are more important than the development process (see Agile Software Development: It’s not a process). Consequently there isn’t just one correct way to do software development – the approach must be based on a careful examination of the needs of each project.
Consider two of the software projects that our R&D group has worked on this year:
- Development of a smartphone app to address a new market for delivery management
- Enhancements to our Distribution Management System (DMS) upon which many companies depend for their business operations
In the first project our goal was to rapidly develop a beta version of the software, get it in to the hands of users to capture their interest and feedback, and quickly evolve the software in response. Starting from scratch with a new design, our development team was small and intensely focused on this application.
By contrast, in the second project we proceeded much more carefully. A DMS is a very large piece of software and even small changes may have implications for the existing functionality. We thoroughly analyzed our functional changes before coding them, and performed comprehensive testing as we progressed. The development was conducted by a relatively large number of people, from the various teams who specialize in different areas of the product.
With these two examples in mind, consider this model:
The best approach to the software development depends on where in the model the project is situated. So the first of our two projects is in the lower-left quadrant as we want speedy development by a small number of developers. But the ERP enhancement requires focus on predictability, stability and the organization and co-ordination of several teams, so it is situated in the upper-right quadrant. Other projects may move through the model over time. I’ve shown a third example that begins with a small team working rapidly, but as the release date draws near the team expands to do more testing and the emphasis moves from feature development to predictability.
So once when the project is characterized and situated in the model the software development approach is chosen. Moving along the axis from speed towards predictability implies that the software development will involve:
- More up-front analysis instead of experimentation
- More testing (e.g. of edge-case scenarios, of scalability)
- Being more conservative in the design and the technology in order to reduce risk
Moving up the axis from small team to organizations implies:
- More documentation so as to facilitate communication
- Additional management structures (meetings, design reviews, project management systems) to co-ordinate multiple teams
To coin a phrase, this is situational software development: an approach that is adapted to each project and where it is situated in the model.