You don't understand Agile!
Tags: agile, discuss, projectmanagement
Published: 2021-01-16 12:23:20

---
title: You don't understand Agile!
published: true
description: There's a high chance that if you're reading this, you don't understand agile.
tags: agile, discuss, projectmanagement
//cover_image: https://direct_url_to_image.jpg
---

## You don't understand agile!

I don't think you really understand agile.  Why do I think that?  Because 90% of people in the industry seem to [not know that they don't know](https://en.wikipedia.org/wiki/There_are_known_knowns#:~:text=%22There%20are%20known%20knowns%22%20is,of%20mass%20destruction%20to%20terrorist) what agile is and as a result, think they know what agile is.  This results in pervasive misinformation.  Just as a pure numbers exercise, it's a good bet -_on my part_- that you don't, simple.

> "_...as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones._" - Donald Rumsfeld,  United States Secretary of Defense

### How do you (think you) understand agile?

I propose that most agile [wells are poisoned](https://en.wikipedia.org/wiki/Well_poisoning).  People learn, self-led on the job and are riddled with bias and obstacles which taints their understanding & implementation. These people make and take part in faulty implementations, find the faults they injected, rage then write articles about them.

### Ad-Hoc Agile

The major mistake we make when adopting agile is not consulting with experts.  Taking in consultants or sending people on courses.  Agile is different, it requires a change in attitude more than (certainly before) process and as a result:

- we assume agile is largely a process change and not a culture/mentality and extract only the process which makes no sense in most cases without the culture

- we dismiss parts as common sense that then don't get attention in implementation.  

- we don't strive for management buy-in an end up making massive compromises.  

- We try to phase agile in to avoid disruption and miss the core concept.  That agile is about embracing disruption.

The second thing we do is assume that people talking about agile, know about agile...

### Learning from "experts"/articles online...

Everywhere I see articles like [this one](https://medium.com/critically-deciding/software-development-practices-desperately-need-real-attention-9477b4b85bd1) which base their premise on massively flawed articles such as: 

> "_Agile is the new waterfall…The reality of Agile is that you still have immutable decisions made by business people with no real understanding of technology. Those decisions are then forced on to developers. The end result is the same as Waterfall, only the names have changed._” — [ayasin, Architect & Developer](https://medium.com/swlh/agile-is-the-new-waterfall-f7baef5d026d)

Anyone who knows agile knows this is anything but.  "_immutable decisions_" completely contradicts [agile principle](https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/) 2...so, not agile!  

> Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Then in the same paragraph

> Those decisions are then forced on to developers

doesn't seem to match with [agile principle](https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/) 4

> Business people and developers must work together daily throughout the project.

And we are given the conclusion that "_Agile is the new waterfall_".  Someone who has managed to be a developer so long they've become an architect seems like someone we can trust, right?  

### All Agile is

It's very specifically a **change in thinking & culture**.  We strive to embrace uncertainty and cut out wastage so that we can deliver tiny amounts of high quality value quickly and repeatedly based on user feedback.  We then turn that attitude inward and cut wastage, make tiny amounts of high quality process changes quickly and repeatedly based on performance in the previous iteration.

Anything that doesn't meet this, isn't agile.  All process added and actions performed which decrease quality, time to increment and/or isn't user value focused will corrode all agile implementations.

 - Every process that slows development in order to forecast.
 - Every time there's a hand-off
 - Every user feedback you shun
 - Every failure to realise and focus the specific value  - added
 - Every time you fail to trust each other
 - Every single time you say "_that's not my job_"

Now the question is, am I right?  Get a certified consultant! Be ready to commit! Don't assume you know all you need to.