- team composition (e.g., more Agile friendly types).
- Determine capability of team
- This involves evaluating the team’s capability in applying Agile. It is important to determine what skill sets you have on the team and the team understanding of implementing Agile. This allows you to determine the type and level of Agile and engineering training that is needed by team members
- Assess engineering practices and Agile mindset of the team
- This is to determine what engineering practices are being applied and how effective they are. This also assesses how Agile the team may already be in the approach they use to software development. This is applicable to existing product teams who have a release already under their belt. This allows you know which engineering practices are team strengths and which need improvement.
- Identify an Agile Coach
- Your coach should be an Agile professional experienced in applying and executing Agile methods and practices on product teams, with the capability of completing the tasks included in the readiness phase. An experienced Agile Coach will increase the chances of a successful Agile adoption.
- Establish a strategy and plan for implementing Agile
- Much like a backlog and Sprint Planning, this is where you establish a prioritized list of tasks and implement them within a sprint context (e.g., Scrum) or continuous flow context (e.g., Kanban). Consider using the tasks in this article as a starting point. This should be initiated by discussing the goals of the Agile adoption effort with the team to ensure their understanding. This will help make certain that the work is planned and prioritized effectively.
- Establish periodic progress meetings
- Much like like the Daily Stand-up, this is where the team or at least a core group meet regularly to assess the progress of the prioritized tasks. This ensures that there is a focus on an effective adoption of Agile
- Establish Agile Roles amp; Organization
- This is where we structure the team into appropriate Agile roles (e.g., Agile team member, ScrumMaster, and Product Owner) and determine if more than one Scrum team is needed (e.g., multiple Scrum teams that make up a large project team). This may require some restructuring to reduce functional relationships to improve team empowerment. The purpose is to ensure that we have a organizational structure that is most suited to Agile.
- Determine Stakeholder support
- This involves identifying which stakeholders (e.g., Senior Management) are the Agile sponsors, then determining how supportive and Agile friendly they are. Identifying their level of support allows you to be aware of friend or foe, potentially increase the level of Agile knowledge and support of the stakeholder, and be aware of any risks to Agile support.
- Establish the Agile methodology and practices framework
- This involves building a set of Agile practices (e.g., Sprint Planning, Story Writing, Daily Stand-up, End of Sprint Review, Retrospective, Scrum of Scrums, Continuous Integration and Build, etc.), techniques (e.g., sizing, etc.), and criteria (e.g., “done”, acceptance, etc.) for the product team. This also includes establishing an Agile framework that works within the governance context of the organization. The result is that the team will have an Agile structure to begin with and can hone practices and process over time. This can also be used as the basis of Agile team training.
- Consider Agile tool needs
- This involves determining if Agile tools will be part of the initial Agile deployment, and what tools may be used to help you get started. An Agile tool evaluation is typically in order unless there are already defined Agile tool standards within your company. Agile tools are commonly thought of as Agile planning tools , but
Agile Adoption Roadmap