DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Last call! Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Is Agile Right for Every Project? When To Use It and When To Avoid It
  • Breaking Bottlenecks: Applying the Theory of Constraints to Software Development
  • How Agile Outsourcing Accelerates Software Project Delivery
  • Rebalancing Agile: Bringing People Back into Focus

Trending

  • The Cypress Edge: Next-Level Testing Strategies for React Developers
  • Event-Driven Architectures: Designing Scalable and Resilient Cloud Solutions
  • Unlocking Data with Language: Real-World Applications of Text-to-SQL Interfaces
  • Comprehensive Guide to Property-Based Testing in Go: Principles and Implementation
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. The Agile Radar: An Approach for Understanding Agile

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.

By 
Rickard Jones user avatar
Rickard Jones
·
John Barratt user avatar
John Barratt
·
Apr. 04, 19 · Opinion
Likes (10)
Comment
Save
Tweet
Share
19.0K Views

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 [1] 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.


Agile Onion - Simon Powers


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 [2]) 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 [3] 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 [4] 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.

Agile Radar

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 [5]).

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 [6], 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.


References

  1. Agile Onion by Simon Powers, 2016

  2. Manifesto for Agile Software Development, 2001

  3. "ShuHaRi" article by Martin Fowler, 2014

  4. Agile Estimating and Planning by Mike Cohn, 2005

  5. Wikimedia

  6. Tasycupcakes game


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

agile

Opinions expressed by DZone contributors are their own.

Related

  • Is Agile Right for Every Project? When To Use It and When To Avoid It
  • Breaking Bottlenecks: Applying the Theory of Constraints to Software Development
  • How Agile Outsourcing Accelerates Software Project Delivery
  • Rebalancing Agile: Bringing People Back into Focus

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: