Revealing Your Agile Mindset
Observing your team in action will reveal what it values and which principles drive the team’s work. Your practices, the things you do, are built upon the values and principles you lean upon to guide the way you think and work, be it individually or collectively.
Your team may actually execute its methodology and practices very well. However, whatever those practices are, they areonly as good as the underlying values and principles that drive the team’s work and its culture. In fact, what is done, consciously or not, always represents what the team believes and what it values. In other words, there is a direct correlation between the work and the values and principles the organization embodies.
Ultimately, to change your organization, you need to change what it believes and values about work more so than focusing on how it does that work.
Before I define how the Agile Manifesto drives Timeless Agility, I will set it up by briefly discussing what Timeless Agility is and then provide an overview of the Agile Manifesto itself.
What is Timeless Agility?
Timeless Agility is the outcome of a mindset that transcends methodology. It is the Ri and Shu-Ha-Ri (more on that below). It is about embracing a way of working that will outlive the latest trends in methodology or best practice.
To be timeless in your agility, you need to internalize core values and principles for how work should be done more so than learning and doing specific practices or using specific frameworks that come and go anyway.
Yes, you need to learn how to work with Agile methodologies, prescribed or homegrown, but the goal of timeless agility is to never again be at the mercy of the latest trends in methodology or the constraints that accompany them. See the 3 Reasons to Value the Agile Mindset Over Methodology.
Shu-Ha-Ri
Before you can ever “become” Agile, you must “do” Agile things. But I believe far too much focus is on and stays within doing that becoming is never achieved. Have you heard of the Japanese stages of learning concept called ShuHaRi, or Shuhari, or Shu-Ha-Ri? Most teams get stuck in Shu and Ha and never break into Ri, which is why I think teams struggle with agile transformation success.
Shu is that stage where you are learning from a teacher and follow exactly what is taught and how to perform the tasks without much regard for theory or why. Even if there are multiple ways to perform a task, you will concentrate on the one way instructed.
Ha is that stage where you are now learning from other teachers and beginning to think about why and the theories behind the practices. You may mix and match some teachings from various teachers.
Shu-Ha is where most people stop, so when situations present that do not fit the learned prescriptions, they do not know what to do.
Timeless Agility is about going from Shu-Ha to Ri.
Ri is where you aren’t really learning from other people any more. You may borrow and edit practices you learned along the way, you may share ideas, but you are also more likely creating your own ways of working based on your own experience and learned mindset, based on what your specific teams and circumstances need.
Shu-Ha is “doing” Agile and Ri is “being” Agile.
What is the Agile Manifesto?
The Agile Manifesto is a set of four core values that serve as the foundation from which all else derives. These value statements are written such that one thing (left side of statement) is preferred over another (right side of statement). It is important to understand that it is not instead of, but rather, over.
“That is, while there is value in the items on the right,
we value the items on the left more.” – agilemanifesto.org
As our pyramid headline graphic demonstrates, the baseline for Timeless Agility is the four Agile values, and its 12 principles, taken from the Agile Manifesto. While these were written specifically for software development, I like to use the Disciplined Agile Manifesto modifications to make them more about consumable solutions than software specifically because agile truly is applicable across departments and industries.
What Makes These Values Timeless?
I will now cover the four agile values from the Agile Manifesto and provide why I think these values are timeless. See if you agree and feel free to provide comments and feedback.
Individuals and Interactions Over Processes and Tools
The timeless concept here is that knowledge work is completed by people, not by the processes and tools they use.
This is not a new concept that Agile practitioners invented, but the statement helps us refocus on putting the primary emphasis around people getting together and interacting, face-to-face if possible, to solve problems and deliver solutions. In a highly technical and remote working environment, you are still more effective when processes and tools merely support that effort.
The common challenge your organization may face, especially as it grows larger, is that it can sometimes get so wrapped up in the processes and tools that unreasonable expectations are placed on those things.
Far too often tools influence the processes. In an effort to maintain control, processes can become a way to control everything in a standardized way. They become a crutch and eventually contribute to doing things a certain way because that is just “the way we do things here.”
Team Size Impacts Processes and Tools
There is a direct correlation between your team size and the use of processes and tools. An autonomous team of three working in the same workspace likely has very little process or tool utilization in their work. They do not need it. As the team grows and as the team’s external dependencies expand, processes and tools are implemented to attempt to facilitate or even control the work.
Despite what some Agile proponents may say, this is not a bad thing. In fact, some Agile methodologies are too narrowly focused on independent, self-organized teams that they ignore the holistic enterprise view and the interdependencies therein.
It is simply not feasible to have a bunch of small, autonomous teams working without processes and tools. In that case, you would essentially have many small startups working independently rather than as a cohesive organization.
An organization may start out that way when they are small, but as it grows, tools and processes are necessary and help tie teams together toward common organizational goals and economies of scale. Think Scaled Agile Framework (SAFe) or Disciplined Agile Delivery (DAD) here.
I just think that organizations tend to put too much faith and reliance in processes and tools and too much emphasis on one-size-fits-all approaches. That simply is not timeless.
Collaboration tools have a purpose, but should not replace the value of personal interaction. Process serves a purpose, but should not get in the way of real-time interaction and problem solving. Timeless Agility understands that one size does not fit all, so each team implements what works for them in their day-to-day while ensuring they stay tapped into the overall organizational scheme.
Working Software [Consumable Solutions] Over Comprehensive Documentation
The timeless concept here is that people use solutions, not the requirements and design documents that support development.
The point here is that requirements and design documentation provide no direct value to end-users, yet it can be quite common for teams to spend weeks or months producing detailed documents before a single line of code is ever written.
Traditional projects measure success by how many tasks are completed along the way, including the writing of these documents. Agile measures success by how much working solution is in the hands of users. Therefore, although documentation is still important, the focus of the team needs to be more on starting and finishing small increments of work, and putting something of value into the hands of users sooner rather than later, and frequently. Think Minimum Viable Product here.
Feedback is the best informant of what you should work on next, so agile values getting something out quickly, even if it is not perfect. The reality is, no matter how smart you are, you can never fully guess correctly about the features users want, need, or will end up using the most.
When in doubt, leave it out. Believe me, your users will tell you if they want something. What they tell you many times is different than what you would have guessed. Agile thinking, more accurately lean thinking, says go with what you know today, let users experience it, learn from their feedback, and adjust.
Customer [Stakeholder] Collaboration Over Contract Negotiation
The timeless concept here is that the business and its solution provider need to work together collaboratively, with flexibility, to achieve desired results. In other words, there is a difference between being right and doing the right thing.
Contracts are often about being right and holding providers accountable to what they said they would deliver, when, and how they said it would be delivered. It naturally creates an us versus them relationship.
Lack of trust is the heart of the issue, so contracts attempt to define in detail what should be delivered and how. Changes to these expectations are unwelcome and often contentious because that usually means original expectations have to change and the organization is not well equipped to adjust contractually to changes midstream.
What is really the issue here? Contracts build in some level of fixed scope with a fixed timeline and fixed cost. This approach removes any hope of building empirically, meaning you do something, experience it, learn from it, and adjust.
Adjusting simply is not built into the contract because that, by nature, changes scope. There is also a mindset that resists changes to defined plans, which we will discuss in the next value statement.
Agile believes that the customer and provider are one team striving for the same goal. It is a partnership with frequent communication and collaboration where trust is developed. As such, both parties desire to do the right work and chase value, whatever that is, and are willing to welcome changing requirements and outcomes as a result. It is a value-driven approach versus task-driven. It is an understanding that no one knows everything up front and we learn as we go, which produces the need for changes, good changes, that produce a better outcome.
Contracts are still needed, but rather than rigid instruments to control, they support the opportunity to change course as needed through customer collaboration and learning. With Agile, we expect time and cost to be fixed, but scope is always flexible. With such a contractual arrangement, the customer and provider work closely to define and deliver the highest value work within the time and cost allotted.
Responding to Change Over Following a Plan
The timeless concept here is that delivering the next right thing is more important than sticking to preconceived plans.
Traditional projects attempt to define everything up front and put a plan and schedule around that. This requires knowing everything up front, which we all know can be challenging, especially in software development projects.
Despite the fact that most of that up-front planning is guesswork, the traditional goal is to stick to the plan at all costs. The plan becomes the measure of success, not the value delivered. Not only is the initial plan not accurate, it keeps us from chasing value. This is why it is better to Wait Until the Last Responsible Moment to make better product decisions.
This is the underlying problem with most large projects. The scope is so large and the timeline so long that even if you guessed right up front, what was valuable when the project started may change by the time the project is delivered.
If the goal is to follow the plan, then one may end up successful in that sense, but may miss the mark on delivering the most valuable product in the end.
Agile thinking, on the other hand, understands that we cannot know everything up front. The more unique and complex a project, the less we know up front and the more we can guarantee that change will occur, or should occur, in order to do the next right thing and deliver the most value.
So, we not only value responding to change, we see it as mandatory for project success. In order to accommodate change, Agile employs an empirical process where, in short cycles, we do something, experience it, learn from it, and adjust.
Summary
I suspect even if you had never heard of Agile before, these values would be worthy pursuits for your business. These four values are indeed the foundational layer of Agile, but alone do not provide enough guidance to live out these values. In order to better focus the Agile movement, to help clarify what is behind these values, the Agile Manifesto authors gave us the 12 Principles of Agile Software, which I plan to unpack in future blogs.