The Key to Your Organization’s Readiness for Change: The Agile Assessment
“Change is Difficult”: a phrase most people can agree on.
It is also inevitable that learning to navigate change as an organization is required to stay relevant. Where “Being Agile” continues to be a driving force for some organizations, those who take the time to properly identify the areas that require the investment of time and energy before implementing a change (Agile or not) are far more successful.
No matter where you believe you are in your Agile journey, as the saying goes: “You can’t change what you don’t know”, the Agile Assessment is a key activity in establishing appropriate next steps. It provides the baseline required to determine if and when an organization is ready to evolve to the next level of practice or adoption. It can also provide data to leverage company change management abilities, show progress to secure funding or investment, support the need for training or coaching, or help to determine that operations are running as they should be.
With so many Agile Assessments already available, it can be overwhelming to consider which one can serve you best. Industry, type of product or service, technology, size of teams – the list of variables can exceed the number of assessments that are already available.
To help guide you into the right mindset, the following list of questions is a good start:
- Are the teams delivering?
- Are the teams consistently delivering?
- Are the teams consistently delivering value?
- Are the teams consistently delivering value that is sustainable?
- Are the teams consistently delivering value that is sustainable and predictable?
For those who are willing to dig a little deeper, I offer my own experience with establishing a unique but comprehensive assessment below:
Software development is creation, which by nature is not highly predictable or repeatable, as much as we’d like to try.
Like the scientific method, it is empirical and requires careful observation and rigorous skepticism about what is being observed. Additionally, the principles of Agile are mostly subjective in nature. Only 3 of 12 principles are immediately quantitative: satisfy the customer (ROI, NPS, # of users), deliver frequently (release schedule), and working software (defects). The key to the assessment thus becomes the ability to quantify the otherwise qualitative data – to move beyond the personal perspective and find commonality across your organization.
While constructing the assessment, it is important to keep the audience in mind.
It cannot be too long, or else you risk losing engagement and reasonable data. On the other hand, it cannot be too short, otherwise you won’t obtain enough context to properly draw conclusions. If the assessment doesn’t capture the change that is required, then employees will not see the value of the results or the change you are attempting to implement. This results in an unsustainable and ineffective process. An Agile Assessment requires an incredible amount of patience, a healthy amount of unbiased observations, and a meticulously refined survey that finds the optimum balance between concise and context to capture authentic feedback on the current status of your development process.
Drawing on the Agile Assessment list above, specifically the Nokia Test, Len Lagestee’s “How to Measure Team Agility,” Mike Cohen’s comparative agility survey, and my own experience with organizational transformations, I’ve constructed an assessment that can provide enough context to understand an organization’s change capabilities as well as the ability to deliver innovative value on a consistent and sustainable basis.
While a focus on team competencies is important, the main priority here is working software – the key measurement that not only proves your process is working but if it will translate into success (ie. money, more customers, deeper engagement, workforce retention). In other words, are you delivering something on a consistent basis, and do your stakeholders realize its value?
Before digging into each of the statements, it is important to note that this survey should (must!) be conducted in person. While it is far easier to gather this data via a link for folks to take at their leisure, the face-to-face conversation (see link to the list of Agile principles above) provides the context that is necessary to obtain an honest snapshot of your organization’s development process.
All statement responses below required the following scale:
1 – Strongly Disagree
2 – Disagree
3 – Passive
4 – Agree
5 – Strongly Disagree
There are many different theories on the “most effective” scale (ie. there should be no middle), but I’ve settled on defining the middle as “passive” and encourage folks to avoid it if they can.
Statement 1: Your team’s stakeholders are satisfied.
This statement provides insight into whether the team has a clear understanding of to whom they are delivering and if those clients are realizing the value. If the answer is “I think so, but I’m not sure who our stakeholders are” then a disconnect exists between the creator and the consumer. The role of the individual should be considered. A Product Owner must know this answer for example, but even the knowledge worker (engineer) closest to the product should have a general sense of who they are creating for. If stakeholder awareness is not an issue, then it is important to get a sense of the level of engagement– are stakeholders providing consistent and helpful feedback? If not, it is worth considering a stakeholder SLA to set the expectations for that relationship.
Statement 2: With regards to the development process, you would recommend your company as a place to work.
This statement usually requires some context, as there are many variables that could influence the response (ie. depends on the team, role, career path, experience). However, the insight gathered from the conversation far outweighs the potential ambiguity. Like the Net Promoter Score (NPS) that is used to gauge customer loyalty, this statement helps prove someone’s faith in your company’s development process. I found most of my interview time is talking through this question, and it helped me gain an excellent perspective into the actual development process.
Statement 3: Your team delivers value at a sustainable pace.
This statement could potentially be broken into two parts, “delivers” and “sustainable pace.” I’m interested in hearing about the individual’s perspective as well as how many unplanned triage situations the team is subjected to. If folks are being pulled out of commitments on a regular basis to put out fires, research unnecessary outages, or spend time on distractions, there is an issue with the process no matter how well it is defined. That’s not to say “fire drills” won’t occasionally happen, but when they are the standard it’s important to bring some awareness and definition to an acceptable threshold.
Statement 4: Your team embraces change.
Like other statements in this list, the potential ambiguity can lead to a lengthy discussion about how the team defines change and their response to it. I can obtain a strong sense of how “anti-fragile” a team is based on the response I hear. It also provides insight into the organization’s readiness for change, especially if I constantly hear “There’s too much change to embrace!” There are many factors to consider with this response– current process isn’t well defined, adhered to, or properly trained, but the details are quickly uncovered during the conversation.
Statement 5: You and your team understand the value and principles of Agile.
At this point most people, especially those working in IT, have at least heard of the word Agile. The issue isn’t about understanding the theory of Agile, but more about the team’s experience and successful application of it. The tone to this response is what I listen for. A quick and seemingly unengaged response will force me to lean in for more information. I won’t force anyone to recite the entire list of agile principles from memory (there are always a few engineers that can), but the language and situational examples used will help me gauge the application of its principles. Of all the statements, this one is mutually beneficial as it helps me refine the agile training needs of the team and individual coaching.
Statement 6: You are happy with your role on the team.
Similar to an organizational happiness index, this statement focuses on the individual’s role on the team and the organization. Are the expectations of their role defined and clearly understood? Are the behaviors and ultimately the value they are providing in alignment with the team and organization? This response can lead to opportunities for improvement that may be considered outside the boundaries of Agile (i.e. clearly defined performance measurements, transparent career path), but it is related to building projects around motivated individuals. “Quality people build quality things” after all, so while the responses may lead to “What does this have to do with Agile?” the result will lead to a better sense of how inspired the individuals in your organization are.
Each interview on average takes about 30 minutes with a quick follow-up to confirm each score and perspective was accurately captured. The results are then presented to the team prior to sharing with a larger audience. Once all identified teams have been interviewed, an aggregate of all the data is generated and displayed for the organization’s leadership. The final report will include a list of suggestions based on the data and context heard during all the conversations.
The value of seeing the assessment is tremendously helpful for both employees and leadership to understand an organization’s change management ability and the key to ensuring implementation of valuable and sustainable changes. As with any empirical process, the assessment should continuously evolve – but it is an important step toward establishing and realizing the next phase of your development process evolution.
By Patrick Wojtak, Agile Assessment Lead Consultant