All in the Mind – Adopting an Agile Mindset as the Prerequisite to Agile Transformation

Abstract

In today’s rapidly changing world, the ability to adapt and thrive is crucial for success. To navigate the ever-changing needs of stakeholders and communities, many organizations seek to implement Agile methodologies. However, the true catalyst for meaningful transformation lies in fostering an Agile Mindset within these organizations.

This paper explores the indispensable role of an Agile Mindset as a prerequisite for successful Agile transformation. We will explore the core principles and values that shape the Agile Mindset, emphasizing how this way of thinking cultivates a culture of collaboration, adaptability, and continuous improvement. By embracing this mindset organizations enhance their impact, drive innovation, and effectively address the evolving needs of their communities.

Using GeoScienceWorld as an example of an organization undergoing Agile transformation and seeking to adopt an Agile Mindset, we will discuss how keeping the four values of Agile to the forefront of our thinking has impacted our internal, and external, business practices, paying particular attention to product development and prioritization.

What is Agile?

Regardless of industry or sector, we often hear the word “Agile” used to describe business processes, especially around project management. However, the use of the word is rarely, if ever, qualified by what is meant, exactly, by “Agile”. In an attempt to gauge the various uses of the term among my own contacts, I presented the following challenge to my connections on LinkedIn:

The challenge provoked a diverse array of responses, including:

• A philosophy many don’t understand
• Learning to work better, efficiently
• Pivoting
• Confirming what is most valuable
• Structure, ceremonies (sometimes too much)
• Outcomes through learning, not over-planning
• MVP, discovery, alpha, beta, kanban
• Empowered teams evolving the solution
• Fail fast then iterate; repeat

Each of the responses from the connections that took part is valid, and in many ways useful. Looking through the responses, I was able to group them into 4 general thematic buckets:

• Project management methodology
• Sprints
• Daily stand up
• Retrospectives

Those buckets all have value in and of themselves, however I am convinced that they actually miss the key point of what it means to be “Agile”.

There was one respondent, though, who understood fully the task that I had set, and that person gave me a simple, single word, answer:

• Mindset

In the rest of this paper, we will look at what it means to have an Agile mindset, and how that mindset impacts our work and business processes, both with colleagues internally and stakeholders externally.

The Four Values

The origins of Agile are in a meeting of leaders working in the software industry, who met in February 2001 in Utah in order to discuss how to improve working processes in software development.¹ Software projects prior to the adoption of Agile methods often failed to complete, and those that did usually exceeded their budgets. The ultimate aim of Agile, and the Agile Manifesto was to uncover “better ways of developing software”. As a result of this aim the attendees in Utah developed the Four Values.

The Four Values are value statements in which the Agile Manifesto notes that certain ideas are to be valued over other ideas. Although the Four Values have their origins in software development, they can be extrapolated and applied to every area of an organization.

The Four Values² are:

• Individuals and interactions over processes and tools
• Impactful outcomes over comprehensive documentation
• Customer collaboration over contract negotiation 
• Responding to change over following a plan

The second of the Four Values in the original text says “Working Software over comprehensive documentation”. I replaced “working software” with “impactful outcomes” as I believe the Agile mindset should not be limited to just software development.

It is important to understand that while adopting an Agile mindset places more value on the clauses on the left side, in bold, of the statements above, it does not say that the clauses on the right have no value at all.

Mindset before Practice

Given that we have identified that the core of Agile is a mindset, how an individual or organization thinks and perceives their work, we need to address the concept of “Agile methodologies”.

There are several popular ways of working that are associated with Agile, including such well known methodologies as:

• Scrum³
• Kanban⁴
• Scaled Agile Framework⁵

These methodologies share common features, roles and ceremonies, including:

• Dividing work periods into “sprints”
• Having a daily standup meeting to discuss progress and blockers
• Performing retrospectives to learn what has gone well and what can be improved

Despite these common features, and the perception that these methodologies are inherently “Agile”, there is no guarantee that an organization is actually Agile, and lives up to the Four Values.

The Agile Manifesto doesn’t prescribe any particular methodology as being a definitive approach to “being Agile”, as such it is perfectly possible for an organization to implement an “Agile” methodology, such as Scrum, and yet remain resolutely not-Agile. When the business values process and tools, for example, over interactions and individuals, but practices Scrum, they are not Agile. When an organization ignores the reality of change in their situation and doggedly sticks to their detailed, laid out, plan but has adopted Scaled Agile Framework, they are still not an Agile organization.

Such organizations have put the cart before the horse, having adopted the practices of Agile methodologies without internalizing the values of the Agile mindset, and it is no surprise that in such a situation the phrase “Agile doesn’t work” becomes common.

Agile Mindset in Practice

