The Agile Radar: An Approach for Understanding Agile
Here's a new tool that you and your team can use to better understand constructing an Agile mindset.
Join the DZone community and get the full member experience.Join For Free
When coaching and training people on being Agile, we have often used the fabulous Agile Onion  from Simon Powers of Adventures With Agile. This is an amazing offering and has really helped us to coach others to be the best that they can be, time after time.
However, over the years there has been a couple of common observations that have constrained the wonderful impact it could have.
The first observation that caused some confusion is the use of parentheses which could be seen to indicate segmentation between "Doing Agile" (Tools, Processes and Practices) and "Being Agile" (Principles, Values and Mindset). As a result, we have sometimes heard people raise the question, "Does this mean I can carry on doing Waterfall but with an Agile Mindset?"
Having done some of our own research and spoken to Robert C. Martin and Arie van Bennekum (both Agile Manifesto authors ) about this, they have both said this alone would not Be Agile. According to them (and we agree), you have to "Be" all of the layers of the Onion to be Agile. Also, in turn, for example, we are not sure that the rules of the Scrum framework could be adopted within a Command and Control organization. Therefore, the segmentation by parentheses does not work and it is hard to justify when queried on this.
What are your thoughts on this? Can you "Be Agile" without "Doing Agile" first? Can you have the mindset alone without the practices?
In our coaching and training, we have often responded to this issue by adapting to simply removing the parentheses text of the diagram and sometimes adding in the excellent ShuHaRi  concept instead.
The second observation that was often highlighted by people is around the metaphor of an Onion. If we look at the diagram we can see that the arrow line indicates that Mindset is "Less visible, yet more powerful" and Tools & Processes are "More Visible, yet less powerful." This makes sense. However, as has been pointed out to us many times, on an Onion, it is the outer layer you see as the most visible first!
We felt from our own view that it was impossible to resolve this in regards to the diagram, as the metaphor seems to contradict the learning intent. Upon further reflection, I considered the coachees to be correct in their observation.
Probing further, we looked at a similar approach with the Agile Planning Onion  with which we made a massive assumption that the Agile Onion was based upon (we could be totally wrong on this). Here we can see that maybe the "Strategy" outer layer could be easily seen first depending on your point of view. Therefore, this approach to planning we feel works well and the idea of an Onion to represent Agile ideas can work depending upon the situation. We could be wrong; as always, it depends.
After experimenting with different metaphors and models we have settled upon the "Agile Radar" (which we have made a free open source diagram and released it under a Creative Commons License ).
This, we hope, will help people understand what Agile is and how "Being Agile" is not the same as just merely "Doing Agile." It should be noted that this is not an Agile health-check tool or any other type of assessment that is so often associated with Radar charts. It is just a diagram to elicit insights into what Agile is. If you wish to use it or not, or how you do this, is entirely up to you.
The optional first diagram is attempting to show the various attributes of Being Agile. Thus "Being Agile" was added to make the statement of intent clear over Doing Agile. "Being Agile" is the central core focus of all the layers regardless of states.
As our visibility radar reaches further from the core of "Being Agile" we pass through spheres of influence. That influence can be "more visible" the easier you can see it, but as we know, "less powerful," and then the further its reach of influence travels, the "more powerful" it becomes but "less visible" as it is further away, until we reach the all-encompassing sphere of "Mindset." Thus, the larger the area the more powerful its impact can have.
The abstract concept is reinforced as all-encompassing with the right-hand side showing that the "Mindset" is further in its reach as a Radar scan traversing across all the areas. Hence, the concept name "Agile Radar."
The second diagram is an optional extra. Whereby ShuHaRi is added to show that a Mindset needs to be developed on a journey.
However, ShuHaRi has some historical issues and makes the diagram more complicated so it is not for everyone.
An optional third diagram adds new element "Beliefs" which for some bridges the gap between the Agile Values and Mindset. Agile "Beliefs" can include the improvement belief, team belief, people belief, and complexity belief.
With all these options available the choice is yours.
The last one has been intentionally left blank as this allows a coaching/training opportunity , in that the participants can be presented with the attributes on cards or write the elements on post-its and then in groups or pairs place them on the blank version of the diagram where they think they should reside and is relevant to them.
From here the facilitator can coach them with powerful questions on their personal but also valid reasons behind this and afterwards do a reveal to share insightful learnings to all.
In addition to the "Agile Radar," as a difference to the Agile Onion’s "Tools and Processes" we decided to align closer to the Agile Manifesto’s first value word order of "Processes and Tools" by putting "Process" before "Tools" on the diagrams. We then adapted as additional learning by limiting "Processes" to the singular to entice people to reduce (but not eliminate) a reliance upon "Process" alone.
Agile Onion by Simon Powers, 2016
"ShuHaRi" article by Martin Fowler, 2014
Agile Estimating and Planning by Mike Cohn, 2005
With special thanks to: Simon Powers, Arie van Bennekum, Robert C Martin, Martin Fowler, Mike Cohn, Scrum Alliance, ICAgile, Creative Commons and the The Agile Community
Opinions expressed by DZone contributors are their own.