One of the biggest benefits of using the scrum methodology for custom development projects is that you get a piece of working software at the end of each iteration. The way the process works is that your user stories—which comprise the overall vision of how the application will work in a real business setting—get incorporated into a plan for a series of smaller subprojects called sprints. Before and after each sprint, planning and review meetings determine which user stories are the highest priority, so the project is always tackling the next most important function of the application under development. And the goal of every sprint is to produce some deliverable that can be demoed for you to evaluate. What this means is that, though the early products may not be of much use in isolation, it’s always the most critical functions of the application that are the first to be built. And you won’t have to wait for the entire project to be finished before you can use the parts that have already been delivered.
But since the software is built in increments, you need some assurance that each of the parts that comes online along the way can be seamlessly integrated into the existing whole. The way to do this is to focus on clean code.
To get all the pieces to fit together as the software grows over multiple iterations, you want to make sure each of those pieces is as simple as possible. The idea behind clean code is that each stretch of code performs just one task, with no extraneous elements. If a piece of code is designed to serve multiple functions, it’s much more difficult to change or add any new components without making several other unintended alterations. The pieces are too complicated, and the way the pieces interact with each other is too complicated. If you tried to integrate the products of several sprints built with poorly developed code, the result would probably be a huge mess.
Limiting each component of an application to the bare necessity of performing one designated task is known as the single-responsibility principle. And the most effective way to ensure adherence to this principle is Test-Driven Development. With TDD, you create what’s called a unit test before you begin writing the functional code. The unit test gives you either a red or a green light to let you know if the code you’ve written performs the one task that’s required of it. Coding to the test like this narrows the developer’s focus to that one function, eliminating the temptation of tackling multiple functions at a time. As software architect Jon Fazzaro explains, “When you’re testing one thing at a time, you’re only writing one thing at a time. And so that single-responsibility principle just kind of naturally falls out of it.”
The result of TDD is code that’s not only resilient and easier to upgrade but that also plays nice with other code. You can think of single-function pieces of code as square blocks, and every extra function would add another side to the block. It’s much easier to put a bunch of six-sided blocks together to form a larger structure than it would be to build it using eight-sided blocks.
Scrum and TDD
The scrum methodology takes into account the difficulty of working out a comprehensive vision for a project at its outset. You can tell a developer exactly what you have in mind, and the developer can describe back to you something that sounds like what you need. But then at the end of the process the application that gets delivered doesn’t work quite the way you imagined it would. This could be owing either to poor communication or to the complexity of most custom software projects. With scrum, though, you break the large and complex project down into smaller and more manageable units. And you have a chance to get your hands on the products that result from each of these iterations. At the end of each sprint, you meet with the developers and provide feedback on the deliverable, which gives you an opportunity to change the direction of the project before it goes off in a direction not to your liking.
There’s an analogy to be drawn between the multiple iterations of scrum projects and Test-Driven Development. They both follow the principle of breaking larger, complex tasks down into smaller, more manageable parts. And they both focus on working in short bursts to produce products that will be immediately tested. With TDD, the test is functional. With scrum, the test is whether the product owner is happy with the software.
At any rate, what everyone in the custom software industry is quickly moving away from is the model that has business users and analysts working out a lengthy list of requirements to be turned over to the developers, who then disappear into their coding lair for several months before returning with a finished product. The statistics on the failure rates of this approach speak for themselves. Only about a third of projects following this old model succeed. That’s why methods like scrum that call for more focus, multiple iterations and tests, and more collaboration between business users and developers are gaining in popularity.