Does it really matter if your Agile implementation is not ideal or complete? It does. However, it is more about the journey than the destination! Knowing your limitations and weaknesses will help you improve towards the goal of being more agile. In other words, it is important that you continue to inspect and adapt.
There are multiple tools to help you evaluate the current state of your Agile process [1,2]. The one I have used is the Nokia test [1]. It is not a perfect measure of where you are, and the scores can be debated. Agile processes are too complex and subjective to summarize to a single number or score. So focus on big areas and not on specific scores.
A good analogy is If you were trying to measure someone’s body temperature. The Nokia test would be closer to putting your hand on someone’s forehead than to using a thermometer. It will give you a sense of how above normal the body temperature is, but it won't tell you if it is 103F or 104F.
In 5 years using Scrum, our team has gone through multiple adjustments. Sometimes these adjustments were necessary because of internal factors, but most of them came from external ones (Reorganization, skills available, etc.).
It’s sad to say, but there were phases of our team where our Scrum implementation was almost perfect, but right now it is what Sutherland would call "Scrum Butt".
The Nokia test allowed me to perform a sort of Strengths, Weaknesses, Opportunities and Threats analysis [3] (SWOT). It showed me where our process is strong and needs to be nurtured, but also where we are weak and need to shore up support.
Not surprisingly, our weaknesses are on areas we thought we shouldn’t play a role. For example, we have a QA department that doesn’t report to the team, so QA practices are not considered seriously and left to that department to manage. We are working with the QA team on improving our common work practices.
Another area where we were weak was Agile Specifications. We don’t necessarily have Business Analysts on staff, so we are now using developers on creating these. Remember, Agile promotes specializing generalists.
As it is the case with iteration retrospective, perhaps we should invest on doing process retrospectives. It should not be as often as the iterations, but often enough to have an impact on the project.
A source that was very helpful as I created these action plans was John Little’s blog series on the Nokia test [4]. It helped me create persuasive arguments to present to the other teams involved and upper management.
Using an external tool helped me take a step back and assess where our team is in our journey to being agile. It was a great experience that I intend to repeat more often.
References:
[3] SWOT link