Once an organization has bought into and initiated its transition to Agile, it is important to take measured steps in order to maintain the organization’s transition momentum. In most instances development team members will want to tweak, tinker with, or change things within the Agile process that was originally rolled out. Even though the suggested changes are usually well meaning with the intent of improving the Agile process, these changes can actually sidetrack your successful implementation of Agile before it has time to take root. Making changes immediately after Agile’s implementation is akin to asking a mechanic at a dealership to change the tires on a new car during your initial test drive. How do you know what needs to be changed until you’ve learned all of the nuances associated with the new car, or in this case your new Agile process?
One of the most effective ways of dealing with this is through the setting of goals associated with the new process. Asking the development team to meet certain goals before suggesting and making changes to the newly implemented Agile process helps the team learn the entire process and learn what will and won’t work before changes are made. One example goal is to require that the development velocity increase by 200% before changes are made. Other mangers require X number of development or scrum cycles to be completed before changes are proposed. Most often though asking the team to meet a performance improvement goal works best. Performance goals encourage the team to become completely dedicated to Agile’s success while simultaneously demonstrating Agile’s value to parts of the organization not directly involved with the newly implemented processes.
In following the decision to require certain goals be achieved before making changes to the Agile process, it is equally important capture suggested changes as soon as the team brings them up. At the end of each sprint a Retrospective is usually held. This is the ideal time to discuss process changes, document what the suggested change is, what event generated the suggestion, and how critical the change may be to the success of the Agile process. It is also suggested to update the team during the Retrospective with their progress towards their goal. As the team gets closer to achieving the performance goal necessary for changes to be made review both current and previous improvement suggestions. This initial settling in period before implementing changes will help the team properly identify improvements that will provide the biggest benefit to the team. Issues that occurred once and appeared critical at the time of occurrence may be proven to be either minor or a non-issue once the team has become more comfortable with the new Agile process. This settling in period will allow the team to review all of the suggested changes and chose which improvements are best suited to help the team achieve long term success.
However you chose to implement Agile it is important that you take definite steps to ensure Agile is not derailed before it has a chance to succeed. Delaying process tweaks, unless something is an obvious and undeniable roadblock to success, will help ensure your success and the success of Agile.
About the Author:
Mark Townsend is a Senior Business Analyst with OneSpring LLC (www.onespring.net) in Atlanta Georgia. Mark has over 15 years of experience in Process Design, Business Analysis, Product Development, and System Implementation.