>> So, never write documentation?
>
> Read the phrase again, with a slightly different word in place
I spent way too many years working at an Agile shop that had been doing Agile for a very long time. (This is me saying "This place definitely wasn't Doing Agile Wrong.".)
At that place, "Prefer working software over comprehensive documentation" ended up actually meaning "Do not write documentation. Go speak verbally to the SME for that thing or section of code if you ever have questions. Documentation maintenance is a cost that we never have time to pay. Ditto for code comments... all code MUST be self-documenting.".
It -uh- didn't work out so well.
> You’ve not been around much contract consultancy work then?
Honestly? IME, this is about the ONLY environment where the Agile stuff makes sense. It's just such a very, very, very poor fit for long-running projects that require continuous work that may extend for decades.
> > You’ve not been around much contract consultancy work then?
> Honestly? IME, this is about the ONLY environment where the Agile stuff makes sense. It's just such a very, very, very poor fit for long-running projects that require continuous work that may extend for decades.
I disagree. Like, I was just working at a place that did both analytics consultancy and in-house products. Go. Speak. To. User. worked in both.
For consultancy, yeah we had to go off and sit with the customer and figure out with them exactly what they needed. Do iterative PoCs. Eventually work out, together, what the 'user'/customer wanted to get out of the project(s).
For product, I sat down with one of the lead scientists and asked her what she actually wants. Like, be real with me. It's me here. I don't care if you want to use the products or not. I want to help you do the job you want to do and help you solve those problems you face on a daily basis. What will help you do this.
Answer: Bin the vaporware in-house software product and move to an established off-the-shelf third party system (Benchling).
Repeated the same thing with Data Science.
(Eventual) Answer: Bin the vaporware in-house software product and move to an established off-the-shelf third party system (databricks).
Of course, that didn't fly with the management people who wanted their magical 'guaranteed revenue stream' (which didn't exist). They weren't Go. Speak. To. User.-ing. So they were divorced from the reality of what was going on and stuck in the blue sky management vision.
Agile-manifesto-agile doesn't just apply to engineering. You can apply the principles of Go. Speak. To. User. And. Stop. Making. Gantt. Charts. To. Solve. The. Real. Problem. to a lot of places.
Yes, but "Go speak to the fucking users so that you build the right thing" is such a tiny slice of Agile shit, and it's a product management rule that predates Agile by ages. This is like one of THE big things that Product and Field people are supposed to do, and has been for roughly forever.
As for the rest of Agile? Maybe the idealized Agile (just like the idealized Marxism) works great, but my personal experience at a place that very, very, very much was NOT Doing Agile Wrong[0], along with the personal experiences of an assload of others who work at Agile (and "Agile" shops) indicates that Agile as she is implemented in the real world is incompatible with long-running continuous [1] projects.
[0] I'm afraid you're just going to have to take my word that I know what I'm talking about here.
[1] "Continuous" as opposed to the "parachute in, mitigate the biggest problems, and then airlift out" engagements that are SOME of what contract shops are hired to do.
At that place, "Prefer working software over comprehensive documentation" ended up actually meaning "Do not write documentation. Go speak verbally to the SME for that thing or section of code if you ever have questions. Documentation maintenance is a cost that we never have time to pay. Ditto for code comments... all code MUST be self-documenting.".
It -uh- didn't work out so well.
> You’ve not been around much contract consultancy work then?
Honestly? IME, this is about the ONLY environment where the Agile stuff makes sense. It's just such a very, very, very poor fit for long-running projects that require continuous work that may extend for decades.