Self-Assessment for Teams: How Agile Do You Really Work?
Self-organized, flexible teams that deliver faster and better results are a step forward for every area of the company. So it’s no wonder that it’s no longer just software teams that use Scrum or Kanban, but that agile transformation is affecting all departments and locations. But while the introduction of agile methods in isolated IT teams or small companies usually still works quite well, scaling often fails due to corporate culture and a lack of agile mindset.
A prerequisite for every learning organization is continuous self-diagnosis by the project teams: where do we stand and how agile are we working? How do we recognize where the project is burning (and why)? Where can we start to get better? With the “Team Self Assessment”, the scaling framework SAFe offers a method of joint learning by regularly reflecting on the status of strengths and weaknesses.
360° team radar in 5 dimensions
The structured assessment process starts with an initial retrospective — often when an Agile Coach or a new Scrum Master joins the team. The aim is to analyze more precisely where things are “burning” by evaluating five-team dimensions. Based on the so-called “Radar Chart”, the team members can prioritize the necessary optimizations and derive suitable measures for the next sprint.
Product Ownership Health
- Are the refinements and plannings structured?
- Does the product owner work collaboratively with the team?
- Is the prioritization of the product backlog items transparent?
- Does stakeholder management work?
PI Health / Product Backlog Item Health
- The team proactively interacts with other teams to overcome hurdles
- Are the product backlog items documented in a comprehensible manner and is the prioritization recognizable?
- Do the Product Backlog Items meet the INVEST criteria?
- Was the sprint goal achieved?
- Were the planned meetings (daily, refinement, etc.) structured and carried out as planned?
- Did you only work on the planned tasks or did unforeseen tasks arise?
- Did the previous sprint run without disruptions from stakeholders or unforeseen technical failures?
- Did the cooperation within the team feel good?
- Have you spoken to each other efficiently and sufficiently?
- In addition to the obligatory Scrum meetings, were there also meetings for lunch or during free time?
- Are problems addressed openly and do the team members help each other?
- Does the current status of the software correspond to the technical requirements agreed for the sprint?
- Was the software developed according to a definition of done, i.e. is it sufficiently tested and documented?
- Is the software accessible to the product owner, the stakeholders, and the team in an integrated state on a test server?
The catalog of questions can be based on SAFe, but of course, individual adjustments to the respective team or project make sense.
Each team member assigns points between 0 (“never”) and 5 (“always”) in each of the five-team dimensions. Alternatively, percentages in increments of 20 are also common. The slips of paper are then collected, the points added up, the team average calculated for each dimension, and entered in the radar chart. Important: The points are awarded and the evaluation is anonymous.
Team self-assessments in practice
I have had good experiences with conducting a team self-assessment in every second or third retrospective. In this way, teams can identify negative trends in one (or more) of the five dimensions at an early stage and take countermeasures. In the long term, when evaluating the radar charts, a trend can be seen as to which measures and goals have positively or negatively influenced the cooperation and the quality of the results. An iterative optimization process is established.