Moving Gradually to Agile Development and Scrum

Each stage is outlined in more detail below:

Stage 1: Focus on the highest priority requirements within a time-boxed sprint

In my opinion, the biggest benefit to be gained by introducing Agile is the ability for a project team to re-focus based on changing priorities (and changing requirements). To gain this benefit, the first step is to focus on only the top priority requirements in the first two week iteration (called a sprint in Scrum).

Work closely with the business representative to ask the simple question 'what happens if we don't do that?' For teams that are less Agile, they will quickly realize they are working on a number of low priority requirements that do not necessarily provide much up-front benefit to the user.

The main goal of the initial prioritization should be to identify the minimum number of features required for the product to be released and demonstrated to the user. Teams can often think only of the end product that includes all features.

Once the first logical chunk of work has been identified, but before any development work begins, sit with the team to break down the requirements into tasks (referred to as sprint planning in Scrum). Get team members to commit to estimates so that everyone is aware of what they must do in that first time-boxed sprint. It is a good idea to use a board or software to track the tasks and ensure they are completed within the sprint.

The new focus for the business representative should be to document detailed requirements only for the next sprint (the next couple weeks). They must not spend a large amount of time writing specs for requirements that aren’t coming until the next release since this is often wasted effort as requirements and scope change.

Scrum features introduced at this stage

If you are familiar with Scrum, note that at this stage, we have not introduced many of the formal rules of Scrum. We have identified the Product Owner by asking the business to prioritize requirements using the Product Backlog. Prioritized requirements have been divided into a small chunk of work called a sprint and the team has performed sprint planning and committed to accomplishing their own tasks. In a future stage, they will commit to work as a team.

At the end of every sprint the software is released for testing. At this stage, I wouldn’t recommend attempting to release the software to testers multiple times throughout the sprint.

Issues overcome at this stage

Issues with decision making and business ownership must be overcome to enable you to complete this stage. It is often very difficult to identify the appropriate Product Owner who is respected by the business. In my experience with custom development projects, the best Product Owner is often a Senior Manager and therefore Business Analysts are required to represent that person at a detailed project level.

Developers always tend to under-estimate their work. When I start introducing Scrum I continually coach the developers to ‘over-estimate’ their tasks during sprint planning, but in the first few sprints individuals often over-commit as they get used to the concept of a time-boxed sprint.

Benefits gained at this stage

The business can see the return on their investment after a short period by gaining benefits from a scaled-down version of the product. After only a few weeks, the team has something they can release to the users. Because the team is only analyzing requirements coming within the next sprint, if those requirements change, the team can re-focus in a future sprint without the waste of business analysis on areas of the application that were not yet ready to be developed.