There’s Nothing Less ‘Agile’ Than Scrum

In the long-distant future, historians will identify the Computer Age as the largest societal transition since the Industrial Age. The changes are all around us, but we still struggle to understand how computers — and the Internet — have altered the way we work.

Corporations Do Not Understand Technology

Since the first factory was created in the Industrial Age, one fact has always been true: the people who managed a factory could understand what they made and how they made it. All manufactured goods, from widgets to cars, were inherently and physically comprehensible. You could draw a diagram of them. You could model them. You could pick them up in your hands (or move them with your body). The Industrial Age could also be called the Age of Manufacturing Physical Things.

Two hundred and fifty years later, the Computer Age is the Age of Manufacturing Virtual Things.  This change has occurred within the lifetime of most corporate managers. These individuals were not trained in — and have no aptitude for — this extraordinary new science. They must rely on someone to guide them through the conceptual maze. But they cannot communicate using a programming language; they can only listen, think and speak through a corporate language.

In corporate terms, any work process can be described as:

• We are digging a ditch.
• We know how long, wide and deep the ditch is. If we are not sure, we can force our programmers to estimate this for us.
• We can calculate the time it will take to dig this ditch because we know how much dirt a shovel can move per minute. It’s simple math.
• Our ditch-diggers (programmers) can move their shovels at a consistent and predictable pace.
• We can maintain our schedule for our project by compelling our ditch-diggers (programmers) to work consistently each day.
• If we manage our workers closely, we can predict the accurate and satisfactory completion of our project.

In programmers’ terms, any work process can be described as:

• A program is like a symphony: it is a composition
• A program can only be managed by an architect/composer who can comprehend it both as a totality and also as a set of individual components.
• The architect will choose the programmers needed for the software based on their technical skill as well as their understanding – and obedience — to design principles. If they choose incorrectly, the symphony “sounds” as if it is out of time, since there is no unity of purpose between the players.
• The architect will train the programmers/players by teaching them how to apply their technical skills to the overall assignment: the symphony/software being produced.
• The programmers will be judged by their ability to interpret and build the software project. This is difficult to estimate in total, but rough, incremental estimates can be made over time.
• The software project can adapt to changing needs because the programmers/players are not attached to a specific outcome, but to any outcome determine by their architect/composer. For software, the outcome is a goal post that is always moving but is within the capabilities of the programmers.
• Because the entire project is a creative process, it cannot be wholistically budgeted at the start.
• If there is a time constraint, then the entire project/symphony can also be constrained, but this will limit the outcome.

The Agile Manifesto (When Programmers Get High)

In 1848, Karl Marx and Frederick Engels published The Communist Manifesto, a document intended to change the way human beings viewed their rights and obligations in the world. One hundred and seventy years later, two major countries proclaim themselves as Communist: Russia and China. And in spite of the time passed, the predicted creation of an ideal socialist society based on “take what you need, give what you can” has degraded into “we pretend to work and they pretend to pay us”.

On an unrelated topic, in 2001, a bunch of tech hippies got together, got high (just guessing), and cooked up the infamous Agile Manifesto, a declaration of how to create software in an ever-changing world. It wasn’t a bad document. As with Communist Manifesto before it, the creators could not imagine where this might lead. They hoped for Utopia. They got Corporatopia. Here is how that document got digested:

