Before we can determine if your team is on the right track in your agile journey, we should first define what we mean.
Atlassian’s definition of agile is: “an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches.”
This is a good starting place, but it doesn’t account for all of the baggage that comes along with the terms agile, agility, agile transformation, etc. As we have seen many times, organizations will often embark on an agile journey by simply commanding development teams to “do agile!” without much of an understanding of what it means.
We have found that there are many ways to work in an agile way, but they can all be distilled to the mindset.
Framework vs. Methodology vs. Mindset — a Common Misconception
There are many misconceptions about Agile but one of the most frequent points of confusion is basic terminology: namely, what do we mean when we talk about an agile framework vs. methodology vs. mindset.
Many times you’ll hear people say the word “Agile” when they really mean “Scrum” — when they are thinking of two-week sprints, specific “ceremonies” or meetings for planning and refinement, frequent demos and production code releases, etc. Agile is not the same thing as Scrum, Kanban, or XP. Scrum, Kanban, XP and other frameworks are simply ways that teams have applied agile values to their ways of working. Therefore, a framework is just that, an established set of norms and processes that a team somewhere has codified, documented, and shared. (Scrum is the most well known and widely adopted framework, so it is conflated with the bigger picture Agile term quite often.)
A methodology is more specific to the team — it may be based on an established framework such as Scrum, but more often than not, your methodology will add or remove elements of the framework based on the needs of the team. If you’re a part of a Scrum team, ask yourself: What does our team do differently compared to the Scrum Guide? This is your methodology.
An agile mindset is the set of governing values and principles that apply across the board, regardless of framework or methodology. The mindset is derived from the Agile Manifesto, written in 2001 by a group of software developers hoping to find a better way to approach their work. While the authors didn’t agree on everything, they did find consensus around these four core values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While there is value in the items on the right, we value the items on the left more.
Taking it a step further, the 12 principles behind the Agile Manifesto were documented for additional context into the agile mindset. These principles are as follows:
1 — Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2 — Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3 — Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4 — Business people and developers must work together daily throughout the project.
5 — Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6 — The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7 — Working software is the primary measure of progress.
8 — Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9 — Continuous attention to technical excellence and good design enhances agility.
10 — Simplicity–the art of maximizing the amount of work not done–is essential.
11 — The best architectures, requirements, and designs emerge from self-organizing teams.
12 — At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
You’ll note that there is nothing prescriptive in the above principles and values. There is no implication that a certain framework is best, or even recommended. There is nothing that says you have to hold daily meetings, biweekly demos, or otherwise. Frameworks like Scrum (two-week sprints, planning and estimating, etc.) and Kanban (continuously monitoring work in progress or WIP) can certainly be agile, but simply going through the motions or checking boxes based on the framework’s guidance does not guarantee it.
The Subway Map below provides a visual overview of the paths a team could take — there are fundamentals that apply along the way, but the journey can look quite different depending on the framework your team chooses to follow and the practices (methodologies) in place for your team:
In some situations, using the wrong methodology or guiding framework for a team can inhibit agility or, worse, lead to problems with delivery as teams struggle to deliver value and fail to prioritize making purposeful changes driven by a mindset of continuous improvement. If teams don’t take the time and effort to reflect on what’s going well or what can be improved, how can we expect them to grow in a meaningful way? And what is an agile transformation without an element of growth?
If “doing agile” gets in the way of delivering consistent, valuable software (or other deliverables), are you really doing it right?
Focus on the Data and the People
Let’s say you have some work to do to get to a place where your team or organization is operating within an agile mindset. How do you start pivoting? Focus on two things: the data and the people.
The Data
Prioritizing data informed decisions is an unsung hero of an agile mindset. This doesn’t necessarily require in-depth metrics or reporting requirements, but it does mean that the team should take inspection seriously and take action based on what they discover.
For example, let’s say a team is seeing tasks rolling over from one sprint to the next, or staying in progress for a long time. If you’ve adopted an agile mindset, you are likely asking:
- Are there any similarities for the types of tickets that are rolling over? Are they related to the same system components? Are there patterns in assignees or transitions? Untracked dependencies across other teams?
- Did we miss anything in refinement that could have cut down on the cycle time? Was the ticket actually “ready to work” when it was picked up?
- What processes would help expedite our work and how can the team support each other? Are handoffs being missed?
- Are rollovers due to conflicts in customer expectations vs. value delivery? What are complaints or pain points? What can we do to ensure the customer is better supported?
- Are the framework we are using (Scrum, Kanban, XP, Lean, etc.) and the methodologies we are applying helping or hindering the team?
Using the answers to these questions, coupled with the actual data (number of releases, number of bugs/production issues, team velocity, team capacity, ticket cycle time, etc.), you should be able to take action to refine your ways of working to optimize the process and minimize pain points.
The People
Equally important to the data are the people who make up an agile team. When inspecting the team’s processes (operational, technical, or otherwise) there must be a focus on the individuals who participate in the process. An effective process for Team A may not work as well for Team B, and may be counter productive for Team C. Part of this is due to the type of work, but also because of the inherent uniqueness of each group of people. More dogmatic agilists tend to focus on coaching the rules of the game — frameworks, values, and principles — but far more effective is an approach of coaching the players. After all, the team is what makes up the individuals and interactions that are favored over processes and tools in the Agile Manifesto, and the importance of the individual is stressed multiple times throughout the 12 Principles of agility. It’s critical to ensure that the team is firing on all cylinders and any issues with team dynamics are diagnosed and remediated quickly.
When reviewing the people aspect of your agile methodology, closely inspect how the delivery process feels for each team member and for the group as a whole. Observe how your team’s interactions flow internally and with partner teams. Where are the points of confusion or roadblocks? Where does the team need help? How could their workflow be optimized for faster turnaround times? Do stakeholders trust the team to deliver value? Look for patterns and anti-patterns, and you’ll find that opportunities will arise.
Conclusion
“Doing Agile” does not simply mean codifying daily standups and pushing out regular production releases. It’s more about ensuring that the way you operate allows your team to react to uncertain and changing conditions, rather than checking boxes for the framework your team currently uses. If you want to be sure you’ve adopted an agile mindset, take a look at your team and ask yourself:
- Are we prioritizing regular inspection and making data informed decisions based on those observations with a clear goal of continuous improvement?
- Do we maintain a focus on the people? Do we ensure that our teammates have what they need to get the job done and that they are each invested in the methodologies in place?
Of course, there is a lot more to it, but these two key points will help strengthen the mindset muscles so that you can continuously deal with change, iterate, and improve. That’s the secret sauce of being agile.