You're Doing Agile Wrong | "Agile Sucks"

[nelsonic]

You're Doing Agile Wrong [AGILE-1 No Boilerplate]: https://youtu.be/9K20e7jlQPA

[nelsonic]

[nelsonic]

Perhaps to the employee who still gets a paycheque or can just change jobs.
But to the entrepreneur ... the cost can be their life savings. Not quite "zero".

[nelsonic]

Agreed.

[nelsonic]

SAFe: "Scaled Agile Framework

https://www.scaledagileframework.com/safe-lean-agile-principles/

[nelsonic]

https://twitter.com/allenholub/status/1514806761873575936

I'd be very keen to see how @allenholub manages what needs to be done in a team without a "Backlog" ... 💭
Pretty much agree with the rest. ✅ Everywhere I've seen Scrum in practice it's been a colossal waste of time.⏳💸 🔥
https://twitter.com/nelsonic/status/1595814369971118080?s=20&t=va9xULpYCwaDx2v24yJCTQ 💬

[nelsonic]

The full quote is:

“Tell me how you will measure me, and then I will tell you how I will behave. If you measure me in an illogical way, don’t complain about illogical behavior.” – Eli Goldratt

https://en.wikipedia.org/wiki/Eliyahu_M._Goldratt

Read his books at Uni. Highly recommended. Especially https://en.wikipedia.org/wiki/Theory_of_constraints

[nelsonic]

Can't argue with this:

Working Software is the ultimate metric in software engineering. ✅
But ... something that "kinda" works and then is a dumpster fire to maintain is horrible for the next person. 😢

[nelsonic]

Spot on:

[nelsonic]

what I recommend. I'd start with:

• A 5-minute standup in the morning
• Around a kanban board
• With a WIP limit of team size/2
• Demo as often as you can

So pretty much what we are doing with: github.com/orgs/dwyl/projects/15 ✅

[nelsonic]

Individuals and interactions over processes and tools

While I agree with this sentiment in principal on an individual or Small Team perspective,
I feel that it fails to capture the reality that most of the products & services we use in our day-to-day lives
are created or sold by BIG Companies.
You don't use a banking App from a mom & pop shop.
You don't use a Laptop, Phone or Car made by a team of 10 people.
Even basics like groceries, you don't buy from small family-run firms ...
So how are the BIG Teams structured, organised and lead/managed?
How do you manage a company with thousands of people?

Working Software over Comprehensive Documentation

Again, I agree that Working Software is the baseline in software engineering. ✅
But once you achieve that baseline of "MVP" features, i.e. your App works,
then adding more features without comprehensive Docs & Tests is Complete CHAOS!
I have been on the "receiving end" of "working" software that had ZERO documentation and it's HELL!!
The Product Manager [who has zero clue how to write code and therefore allowed the previous dev to get away with writing zero docs or tests] is demanding new features be added to a brittle codebase. What do you do?
Do you take the time to retrospectively add docs & tests to the code that the "10x Developer" [cowboy] boshed out? 🤷‍♂️
Or do you keep compounding the problem with fixes and patches to the "working" software?

Tristram is coming from the perspective of writing Rust which as we know is "Perfect". 😜
But even perfect code requires some context for people joining the project.
If the documentation is poor it wastes everyones time.
Obviously we can't spend all our time on docs because then we won't have any software and we all starve!
But once the baseline of working software is achieved, docs should be next, not more features [without docs]!

Documentation in Open Source

Docs are important in closed source software where only a handful of "insiders" will see them,
but they are 10x more important in open source because the objective is collaboration!
Tris understands this and has contributed to the docs where he works:
https://github.com/alphagov/paas-tech-docs

In some cases we have 10:1 (docs to code)
where our objective is to on-board people as fast as possible into being "productive" in a project.
Our MVP App: https://github.com/dwyl/mvp is under 300 lines of [significant] code:

https://app.codecov.io/gh/dwyl/mvp/tree/main

But our docs that explain the reasoning and steps to build the project are 3000+ lines:
https://github.com/dwyl/mvp/blob/main/BUILDIT.md

That is not an "accident". It's a very deliberate.

The goal of documentation is to completely remove the barrier to first contribution.

We don't see "working software" and documentation as mutually exclusive,
we think we cannot have one without the other in the long-term.
Sure people can bosh out working code very fast [without docs] in the short-term.
But anyone with a short-term mindset needs to live long enough to work somewhere with ZERO docs
and feel the pain of having to unpick horrible spaghetti code. Then come back and tell me docs don't matter.

OR ... we all just write Rust everywhere and have "self-documenting" code. 😜

Customer collaboration over contract negotiation

Agree unequivocally.
But we still need contracts.
Otherwise customers come back and say "you didn't build what I asked you to" ...
And, again, trust me that's deeply unpleasant. [ask @iteles ... ⛵]

Responding to change over following a plan

Again, agreed. 👌
But you can't beat executing on a good "Master Plan" for achieving extraordinary goals ... 🚀
That's why we have a flexible Product Roadmap [Plan] that anyone can contribute to!

[nelsonic]

1. Read the manifesto - https://agilemanifesto.org/
2. Do what is valuable.
3. Don't do what is not.

[nelsonic]

I love this video so much I decide to sponsor the author: https://github.com/0atman ❤️

I'm so glad that someone is talking sense and I hope this is widely shared in the community. 🙏