Agile software development bases on four core values (paraphrased to make them more drastic but not change them in their meaning):
- Proper tools are not important
- Documentation is irrelevant
- Donāt have a contract to adhere to
- Do not follow any plans
I am not surprised that this fails miserably.
Iāll rephrase them, except in good faith:
-
Talking directly to the people about the work is better than a 95 state JIRA pipeline
-
Document your finished working work, not every broken POC, because thatās a waste of time
-
If the contract isnāt actually going to meet the desires of your stakeholders, negotiate one that will
-
If you realize the plan sucks, make a better plan.
My company paid to have Kent Beck come to workshop with our Sr devs. I expected to dislike him, but he won me over pretty quick.
I donāt remember what it was, but someone was like āKent, we do X like you recommend in the manifesto, but it creates Y, and Z problem for usā
And he was like āSo, in your situation it isnāt providing value?ā
Guy was like āNoā
āThen stop doing it.ā
Itās not hard. Itās the most fucking common sense shit. I feel bad for them because these guys came from a world where there were these process bibles that people were following. So they wrote like, basically a letter saying āif your Bible doesnāt serve you, donāt follow itā
And all these businesses dummies were like āoh look, a NEW bible we can mindlessly followā
It assumes that: devs can and have the right to talk to the final user, devs can negotiate anything, and devs can make plans. Where Iāve used agile, the whole circus was taken hostage by the managers and there was nothing you could do about it.
Youāll tell me itās not real agile, but itās like real communism, Iāve never seen it.
I mean, Iāve never seen a real platypus but Iām not going to use that as a justification for why they canāt exist.
I donāt know what to tell you. Itās a spectrum. Iāve worked in shops that claimed to be agile but to them, that just meant JIRA and story points. Iāve worked at places where agile meant having daily standups.
And Iāve worked places where there actually was a genuine attempt, and that was an awesome place to work.
Iāve worked on supposed āAgileā teams that operate this way, and worked on an Agile team that actually work ridiculously well. The biggest issue with Agile isnāt the philosophy, itās when management starts using it to cut costs. This comment is what it turns into. Notice that every single one of these points lower cost. But one of the main assumptions of Agile is that the workers control the work, managers support the workers. The places Iāve been where Agile didnāt work it was because management was unwilling to buy into this basic assumption, then use Agile as a crutch for not giving the team what they needed to be successful.
The one successful team I was on that was Agile, the entire group of around 12 worked directly with the customer, and our managerās role was to ask āwhat do you needā. It was hands down the best dev role I was ever in (before I became a teacher).
I understand the frustration; almost nowhere does agile ārightā. However, this is a gross misrepresentation of the philosophy.
Specifically it leaves out and ignores this very important part:
That is, while there is value in the items on the right, we value the items on the left more.
As seen on agilemanifesto.org
The base philosophy is meant to remind us what we are here to do: make software (or whatever project weāre working on), not become dogmatic about processes or tools or get bogged down in peripheral documentation.
This just in: intentionally misrepresenting something has a 100% chance of it being misrepresented.
Letās try again:
- proper tools are important, but not as important as the people using them
- documentation is important, but not as important as the software functioning correctly
- working with the customer to accomplish their needs is more important than adhering to the letter of a contract
- plans are important, but dogmatically applying them above the spirit of their intent is harmful
