Empower the Team

I am currently working for a company that is trying to implement an agile process. We have 2-week sprints, daily stand-ups, backlog, burndown charts… but each sprint we are struggling to deliver.

Thinking about the way we are developing, I have suddenly remembered a picture in The Neglected Practice of Iteration (Jeff Patton) that illustrates the difference between incremental and iterative development. Considering the story as our deliverable, we used to split it in increments (tasks). Each developer picked up a task (increment) and worked on it until it was DONE. Integration took place not long before the end, when there is just not enough time left for accommodating feedback from the QA and the business. The amount of work to be done in the last days of the sprint was simply overwhelming.

During a retrospective, we have agreed to take another approach: tackle each story in several iterations. For each story we identify the story backbone (essential functionality), additional features and aspects on which the business has not decided yet. The story backbone is addressed in the first iteration while additional functionality, business rules, UI special features are dealt with in further iterations. We are tasking out for each iteration, therefore tasks are much shorter. Each iteration involves TDD, continuous integration, deployment of perceived functionality and feedback from QA and the business. An iteration is DONE when the QA and the business consider the delivered functionality meets their acceptance criteria. This approach ensures early and continuous integration and feedback.

The advantages are immediate:

1. Enforces development discipline as it requires a proper Continuous Integration environment.

2. First iteration ends early in the sprint, usually within the first 2 days.

3. Provides constant feedback as the QA and the business can test the implemented functionality from the first days of the sprint.

4. Improves communication among team members: the team works in parallel on small bits of functionality and frequently integrates the work.

5. Improves team morale as there is a constant delivery of functionality.

6. Delays implementation of complex/open business rules and special UI features, as these are more likely to change.

7. Reduces waste by keeping QA busy and reducing bottlenecks through frequent integration.

We have applied this approach in our last sprint with promising results. There were some external factors that have influenced our previous sprint and it is hard to accurately estimate the impact of the approach. It does not depend exclusively on the development team… we need the business involved in the feedback process to drive our work. However, I hope this approach will be validated soon in our sprints.