OK, so you’ve read the books, been to some conferences, talked to some experts, and now you’re ready to start migrating. If you are migrating one team you may be able to identify a scrum master, toss a book into the team room, put up a cardboard story board, and check back in a month. Larger enterprise migrations require much more planning and education. This article is not an exhaustive treatment of enterprise Agile migration, that subject can fill volumes. But, I’d like to give you some things to consider as you are planning and executing the migration.
The entire organization will be touched by this migration, but two roles are critical to the success of the project. The first is a management sponsor that has the ability to influence the teams that will be implementing Agile, and the stakeholder organizations that may be impacted. The second key role is an Agile coach that has a thorough understanding of the process to answer questions and the guide everyone on the journey. This may require multiple people to fill these roles.
Draft a Plan
By drafting a plan for the migration you can use it as the basis for talking to your stakeholders and the people that are key to the implementation. Elements of the plan should be:
Benefits and goals – It is important to understand what you want to achieve with the Agile migration. Being able to articulate these goals and benefits will help with the rollout as you talk to employees and stakeholders.
Training plan – identify the groups that need training (team members, management, stakeholders), identify the source of that training material, and identify how and when it will be delivered.
Scrum team staffing plan – what teams will exist, what is their membership, who is the scrum master, and identify other key roles such as product owner and customer. It is also invaluable to have Agile advocates identified on each team to help the teams deal with the challenge of change.
Timeline with milestones identified – Include such items as training delivered, scrum teams formed, begin sprints, first release deliverable, etc.
Release and deliverable planning – Describe how your internal and customer deliverables will change with Agile.. Changes could include new timelines, different content targets, modified customer validation, etc.
Facilities changes – Where will the scrum teams reside and are those rooms conducive to Agile. They must include tables, story boards, and projectors for rapid information sharing.
DevOps – Do your current development operations support the proposed sprint plan? Can a team realistically build, deploy, and test software rapidly enough to support working code at the end of the sprint.
Once you have a plan drafted, you can begin to share that with customer, employees, and stakeholders.. Be open-minded to feedback and be prepared to make any changes suggested during these discussions. Remember, these people know their jobs better than you do. You can also use these meetings to determine the level of buy-in from these groups.
Customers – It is important to identify your customers and educate them about the changes that are coming. You need to find out from them what they are getting now that is important and what they can live without in Agile. You can also ask for their ongoing involvement in the process, they will appreciate this opportunity to provide input.
Employees – This group needs to understand the mechanics of the migration and proposed timelines. Be prepared to answer the “WIIFM” (what’s in it for me) question. Benefits to them should be more predictability, less disruption to schedules as the software requirements evolve, faster feedback through working software, and more customer involvement throughout the development cycle.
Internal stake holders – Important stakeholders are customer support, computer center operations, sales, and marketing. This group needs to understand any changes to the software release process that might impact them. This is also an opportunity to solicit their involvement in the process and perhaps join a scrum team.
The mechanics of the migration will be spelled out in the plan you’ve created. The basic framework should look something like this:
- Form scrum teams with scrum masters, move teams into team rooms.
- Execute the education plan to train the teams on the mechanics of Agile and Scrum.
- Begin sprints. Be sure to hold a daily scrum of scrums during the migration to track progress and identify challenges that the teams are experiencing.
- Schedule the team report-outs and demos. These should be held on the last day of the sprint to assess progress.
- Create and update key metrics. Such stats as stories completed and defects will allow you to evaluate productivity and quality.
Finally, be prepared for Agile to uncover underlying organizational issues. If you find that teams are not meeting their sprint goals, it could be that they are experience significant blockages and inefficiencies. Don’t be quick to conclude that Agile is not working. It may be doing you a favor by exposing this problems.