Having discussed the attributes of an Agile Mindset, I now want to show how we at GeoScienceWorld have put it into practice within our own organization, in particular in the team that I lead, the Product Management Group.

The Product Management Group, PMG, in GeoScienceWorld is responsible for the creation and prioritization of our product backlog. PMG also oversees the development of new products and enhancements to existing products, such as our publishing platform.

In 2022, PMG spent a lot of time and resources working on plans to revitalize an existing tool on our publications platform called OpenGeoSci, which is a content search tool that has a map based interface to allow users to navigate through available content based on geography rather than traditional keyword search. When the tool was originally launched, it existed as a separate website from our publishing platform, however when we migrated to our current platform provider, OpenGeoSci was integrated into the main website.

As a result of the work that PMG had undertaken in 2022, we came into 2023 ready to start development work with our various software development partners. We had created wireframes for the user interface, the technical architecture had been defined and documented, and the tools required to meet the requirements had been identified. We had also applied for an Amazon Imagine grant to offset the cost of development to some extent.

PMG meets on a quarterly basis to discuss and plan our work in the upcoming months as well as create our roadmap for where we think we are likely to concentrate our efforts further out. When it came to prioritization though, we usually worked on whatever was most appealing to us at any given time, as such we weren’t necessarily providing value back to our various stakeholder groups.

Having been asked by our CEO how exactly we went about prioritizing our work, PMG set about creating a more data based approach, which resulted in our “Prioritization Matrix”. For each project that PMG needed to prioritize, we awarded points based on the following criteria:

• Number of target personas who would benefit
• Number of business metrics impacted
• Number of customer service issues reported in the previous 12 months
• Potential market value of the project
• Level of effort

The highest score possible using this matrix would be 14.

The image below shows the matrix after the first time PMG assigned points to each of the extant projects in our backlog as of March 2023.

Assigning points to all of our projects showed that despite the amount of work PMG had put into planning and creating the specifications for a new version of OpenGeoSci, the project scored incredibly low in the Prioritization Matrix. With this information, and with a commitment to working in an Agile manner, PMG responded to this change rather than blindly following the original plan that had been laid out. The Prioritization Matrix had shown PMG that:

• OpenGeoSci had limited value when compared to other projects in the backlog
• PMG needed to pivot to focus on the work that would have more impactful outcomes
• PMG’s plan for 2023 needed to be re-configured

As mentioned above, GeoScienceWorld’s Product Management Group meets in person once a quarter to review the work undertaken in the preceding few months and to re-prioritize our backlog, taking into consideration new information, changes in our industry, fresh opportunities, and how we can provide value back to our stakeholders. 

Conclusions

From this very brief overview of the values that underpin a truly Agile organization it is possible to draw three conclusions for those organizations looking to adopt Agile ways of working.

Given that Agile is first and foremost a way of thinking rather than a way of doing, it is imperative that an organization understand that Agile is about culture. To be Agile is to place the customer, whether that be internal or external, at the very heart of everything we do. It is after all to the customer that organizations ultimately need to provide value.

Secondly, it is clear that Agile is not a one-size fits all approach, and that extends to within an organization. Some Agile teams will adopt a Scrum approach, while others will decide that Kanban is the right choice for them. Yet other teams will decide that none of the prescribed methodologies work for them in their sitz im leben, thus they will design and implement ways of working that are imbued with the Four Values but don’t have any particular framework underpinning them. When organizations begin to value their Scrum or Kanban processes and tools over the individuals and interactions they encounter, that organization is no longer Agile.

Thirdly, and finally, adopting an Agile mindset requires constant reflection and the willingness to constantly refer back to the Four Values as our ultimate guides to how an organization works. As the Agile Manifesto itself says in its first sentence:

“We are uncovering better way of developing software by doing it and helping others do it.”

It is possible to replace the phrase “developing software” such that the goal of an Agile organization is that:

“We are uncovering better ways of working by doing it and helping others do it.”

The process of becoming Agile is ongoing and iterative, such that it requires an ever present willingness to change and adapt to the changing world in which we find ourselves working.

References

1. History: The Agile Manifesto [online]: 2001, The Agile Alliance [Accessed on 30th October 2023]. Available from: https://agilemanifesto.org/history.html
2. Agile Manifesto [online]: 2001, The Agile Alliance [Accessed on 30th October 2023]. Available from: https://agilemanifesto.org/ 
3. What is Scrum? [online]: Scrum.org [Accessed on 9th January 2024]. Available from: https://www.scrum.org/resources/what-scrum-module
4. What is Kanban? [online]: The Agile Alliance [Accessed on 9th January 2024]. Available from: https://www.agilealliance.org/glossary/kanban/
5. Scaled Agile Framework [online]: Scaled Agile, Inc. [Accessed on 9th January 2024]. Available from: https://scaledagileframework.com/