Having troubles introducing Agile Development on your custom software development projects? Why not try moving to it gradually?
Implementing an Agile Development methodology on a custom (or bespoke) software development project can be difficult and many organizations new to the agile methodology struggle to adopt it. One of the big ‘problems’ with Scrum (a flavour of Agile Development) is that project-related issues come to the surface early because the team must deliver potentially release-able software within a month. Those issues in combination can seem insurmountable to those new to Scrum.
Typical issues/obstacles that arise include:
- Lack of business ownership and the inability to make decisions,
- Limited business buy-in into the concept of Agile,
- Team communication, individual skills, and team fit,
- Lack of trust in the team by the business.
In a traditional (waterfall) project, the team can spend months on design and when development begins they may start with the low complexity features, thereby not identifying issues until it is too late; forcing the project to run over-budget and/or delivering a solution that doesn’t meet the users’ needs.
When introducing Agile Development, organizations often attempt to tackle all of these issues head on and get overwhelmed with the new methodology, then choosing to revert back to what they are familiar with.
Why not introduce Scrum in stages to enable an organization to deal with issues one at a time and gain the benefits associated with solving each issue gradually?
Based on my experience as an Agile/Scrum Coach, I have found that introducing each stage below gradually over a number of months can work effectively for an organization that is struggling with Agile Development.
This article outlines a number of stages that a project team should go through in the introduction of Scrum. Each stage is summarized and then outlined in more detail below.
The first stage introduces prioritization of requirements, focusing only on the highest priority ones within a time-boxed two week sprint. Introducing prioritization can be difficult and issues with lack of business ownership and inability to make decisions must be overcome to enable you to complete this stage. The benefit gained is the ability to re-focus based on changing priorities.
At the second stage, you will overcome the obstacle of gaining business buy-in into the concept of Agile Development and ensure that the business agrees that quality and high priority business requirements are the top priority – over a detailed plan. You will have introduced estimation based on story points which will give the business improved control of the project in making decisions related to priority.
At the third stage, you will ensure the team is collaborating more closely; overcoming team communication and development skills deficiencies. You will have reduced the number of defects and the team will produce higher quality software quickly.
At the fourth and final stage, proper user stories and acceptance tests written by a Business Analyst will be introduced and the software will be frequently demonstrated to users so that their feedback can be incorporated. The business must learn to trust the team and agree to minimal documentation and sign-off. Once complete, teams are able to deliver software that is more closely aligned with what the user wants.
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 Development 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.
Comments