Agile Principle	How This Actually Works In A Corporate Environment	Achieved Value vs. Potential Value (A-F)
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.	Sounds great so far — just don’t get too “touchy-feely” on us.	F / A Nice philosophy for sleepy time (Nice dream, nice dream…) Great Idea, Part 1.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.	We don’t have a starting plan or a design document, and we don’t want to hire an architect, so it’s not like we have a choice.  Just don’t let this mess up our ridiculous deadlines.	F / C Since these projects are over-managed and always run late, added requirements are generally delivered by a mermaid riding a unicorn.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	Great! We can pester you every two weeks for MAJOR results. Then again, this is ditch-digging, right?  And the complex stuff– that’ll get done eventually, right?  Maybe when dark matter and dark energy mix, and the little faerie people from outer space will arrive at last?	F / C (Encourages Micro-Management, False Metrics and Trivial Results)
Business people and developers must work together daily throughout the project.	Wow, we’re on a roll!  We can ask you what you are doing every single day! We can force you to make daily work goals and then humiliate you in front of other people when you fail to meet them!  AND we’re not to blame!	D / D Like putting two warring tribes together in the same room with no translator. Pure mayhem.
Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.	Not sure what that means… …. if I sing a song to myself, I don’t have to hear this one…. hmmmm….,mmmmm… come on! You should be glad you have a job!	F / A This never occurs, even initially.  By the end of the project, everyone’s at each other’s throats. Great Idea, Part 2.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.	You bet it is. That’s why we have six levels of management.  Your manager needs this time to make sure you tow the line.	D / D So much for telecommuting.  Also, how much really valuable communication ever occurs in a daily scrum?  Or a 2-week review?
Working software is the primary measure of progress.	We completely agree. The thing should always work or you are incompetent — even if we can’t make up our minds about what we are doing.	C / C Nice in theory, but never occurs in actuality.  This would require real planning and communication about the software itself, plus rigorous code reviews, plus perfect team cohesion.  Even then, the software will tend to move in fits and starts.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.	Yes, we pay a pitiful price for your services, and you work like a dog until you die. You are a machine that needs no rest and no variation; your accomplishments are erased as soon as they are completed. If you whine, we “have to” get rid of you.	D / C Of course!  Just ask a marathon runner who never gets a break! The good news: your technical debt falls onto the next schmuck’s shoulders.
Continuous attention to technical excellence and good design enhances agility.	We do not know what means but agree as long as it doesn’t take any time or cost any money.	C / A Great Idea, Part 3. Corporations consider this to be a philosophical ideal rather than a critical requirement.
Simplicity–the art of maximizing the amount of work not done–is essential.	You don’t mean that we have to change to get more “simple”, right?	C / A Great Idea, Part 4. Corporations consider this to be a philosophical ideal rather than a critical requirement.
The best architectures, requirements, and designs emerge from self-organizing teams.	Yes, organize yourselves — otherwise, you might miss our mandatory daily meetings	C / A Great Idea, Part 5. It is even wiser to encourage individuals to create excellence on their own schedules and within the team’s architectural guidance. The entire team should not have to constantly hear about, or micro-manage, work of each of its members. The corporation does not understand this process and cannot assist.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.	Yes, just as your Scrum “Master” and I am sure they will find time for your rambling reflections.	C / B A “self-organizing team” can be as oppressive as a corporation if the political alignments get out of control. The time would be best spent discussing how to improve code quality, how to better abide by design principles, and how to help each other achieve common goals. The corporation does not understand this process and cannot assist.

Corporations Do Not Understand How to Motivate Human Beings. They Also Do Not Account for the Cost of Demotivating Human Beings

Corporate planners have fallen in love with the word agile because it is almost impossible to argue with. Who doesn’t want to be more agile? But agility is not the goal. It is the extreme, ceaseless micro-management of their personnel. Agile/Scrum, the corporate world’s solution to managing technology, is how they accomplish this. While agile at least pretends to give workers some rights, scrum instantly erases them. This is because, to a micro-manager, the following truths are self-evident:

Corporate Belief	Human Dilemma
Workers are lazy, greedy and stupid	That’s actually true — of all of us, including managers.  These are human vices. Workers who give up their liberties and tow the corporate line end up feeling powerless and disrespected.  This sends them into a passive-aggressive spiral in which they lose interest in work and become increasingly inefficient and unhappy. When corporations calculate the value of a person’s time, they use these miserable workers as a guideline. Everyone, regardless of their productivity, gets paid at the same rate as the worst performers.
Because of this, workers cannot be allowed to work unsupervised.	All major psychological studies have concluded that human beings are both productive and efficient when properly trained and given creative freedom and control over what they do.  They want to succeed; they know this takes hard work. If they don’t, they should be fired.
“Supervised” means: watched, given strict time-based assignments, and confronted if they do not make daily deadlines.	These debasing mind-control techniques are used in throughout the world to torture prisoners. They do not motivate workers.

A badly designed and written software project is a poison bullet for any company to swallow:

• Every app user will lose efficiency. That translates directly to money.
• The app will have to be maintained over time. The cost will be prohibitive, but is never accounted for until it is too late.
• Bad management means losing good workers; the entire negative cycle repeats endlessly.

Mistreating Human Beings Is a Psychological Disorder

Why do so many corporate managers choose Agile/Scrum for their software teams? Is it because they need to feel in control to be happy, and they can’t control what they don’t understand? So they adopt this extreme micro-management system to restore their lost sense of control? Surely a modern corporation can aspire to a more aspirational agenda.

Listen to What Experienced Programmers Have to Say About Agile/Scrum

These are the most complete, coherent analyses of Agile/Scrum available on the Internet. They are presented here in no particular order.

Aaron Gray
James Succis
Simple Programmer
OK Give Up
Bits and Hops
Cutle.Fish
Effective Software Design
Mike Hadlow
Clever PM
Code Artisan
QED Therese
DK Rimmer
Luke Halliwell #1
Luke Halliwell #2
Knowledge Hut
Effective Software Design
Agile Connection
Vitality Chicago
Jimmy Bogard
Adam Ard