It’s a doozy.

Agile bewildered the industry. Simple statements, borne from first principles shattered misconceptions about software development.

Agile Frameworks consistently fail their stated purpose: deliver software faster.

I realized the mismatch: Agile Frameworks do not employ agile. Agile Frameworks employ the failed management processes that have crippled software development projects since the 1960s. The perpetrators of agile frameworks employ the same con that every grifter employs. They use a name that most people think they understand but don’t, in a way that the grifter convinces them they don’t understand but must.

The word that trips people up every time is “agile.”

The snake-oil salesmen showed true genius on this one. They somehow deduced that everyone – young, old, smart, stupid, developer, manager… everybody – thinks they know what it means.

They don’t.

It’s too simple.

The 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

Manifesto for Agile Software Development (agilemanifesto.org)

The confusion originates from one primary source: the Manifesto for Agile Software Development was written for and to software developers. Nobody else!

When a middle manager who does not develop software interprets the Manifesto for Agile Software Development, he or she requires a translation from the concepts of software development into managerial process and plan. Since there are no instructions about the managerial process or plan in the Manifesto for Agile Software Development, the translation must fail.

Agile Frameworks do not employ agile. Agile Frameworks employ the failed management processes that have crippled software development projects since the 1960s. The perpetrators of agile frameworks employ the same con that every grifter employs. They use a name that most people think they understand but don’t, in a way that the grifter convinces them they don’t understand but must.

When a customer who does not develop software interprets the Manifesto for Agile Software Development, he or she requires translation from software development into schedule or budget. Since there are no instructions about schedules or budgets in the Manifesto for Agile Software Development, the translation often fails.

In a deep blow to management’s love of process, the Manifesto for Agile Software Development explicitly says that its own definition of “agile” focuses more on individuals and interactions than processes and tools.

It says there are more important things than negotiating schedules and budgets.

So why be agile at all?

I think that’s the best question anyone could ask. And there are different answers for each of the different camps.

The Three Players

The three distinct camps in this effort are customer, manager, and software developer.

Let’s make one thing tautologically clear: you can’t be a software developer unless your work directly results in some little zeroes and ones that the computer hardware understands as machine instructions.

(Those include instructions to the peripherals and services. I don’t wanna be too restrictive.)

But managers – and that includes scrum lords, fragile coaches, any non-coding role defined by scrum or SAFe – aren’t software developers and do not understand what software developers do. And for all that’s holy, they cannot understand how software developers think or work.

Here’s a simple test. If you could sit in a room with nothing but a computer and the interwebs and pound out a valuable solution to a business automation problem, you are a software developer. If not, you aren’t.

See how simple that is?

This is why managers and customers will never understand the Manifesto for Agile Software Development. It’s not meant for them. It’s alright if you want to ask, “why?”

First Principles

The mismatch in perspective comes from First Principles.

There are both first principles and first principle thinkers. Some people can teach themselves to use first principles in their lives, but a certain cadre of people could not use anything else. We call them first principle thinkers. Most innate software developers follow first principles. The best can do no less.

Let’s make one thing tautologically clear: you can’t be a software developer unless your work directly results in some little zeroes and ones that the computer hardware understands as machine instructions.

The Manifesto for Agile Software Development results from first principles, but isn’t, itself, first principles about software development. This is why it doesn’t translate to other corners of the business. To understand the Manifesto for Agile Software Development, try to understand software development first principles.

First Principles for Software Developers

The First Principles underlying the statements in the Manifesto for Agile Software Development may include the following:

• The practice of software development must develop valuable software (tautology, I know)
• Knowing how a machine works is insufficient to develop good software
• The more senior the group, the better the likelihood of success
• Risk exists and planning does not mitigate it
• Strict control increases risk, costs, and failures
• Common software development management practices punish developers
• Successful software development must remain fluid
• Contracts are not communication
• Software documentation (even today) transmits no knowledge

I’m sure there are more, but those are sufficient for the purpose.

The Manifesto for Agile Software Development addresses those foundational truths about software development. They address no other practice’s concerns. They’re only adequate when applied to software development.

In fact, the Manifesto for Agile Software Development exposes management’s first principles as anti-patterns to good and sustainable software development.

When the common three disparate groups (developers, managers, and customers) conspire to commit software, those first principles prove inadequate for two of them: the managers and the customers.

First Principles for Customers

For the customers, the first principles include:

• There’s only so much money
• There’s only so much time
• We don’t trust one another
• Software development projects historically fail at frighteningly high percentages
• We want guarantees

