So you’ve adopted an iterative approach to software development. Every ‘N’ weeks your team delivers working software. ‘N’ is usually 2-4 but could be 6-8. The point is that the project is divided into a series of iterations or sprints rather than building everything and delivering all of it in one big bang.
Congratulations! Your software development team is agile — or maybe not. We need to take a closer look at how the work is being broken down into chunks and spread out among the iterations. Let’s begin with a few basic assumptions. If you’re not doing these things, you’re not agile.
- The team includes a test function (i.e. there isn’t a separate QA group)
- The team delivers working software at the end of each iteration.
- There is a backlog of work items to be done.
Sounds good, right? But wait, let’s examine that backlog. Agile software development teams are strongly encouraged to define their work chunks (e.g. user stories) as vertical slices through the software system. This approach helps in growing the system little by little. It invokes the principle of progressive refinement — the software becomes more comprehensive sprint by sprint.
Unfortunately, many teams don’t approach the work effort this way. They begin by defining a set of software components that will be built semi-independently and ultimately joined to construct the system. They then build and test each component during separate iterations and deliver them as completed units.
Here’s the problem. The software won’t function in a useful way until nearly all the components are delivered. Thus the deliverables at the end of each iteration are largely useless to the business. The components don’t accomplish anything individually. They need to be integrated into a whole system to be useful.
This component approach is iterative but it’s NOT agile.
Go back and take a closer look at that backlog. Think about user activities (or business process flows). Those are your work chunks (i.e. stories). Map the activities to your software components. Then, isolate specific functionality within each component that’s needed to support the user activities.
The goal is to build out components little by little and as needed. This way the team will deliver functional software at the end of each iteration and the components will be progressively refined. That’s agile.