Being a bit of a theorist and process thinker, I have found it fascinating to watch proper Agile (with Scrum) in action. I am impressed with Agile, which favors high levels of collaboration and functional software in lieu of extensive planning and tooling.
Yet this article was birthed out of my responses to those who use “Agile” as a synonym for “God.” When Agile trumps all and labeling an approach as “not Agile” is the easiest way to dismiss it, we are blind followers of an ideology. We have to dig deeper into the actual values of Agile and understand their intention as well as their appropriate application.
Agile Manifesto
Here are the values straight out of the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
It is important to note that this principled approach does not deny the importance of the methods on the right. Rather, it simply emphasizes those on the left. They are given higher value.
Understanding Values
In the cases where teams ignore the values on the right, things get ugly. Working software with no documentation is a recipe for disaster when a new developer joins the project. Lacking a plan altogether, in favor of responding to change, leads to chaotic software development. I’ll dive into some examples in a moment, but it’s important to recognize the both-and nature of these values. There is an interplay between them, and often times the values on the left should trump those on the right, but it’s not a hard-and-fast rule.
Rules and laws are rarely absolute, having clear breaking point(s). Police officers may exceed the speed limit when rushing to the site of an accident. Do they think they are above the law? No. They are hurrying to ensure the safety of those in the accident. In that moment, following the speed limit becomes less critical than saving someone’s life. But most of the time, obeying the speed limit is of highest importance.
Agile Values
I would agree that, in the majority of Agile contexts, individuals and interactions overrule processes and tools. Customer collaboration should supersede contract negotiation. But when is contract negotiation actually more valuable than customer collaboration? And when do processes and tools prove more useful than individuals and interactions?
Let’s take each value statement in turn and consider when the less important values become more valuable. I’ll use Affirming Agile where the scenarios line up with Agile values, and Challenging Considerations where Agile values prove less than valuable. The Sweet Spot sections hone in on a principle that provides a balanced approach.
Individuals and interactions over processes and tools
Affirming Agile
At a former workplace, I only actually interacted with coworkers about once a week for a few minutes. It was a disconnected team of three. I did web application development and lived in the U.S. My counterpart lived in France and we had very little overlap in our workdays. My manager was so busy I never knew when I would see him. It made for an incredibly isolated work environment. Little interaction resulted in poor communication, duplication of work, and sluggish adaptation.
Moreover, our processes and tools were abundant, and it took several years to push a new feature into production. Okay, I’m exaggerating. But I did spend three months improving processes and because of our tool set, those changes never got implemented. We had poor processes and poor tools, as well as little interaction and collaboration. It’s ultimately why I sought employment elsewhere.
Challenging Considerations
But sometimes a good process or tool actually assists the individuals and interactions. Without project management software, status updates wouldn’t be as readily available. Without real-time messaging platforms, remote teams would be more disconnected. And without process-oriented frameworks like Scrum, there is a gap between the theory of Agile and its actual practice.
Basecamp has produced some articles and podcasts that challenge the importance of collaboration and even Agile itself. One example, “Interruption is Not Collaboration,” pushes back against so-called collaborative environments that hastily waste productivity due to constant context switching.
Sweet Spot
When leading to chaos or disruption, individuals and interactions need to be tempered. Team agreements, asynchronous communication tools, and project management tools can maximize productivity as well as facilitate connectivity and interactivity.
Working software over comprehensive documentation
Affirming Agile
I’m sure you’ve seen comparisons between Agile and Waterfall. The trouble with the linear Waterfall approach is that it has problematic feedback loops. This causes a sluggish response to changes in requirements. It’s also prone to pushing off or curtailing the critical testing phase due to impending deadlines for project launch. The Agile approach produces quicker feedback loops. It promises within-budget and on-time delivery, with scope as its primary lever of change.
In the Agile model, software may have less features, but its guaranteed to work. In the Waterfall approach, scope is fixed. Resources and time are estimated. This difference is readily observed in The Iron Triangle of Planning.
Image courtesy of Atlassian Agile Coach, https://www.atlassian.com/agile/agile-at-scale/agile-iron-triangle
In this way, Agile Methodology produces working software rather than broken bells and whistles.
It is clear, in this context, that the Agile value for working software is critical to the success of any project.
Challenging Considerations
But what happens when your team grows from 3 to 80 in nine months, your onboarding process is minimal, and your documentation is scattered?
This is known as a mess.
In this scenario, Agile falters. “Working software” looks like your code base welcoming three different tool sets and constantly frustrating developers who don’t have a common standard to follow. Strategic use of documentation can become a beacon of light to guide the way forward.
Sweet Spot
You need to tame your code and introduce some thoughtful constraints. Whatever you do, don’t impose those constraints too rashly. Exercise discipline in determining how best to progressively clean up the code base while not hindering progress in delivering business value. I would highly recommend reading up on effective change management.
When fast-paced growth results in working software that compromises developer sanity or quality of code, take a different approach. Thoughtfully identify, implement, and enforce some documentation and standards across your team.
Customer collaboration over contract negotiation
Affirming Agile
Contracts are useful in many situations, such as buying a house or setting up a lease agreement for renters. They articulate clear expectations of all the parties involved. Contracts are also often legally binding, providing assurance for both parties.
But contracts are problematic. They are impersonal and oftentimes inflexible. When navigating a software development project with ever-changing requirements and/or scope, contracts break down. They become too rigid, requiring constant revisions or addendums. In short, they require too much maintenance.
Customer collaboration functions much better in these situations. It is based on trust rather than a hedged contract-backed position. Changing requirements or scope merely requires a conversation with the customer to confirm necessary adjustments. Especially in fast-moving environments, customer collaboration easily trumps contract negotiations.
Challenging Considerations
Contracts, however, are critical in defining up front terms and expectations. If you go the route of customer collaboration without defined expectations, you could easily get several months down the road in developing a product, only to find out what you’re creating isn’t what they wanted.
That happened to me once. I spent three or four months developing an app that never got used. Actually, it happened twice. Both times, a contract would have clarified expectations up front and curbed misunderstandings.
It’s also possible the customers will change their minds about the features they want in their app. If you don’t have a clear agreement that outlines a clear scope of work for Phase 1, how can you push back when they ask you to sneak a few “small” features into Phase 1? Your agreement, which would likely be in writing, needs to protect you from scope creep or changing requirements.
Sweet Spot
Customer collaboration should include contracts that are clear but flexible, defining the work to be done in each phase but allowing for adjustments to the requirements and/or scope of each phase.
Responding to change over following a plan
Affirming Agile
The Chinese have a saying: “Plans can’t keep up with changes.” This is often the case in Agile environments, and it’s what allows companies to quickly pivot on an app based on user feedback. In fast-paced environments, responding to change is critical to the success of a software project.
When the only constant is change, you must constantly adapt. In this way, plans bow to change. You could even ask, why do we even need a plan if it keeps changing? If you’re tempted to toss the plan, you’d not be the first.
Challenging Considerations
However, having little foresight and planning will compromise your effectiveness. It is wise — and kind — to give designers at least a week to produce comps for your upcoming features. And you’d better think about giving advance warning to other teams about dependencies you have on their features.
These are examples of the necessity of planning as it pertains to workflow around feature development and sprints. But if you zoom out a bit, planning is critical at a strategic project level. When an enterprise company undertakes a green field side project and they have deadlines for implementation, you have to craft a solid plan. Even the Lean concept of an MVP requires a clear plan to execute.
Sweet Spot
Perhaps the key distinction in the Agile value here has to do with the difference between having and following a plan. “Responding to change” does not require abandoning an existing plan or not even having one to begin with. Rather, we must avoid following a rigid plan at the expense of adapting to change.
Intentionally Agile
In summing up our discussion here, I want to highlight the fact that I deeply respect Agile values and the culture it creates. At the same time, we must consider the strengths and weaknesses of Agile, and how to best utilize the methodology to maximize our software development efforts.
My foray into Agile has been deeply enriching. And this exercise in more fully exploring the tenets of Agile has brought even greater enrichment. My hope is that you, too, have developed a greater sense of the core concepts of Agile as well as their nuanced applications.