How to Transition to Agile Software Development

Print this article Print
agile software development

Agile software development involves building software iteratively and incrementally. The results of early phases influence the planning of later phases.

Choose First Project Carefully

Organizations must carefully consider which projects will be first to use agile processes. Managers may have heard of cases where agile methodologies have revitalized large, mission-critical projects on the verge of disaster. They might advocate using a large troubled project for their company’s first agile effort.

A safer approach would be to start with one or two small, noncritical projects and learn from the results. The experience gained from the pilot projects can be used to adjust processes or conduct remedial training as needed.

Gendel recommends breaking larger projects into components, with each component assigned to a different agile team and—ideally—represented by a single product owner. If the organization decides to create a product owner committee, a single individual should be designated as the committee’s voice to each agile team. This eliminates the possibility of agile teams being provided with conflicting information from different people.

Prior strongly advises getting a good agile coach. He believes coaches can provide critical training and guidance to agile team members and the rest of the organization. He suggests looking for “someone who has been through agile adoptions multiple times with multiple companies.”

An experienced coach has the ability to anticipate emerging situations and can help deal with cultural issues and backlash. Prior warns against hiring coaches who claim a perfect record of success, as they may not have dealt with adversity during a transition project.

Organizations should consider applying agile best practices to how they adopt agile techniques. Agile methods emphasize gauging progress during and after iterations. Decisions are made based on frequent measurements of performance.

For example, the Scrum framework includes regular team self-assessments of how well Scrum is being applied. Agile teams are either encouraged by seeing positive improvements in how products are delivered, or are challenged to find ways to improve unsatisfactory performance during the next iteration. The Kaplan Test Prep team applied these principles by defining a set of goals for its agile transition. These included delivering higher quality, greater value, improved time to market and increased satisfaction within the organization.

The team conducted a baseline survey before starting the agile transition to capture perceptions of how well it was achieving these goals and followed up with quarterly reassessments as the transition proceeded. Breyter reported that within six to eight months after the transition had started, significant improvement was shown in all areas, including faster time to market.

Subsequently, the survey metrics did not show as great an additional rate of incremental change. But, by adjusting the training approach, the team was able to regain the previous pace of improvement. Rather than mandate a predefined training regimen, the team empowered its agile teams to request their own topics, and it promoted a culture of empowerment, networking and collaboration.

Krumins-Beens believes the team’s forthrightness and the use of an incremental rollout strategy were critical to Kaplan Test Prep’s success. The team members admitted up front that agile methods might not be best for the company, but they would at least use the methodology to assess strengths and weaknesses in their software development methods. They realized that when process improvement initiatives attempt to change an entire company overnight, such initiatives often fail.

By embracing a pilot project approach to flesh out and demonstrate the effectiveness of the new agile processes, the team gained management buy-in and grassroots support. As a result, the rest of the Kaplan Test Prep organization adopted agile processes within six months.

Lawrence Mantrone is a management consultant who teaches graduate and continuing education courses in business at the NYU School of Continuing and Professional Studies. He is a project management professional (PMP) and a Certified Scrum Master. You can reach him at larrymantrone@msn.com.

This article was originally published on 2013-11-06
eWeek eWeek

Have the latest technology news and resources emailed to you everyday.