20 years ago, just about this time of year, 17 software engineers created the Agile Manifesto as a better way to develop software products. Agile’s ascent in popularity over the last two decades has changed how the entire technology industry builds products, allocates resources, and delivers value to its customers. The benefits have been tremendously positive. However, as Agile has become mainstream, it’s morphed into a buzzword thrown around by consultants trying to make a buck, marketing firms trying to capture SEO, and executives trying to control it. Agile itself has turned into an industrial complex which is suffocating the very principles it was founded upon.
Stop Reinventing and Controlling Agile
As Agile made its way from small engineering teams up to C-Suite discussions and into the board room, executives do what executives do best, control it. They redefine it, put processes around it, make standards to roll out company wide. These are all against Agile's very core and what its founders were trying to get away from 20 years ago. There is a name for controlling, documenting, and putting processes around software development, it’s called Waterfall, which is the very reason why the manifesto was created in the first place. Waterfall does not work for developing software.
Trying to control Agile is like trying to bite your own teeth, it is a non-sequitur, doesn’t make any sense.
Executives, consultants, and business analysts try to control and put in guardrails in order to reduce risk, which uncovers the real cultural issue: a deep seeded lack of trust and insecurity in your teams. If you find yourself trying to control Agile to get better results, you most likely don’t have a software development problem, you’ve got a cultural problem.
Dark Scrum, Faux Agile
What is even worse than trying to control Agile is using its name as a label against its core principles. This further cheapens the term and introduces confusion for everyone. Here are some examples:
- Architecture Decision Records, or ADRs. These have gotten so common that GitHub has productized them. What is the better way?...sprints
- SAFE Large Scale Scrum, which means Scaled Agile Framework. The purpose of such a framework is to reduce risk, not maximize value creation. There are endless service offerings for agile consultant firms:
- https://www.scaledagileframework.com
- https://less.works/
- Budgeting with Agile. You often hear this from the CFO: “If I budget $100k for this software project, what can you deliver?” Whenever you try to control output for input, we’re back to Waterfall product development. Your software team may be running sprints, doing daily scrums, and have nice burndown graphs, but as long as you're making decisions based on a predefined budget and plan, you cannot call it Agile.
Martin Fowler, one of the founders of The Manifesto, sums it up in a 2018 speech on dark agile:
Our challenge at the moment isn't making agile a thing that people want to do, it's dealing with what I call faux-agile: agile that's just the name, but none of the practices and values in place. Ron Jeffries often refers to it as "Dark Agile", or specifically "Dark Scrum". This is actually even worse than just pretending to do agile, it's actively using the name "agile" against the basic principles of what we were trying to do, when we talked about doing this kind of work in the late 90s and at Snowbird.
So you really want to adopt Agile, what should you do?
Remember the Manifesto
The first thing to accept is that Agile is a philosophy, not a process. You can’t blast it out in an email or declare it at the annual all hands meeting. You and your colleagues must commit to the Agile philosophy internally, it really comes from a place of trust.
The Agile Manifesto is actually quite simple:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
When someone tries to implement a process or exhibit control to mitigate risk, remind them of the manifesto and the company’s commitment to Agile philosophy.
A great place to start incorporating this mindset is in recruiting. Screen for an Agile mindset when hiring managers or executives. Are candidates trusting of their employees and teams? Are they able to set a vision and goals and let others execute? Or are they controlling? Do they want to come in and establish new processes on how to do things?
Watch for the Symptoms
There is a lot of basic data you can see in the symptoms of process systems gone awry.
- You have chickens running your SLDC
- More than 20% of your resources are dedicated to servicing technical debt
- Does your data on expanding or constraining Agile actually support your conclusions, if not, time to iterate a different experiment.
- Your contractors, or business heads, are delivering success stories where the data is specious at best.
- Are contractors making process tweaking masked as an insurance policy? If so, there often tends to be a better way to do something. A retrospective will at leasts cast doubt on their assertions, but the takeaway is to double down on a process that failed to deliver.
- No one can hit their velocity numbers is always a sign to look for, can be any number of issues, but can be a symptom of many misalignments with Agile.
- You, or your engineers, can’t explain a process, and seem to be having drowning in documents nobody reads or meetings nobody knows the purpose of
These symptoms typically mean Agile has lost its way. Dive into the issues further and there is a good chance you’ll see written, or unwritten, process, control, and risk mitigation strategies implemented that are killing your creativity.
Trust and Let Go
At the end of Martin Fowler's speech, he makes it clear exactly how to live agile principles and not control them.
"Should the original 17 people that wrote the manifesto take a special place in this ongoing effort?" The thing I'm proud of, that we the 17 authors did, is that we said "no". We wrote the manifesto. We did a nice piece of work, we'll be part of what goes on in the future, but we have no special role in that future. That role has to grow forwards. We said "new people will come in and do great things", which is indeed what happened.
Admios has been in business for 16 years, founded a few years after the Manifesto on the premise that these principles provide a better way to develop software and bring value and innovation to customers and engineering teams. We encourage you to join us to continue to fight for the Agile philosophy just like its founding fathers did two decades ago.
