When trying to be involved in the concept of continuous improvement with your team, there are many things that can be used to help assess the successes and opportunities that exist for the team. There are even companies that their whole existence is hinged on the measurement of and charted improvement for individuals, teams and organizations. I want to very clearly tell you that with as many ways that there are to assess success, there should not be a single prescribed way to conclude that we are doing well or not with our Agile implementation. To the contrary, we should at regular intervals reflect on how to become more effective, then tune and adjust our behavior accordingly. We should be asking ourselves about potential outcomes, flow of work and the competency with which our teams are moving forward towards more successful ventures. Let’s jump into what that means when using assessments to measure our organizational and team’s agility.
When to do an assessment?
There are different levels of assessments to be conducted such as team retrospectives, team and technical agility assessments, Inspect and Adapt Problem Solving workshops and many other types of ways to determine how well we are doing as an Agile team or organization. The key for each of them is that we have consistency and regularity with which we are doing them. With a very basic level of an assessment, a team reflects after every sprint or iteration on how well they are doing, what is not going well and how they can improve. These retrospectives often times can seem very basic but they are the life blood of continuous improvement at the team level. Done well, a retrospective can help a team generate ideas and solutions for some of the most vexing problems and make them a thing of the past. The retrospective is intended to be something that generates the next ideas on how to improve so immediate correction can happen with things that may have taken us down the wrong path but also to continue on the path that has led to wild success for our team.
With that same sense of regularity, a team level assessment can be done to help the team look from a higher lens to see how they are overall applying principles and pertinent practices to become more Agile in their day-to-day activities. These type of Team and Technical agility assessments should never take the place of a retrospective but should help a team ask some deeper questions that are not necessarily revealed during a retrospective. It may lead the team to focus their attention on technical excellence and good design practices to enhance their agility. I have seen in many organizations this type of assessment is best performed on a quarterly basis. Done more often it doesn’t allow enough changes to really take root in core behaviors and practices that can make a difference in what is going on within the team. For organizations using SAFe, this oftentimes happens during the Innovation & Planning (IP) Iteration as it becomes one of the activities that feeds information into the Inspect & Adapt Problem Solving Workshop(s) at the Agile Release Train (ART) level.
What should be included in an assessment?
When deciding to conduct and assessment or set of assessments for teams and an organization, agreeing on what will be measured subjectively and objectively is crucial. I have been in organizations working with multiple teams where it seemed like the purpose of the assessment process was to standardize how everyone was doing Agile within their teams. Perhaps some of the best advice given during the podcast episode “Measuring our Agile Health – Agility Assessments & GROW” by Lee Henson is that a dogmatic, standardized approach may get teams looking alike but they quite simply don’t and shouldn’t all operate the same. We need to make sure we are measuring adoption of principles and not just prescribed practices that may not apply. I can remember a specific organization I worked with a few years ago that we had to create a separate assessment to measure practices with teams using more of a Kanban approach instead of Scrum. Ultimately, we moved towards a more open way of having the teams measure themselves on various factors that opened lines of communication as to how the team could improve in different areas instead of always being prescriptive. I recognize that this leaves more open to subjectivity, but that should always be a factor when doing an assessment because we are dealing with individuals and their interactions with each other on a team instead focusing on a single process or tool to be the catalyst for our improvement. This being said, a simple structure is usually the best to use such as the GROW method explained further in “Measuring our Agile Health – Agility Assessments & GROW”.
Goal – Desired Outcome
Reality – What is the current reality?
Options / Opportunities – What Options are available to us?
What WILL we do – What steps will we take to get us closer to the desired outcome?
So, what else do we include? Anything that helps a team judge for themselves how well they are implementing Agile principle and practices. It could be as simple as having the list of the 12 Agile Principles and a 1 to 5 scale on how well they are doing at applying them. It can also get more specific such as using a Team and Technical Agility Assessment or a Business Agility Assessment as recommended when using Scaled Agile approach. Any of these approaches needs to leave the results open to interpretation and discussion instead of just being a simple assessment with only Yes and No answers. Those type of polarized assessments serve a purpose of applying the rigor of practices, but they do not instill the mindset and empowerment that comes with assessments that leave more open to discovery and discussion. As mentioned in the podcast episode “The List of Agile Metrics – Part 1”, the purpose behind measuring anything is for the team to have that feedback cycle loop so they can learn and improve. If the audience ends up being anyone other than the team that is empowered to act upon the outcome, it will not have as far reaching of an impact on team improvement.
Can you overdo assessments?
Quite simply stated, assessments are just one tool to be used to help teams and organizations improve. Many people will hate to admit it, but as an Agile Coach I have gone through times in my career when I have used an official assessment too much. I have seen times when the entire focus of a coaching engagement becomes charting improvement of the assessment numbers. That’s definitely when the focus has shifted from where it should be instead of being honed in on things such as customer satisfaction, NPS and team happiness as mentioned in “The List of Agile Metrics – Part 2”. We need to make sure that assessments are encouraging the value that comes from early and continuous delivery of valuable solutions as those solutions we deliver become the primary measure of our progress.
If you find yourself wanting to do a larger assessment other than a team level retrospective more often that every 4-6 sprints or iterations, you are probably doing it too frequently. The fatigue that comes with over assessing your teams and organization typically displays itself with bitterness towards the underlying Agile approach being taken or even worse yet bitterness towards the individuals helping to “complete the assessments”. Anything we can do to keep the tuning and adjusting of behavior regularly from becoming an undue burden but instead being a welcome addition to the way that the team operates is ideal.
Keep it Simple – Assess, Reflect and Adapt
As we find increased need to show the improvements of our teams during an Agile transformation, don’t forget there are many ways to measure the WHO, WHAT, WHY, WHEN and HOW pointing towards our success. From “Metrics, Statistics and Other Agile Voodoo”, we need to always ask about the intended audience of whatever we are assessing or tracking. See what the information reveals and reflect on what that means for how the team is improving or regressing in different areas. However, in no way should you ever impose THOU SHALT’s on an Agile Team when you are simply using different forms of assessments to help them adapt what they are doing as a team to become more self-organizing. That is the outcome or goal we are looking for here. We are looking for any team to be able to see how they are doing, ask where they should be and take steps towards that more desired state so the product or solution they are creating becomes better as a result of the team improving their own state as a team. Opportunities will arise for coaching and leadership in the paths the team takes, but that will come because they seek it out to become better in the behaviors, principles and practices. May we guide teams to have successful assessments and by so doing have a better more self-sustaining organization.
Comments