Interestingly enough, the twelve principles behind the Manifesto for Agile Software Development actually address the customer’s first principles – except for being able to provide guarantees. However, the twelve principles must be explained to the customer from the viewpoint of their own first principles.

The most important of these includes:

• [E]arly and continuous delivery of valuable software
• Deliver working software frequently
• Business people and developers must work together

Valuable Software

The very first of the twelve principles makes delivering valuable software to the customer the highest priority. This speaks directly to the promise that agile developers want to spend the customer’s money on the most valuable things first. When the money runs out (and it will), all that remains are “that would be nices” and “that’s not importants.”

Frequent Delivery

By delivering working software frequently and measuring success on that delivery, software developers improve trust and demonstrate progress.

Daily Collaboration

A couple of the twelve principles speak of face-to-face communications between the developers and the customers, and that such communication must happen daily. Frankly, I think this is the part that scares the beejeebers out of most managers and why they prefer to replace agile with agile frameworks (true gold with fool’s gold). Agile removes management from the secure position between customers and software developers and reveals the historic trap in sixty years of software development failure.

It Is Down to You and It Is Down to Me

The Manifesto for Agile Software Development, then, addresses and offers solutions to both the software developers’ and the customers’ first principles. It provides new ways to think of software development and expects both the customer and the software developer to alter practices that have not worked in the past and offers new practices that have demonstrated value.

Twenty years’ of agile practice demonstrates that the practices and principles only work if the developers, the customers, and the managers adapt to different mindsets and foci. But managers who reach for their agile framework lifeboat make a very clear statement to the others. And it’s not a good one.

In other words, software development works if everyone changes their practices to accommodate valuable and successful software development.

Management wants to drag everyone back to the sump of failure by canning the old sausage in a new can: the agile framework.

What is the classic definition of insanity?

First Principles for Managers

For the managers, the first principles include the almost visceral need for the following:

• Planning
• Organizing
• Leading
• Structuring

Management as Anti-Pattern

In fact, the Manifesto for Agile Software Development exposes management’s first principles as anti-patterns to good and sustainable software development.

Managers say: “we need a plan.”	Agile says: “responding to change over following a plan.”
Managers say: “we need organization,” and “we know how to lead.”	Agile says: “the best architectures, requirements, and designs emerge from self-organizing teams.”
Managers say: “we can structure the output.”	Agile says, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

In fact, management’s answers to management’s first principles, when forced upon the software development project, regardless of framework or scaffolding, remain the most consistent impediment to satisfactory outcomes for both software developers and customers during the software development effort.

Twenty years’ of agile practice demonstrates that the practices and principles only work if the developers, the customers, and the managers adapt to different mindsets and foci. But managers who reach for their agile framework lifeboat make a very clear statement to the others. And it’s not a good one.

If managers truly yearn for successful software development, they’ll have to reorient their management first principles. And here is the hardest part: managers must abandon classical management and become vine dressers.

Frameworks don’t improve the lives or outcomes of the developers or the software. At worst, they mask the failures of communications, progress, customer’s changing priorities and the ever-endangered degree of trust critical between customers and software developers.

Frameworks (like scrum and SAFe) satisfy managers’ first principles. We’ve already established that those exist as anti-patterns to successful and sustainable software development. Formalizing anti-patterns doesn’t make them better. It just makes them formal.

I’ve known some very good managers but by-the-book management answers don’t usually work with software development. The best managers, though, took historically iconoclastic approaches to software development.

Vinedressers

If managers truly yearn for successful software development, they’ll have to reorient their management first principles. And here is the hardest part: managers must abandon classical management and become vine dressers. Vine dressers first principles include:

• Knowing how and when to prune
• Knowing how to nourish
• Knowing how to improve conditions and cultivate excellence

The first principles of a software development manager must change – must embrace the need to learn how to make the software developers stronger, more skilled, and unencumbered – sufficiently to do the hard job of developing software that satisfies the customers’ desired outcomes. This is much different than production management. It is much different than typical widget management.

A good software development manager must have the knowledge and courage to do the following:

• Pay such close attention to the group dynamic that the manager recognizes when it’s time to prune a member of the software development team.
• Pay close enough attention to the group dynamics (and the workload and communication struggles) that the manager knows when it’s time to add a new member.
• Learn what promotes growth and invention inside the software development group and learn when to apply the tools and support that improves communication, knowledge, training, and trust within the group.
• And know when to stay away.

Management needs to catch up. The rest of the players already know how to build good software and satisfy customers. But the software developers and customers sure could use some help instead of competition.