Agile Self Assessment

http://blogs.atlassian.com/2013/11/enterprise-agility-maturity-matrix/

 

The Enterprise Agility Maturity Matrix can be used to set transformation goals, monitor progress, and get everybody on the same page regarding Agile including: Agile Coaches, team members, managers, and senior leadership. This tool has also been used in many other creative ways, such as to focus retrospectives and to help people at all levels do a self assessment of their own understanding of Agile so as to encourage self-paced learning and open people up to learning from folks that may have more Agile experience.

The tool is a spreadsheet with a section for describing the organization as a whole and another section which is for describing individual teams. There are a number of Agile indicators for each section and each indicator ranges from a ‘0’ (impeded) to a ‘4’ (ideal). For each cell in the matrix, there is a simple English explanation of what it means to be at that level for that indicator. The goal is to get as many indicators to a ‘2’ (sustainable) as possible. This helps the organization understand when they are over the main hump of adoption so that they don’t stop investing in the adoption too early. If not enough indicators get to the sustainable level, the organization will likely backslide to its old ways.

This Enterprise Agility Maturity Matrix was initially developed by a large group of Eliassen Agile Coaches that have had experience with Enterprise Agile Transformations at a wide range of organizations. Over the past six months it has been more widely disseminated via seminars and webinars, and has been refined based on the input of people who have downloaded it and provided feedback. We are now making it even more widely available via this blog, and look forward to your feedback. We will continue to provide additional information on how to best use this tool in future blog postings.

 

Category	In transition (1)	Sustainable (2)	Agile (3)		Comments	Owner
2-Impediments		Raising impediments is becoming routine and there is a high degree of comfort in doing it. Impediments are usually resolved. Root cause analysis is sometimes performed and there is a growing recognition of its value.	Impediment raising and resolution are a cultural norm. Individual and team impediments that can be addressed at those levels are addressed. Root cause analysis is frequently performed and acted on.	Current impediments can rise from team but haven’t track in high degree. Root cause analysis is not frequently performed.	Scrum master
2- Definition of ready		There is a fairly good definition of ready which resulted from the collaboration between multiple members of the team. Definition of ready includes existence of acceptance criteria	There is a strong, clear, comprehensive (yet simple) definition of ready which resulted from the collaboration of most of the members, agreement and input from all, and it is publically posted	Definition of Ready didn’t fully understand by PO side and team always urge for AC.	PPO:
2- Story size		It is apparent that story size is having an adverse effect on the process	Team has a rule of thumb encouraging small stories	Story still not small enough for team and hope can split more
1-Progress tracking	Progress is tracked and known using burnup, burndown, CFD or similar method and sometimes used to influence behavior	Progress is tracked and frequently influences the behavior of the team	Progress information usually influences the behavior of the team	Progress is tracked by CFD, but team didn’t use to influence team behavior usually.	Team
1-Test automation	30%+ code coverage via test automation and plans are in place to increase this level	50%+ code coverage for all new user stories via test automation	50%+ code coverage via test automation	Test automation can’t follow the step of implements; automation script should be part of code release from Team and making sure multiple members can work on one story.	Team
ATTD should adopt to make sure Acceptances Test ready after AC is clear and mark is as a basic testing entrance for UAT.	Team
1-Refactoring	Some understanding of single responsibility principle (SRP) and open/closed principle. Some amount of refactoring done as needed when implementing stories.	Refactoring around SRP and O/C principle. Doing the appropriate amount of refactoring with most user stories	Deep understanding of refactoring. True refactoring is a cultural norm.	Some amount of Refactoring done but Team didn’t how to appropriately abstract our design, which requires in-depth knowledge of OO design, pattern and refactor technique, etc. Need Coding Dojo as a platform to improve personal skill.	Team