> These things might be reasonable in a startup with a dozen people, but we have over a hundred thousand. My opinion is that once an organization is a certain size, everything really needs to be written down and easily accessible. I shouldn't have to regularly ask people how to do basic things, it should be on a wiki. If it's complicated, it should be in a training video, or a user manual.
> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
I remember when my employer adopted agile. One of the first things they did was lay off their team of technical writers.
Also you wasting your time flailing about probably makes some manager's budget numbers look good, because they got to "save" the money that would have prevented you from flailing about.
Indeed. It is too easy to read this as a rejection of tools, processes, documentation, and plans. That interpretation makes it harder for at-the-coalface employees to get help from leaders when they...
- actually need tools and processes designed to set the conditions for healthy interactions among individuals.
- actually need to spend time improving the documentation to enable them to produce working software.
- actually need to have a meeting-of-the-minds so they can collaborate with customers.
- actually need to spend some time planning so they can respond effectively to change.
Part of the problem here is that good technical leadership is waaaaaay more difficult than can be reflected in a 4-point manifesto. Whole books[1] are written about it. Part of the problem is information flow. It takes courage to speak clearly enough to tell leadership that they're so focused on being agile that it is harming social trust in their organization and preventing their teams from acting with agility.
[1] recommendations: The Toyota Way, Leadership is Language, Ego is the Enemy.
Maybe I have been lucky to never have experience a process heavy work place, but those two parts of the manifesto never made much sense to me.
Going Agile basically meant a return to caveman times. The only way to know anything about the code base is for the tribe's Elders to sit around the fire and tell stories.
Code doing weird thing X? Is it a bug? Is it intended? No way to tell unless I interview everyone who has ever touched the code base, and they happen to remember why they did that.
I get that the manifesto says favor "this" over "that" but don't discard "that", but everywhere I have ever seen it implemented they discarded "that".
Im going to have to disagree based on personal experience at my huge ass fortune 50 megacoprp. They JUST started adopting agile...JUST, I kid you not many teams are still officialy waterfall, even officially agile teams are effectively waterfall. It's going to take another 5 years for anything to stop looking like waterfall. And let me tell you, as much as people hate agile, the old way is not working, it may even take the company down. Anyway having had no agile...OPs Post rings very very true in my ears. There is an obscene amount of tribal knowledge that needs to get aquired. Sometimes if you're lucky and in the right chat, there's a one-note that gets passed around. We just started getting wikis.. and now they're transitioning to a different vendor. So some high profile teams working on safety critical teams have docs on both...but they aren't the same and both are woefully out of date, also you need manger approval to get access to either of them.
Yeah, Agile is not the OP's problem. Some director made some comments about a direction, and zoom! Off all the middle managers went, trying to kiss up to him, and implement what he said in the most dramatic way, in order to get that next promotion, or at least more headcount. And now it's, "Just the way we do things around here. Like it or leave."
His problem, as with all these types of things, is management. Of all people, we here on this forum ought to be able to call a spade a spade. But even we fall victim to blaming the process or the tool. Over and over again, the problem is management, and we should call it out.
The biggest problem with large corporations is managers who sacrifice long-term company success for short-term personal success. Smaller corporations can often get rid of such managers, but past a certain size -- and that's not really very large -- bad managers can become entrenched as they hire and/or promote sycophants to prop up their power plays. I have 27 years in the blue-chip Fortune 250 world, and I've seen it over and over and over again.
We're going to have to change large parts of the tax code in order to fix this problem, so that companies do NOT get a tax break by giving stock options as compensation. Until that is no longer the case, you will have people -- and rightfully so -- deliberately and predictably responding to huge financial incentives to do LONG TERM damage to the company with SHORT TERM thinking. The C-levels should stop this nonsense, despite the tax incentives, but, of course, the problem is only worse at that level.
Agile might not be my problem, but even so what the comment you're replying to kind of sums up the situation:
> I remember when my employer adopted agile. One of the first things they did was lay off their team of technical writers.
We had a big round of layoffs a few years back. I don't know if technical writers were affected more than others, but we did have a team whose main job was to run training sessions; how to write better code, how to be a more effective technical organization, that sort of thing. That whole team was laid off.
Management may be the problem. It's hard to point the finger at any one person in particular when everyone is just trying to do what they need to do to ship product, and the underlying problem seems to be a sort of emergent behavior that you end up with if you get a bunch of generally smart, helpful, friendly people together and apply all the wrong incentives.
Stock incentives might be part of the problem, but I expect that's more of an issue for the upper layers of management. Lower-level manager can't individually do much to affect the stock value one way or the other. I think maybe a mandatory long vesting term could help. Like, if you're a CEO your stock doesn't vest for ten years. (Maybe "vest" is the wrong word, since that implies you lose it all if you move jobs before it vests. I'm thinking of a system where if you leave you still get the stock eventually.)
You're taking those statements out of context read just a tiny bit further and it says:
"That is, while there is value in the items on the right, we value the items on the left more"
So it's doesn't say forget all processes and tools. Also I would say that most of these automated things the OP is talking about are processes and tools.
Hang on, don't blame the agile manifesto here. Blame the management that adopted the agile manifesto as "do all the exact same things we used to do that didn't work, but call it 'agile'".
I totally can, and will. It's on them if they popularized slogans that can be too-easily misunderstood. That's meant that agile, in several respects, has been an exercise of throwing the baby out with the bathwater.
> Blame the management that adopted the agile manifesto as "do all the exact same things we used to do that didn't work, but call it 'agile'".
We’re now at a point where the widespread and rampant destruction that’s been wrought in the name of agile is so bad that it’s not reasonable to say “oh you’re not doing it properly”.
That excuse could be used to avoid responsibility for literally anything.
Hype bros use that to defend token scams (“you just don’t get it”).
There’s an increasing mountain of evidence that shows agile just doesn’t work, makes things actively worse by forcing the creation and then concealment by neglect of engineering problems, and (as discussed above) actively reduces documentation so that agile cheerleaders can pin their incompetence on the engineers that inherit their mess when they cruise on up the ladder oblivious of their failures.
All of this and not a shred of empirical evidence, ever, that it actually achieves anything other than obscuring management stupidity.
> There’s an increasing mountain of evidence that shows agile just doesn’t work
Do you have any keywords I can search for to find this evidence?
I haven’t looked at in in ~4 years, but the Project Management Institute (PMI) used to publish some reports based on surveys that said ~70% of corporate projects fail. I am interested in comparing the evidence you’ve seen with the evidence the PMI has put together.
Edit: I think the language is “70% of projects fail to realize the planned benefits”
I haven’t looked at it in years, so I could be way off. I believe that projects that are completed 2 weeks late are classified as failures the same way a project that is abandoned half way through is.
Good ol’ intent vs impact. If you’re proselytizing something, it shouldn’t be judged by your intentions or how true it is, but the impact it has on the world. Agile was not great in that regard.
If I hear that damn mantra again, I'm going to puke. Xtreme Programming had it right
If you aren't writing the damn manual, you aren't delivering an entire dimension of product to your user.
I sat down a little while ago to an old 80's handheld digital business organizer. The device itself was meh.
The manual tho! My God, I'd forgotten what it was like to read a primer on a product that had actually had some effort put into it. People think UX replaces training/SOP's/manuals, and it really doesn't. Your manual is how you mass produce user expertise. Your manual, at least by consumer's opinion is the difference between Yet Another Agile Heap Of Kludged API's and Business Processes and a truly coherent whole.
The problem with most Agile extremists though, is they never take Minimum viable documentation to heart. Or they completely externalize the cost of clear, complete communication to the User. If I had to put my finger on why, it would be because Engineering spends too much time writing and not enough time using their code outside of bench testing.
This isolates from the consequences of poor decisions; and prevents people from facing the One Great Problem of Humanity: Communication.
Keep a bucket handy, because you are going to hear it again, because it often isn't. The fact that a million people are acting entirely contrary to the spirit and text of the agile manifesto, but calling it agile, does not change that.
>> If I hear that damn mantra again ... never take Minimum viable documentation
> But... you're not doing it right. Like, not at all.
Nope, sorry. You can't honestly say someone's doing it wrong, especially when "it" is defined so vaguely, or when "doing it wrong" seems to emerge from the document at least as much as "doing it right," if not more so.
> Where on earth do you get "don't provide user manuals" from the agile manifesto?
Where do you get "provide user manuals" from the agile manifesto"? The problem is that it's most easily read as a rejection of documentation, in general.
> Working software over comprehensive documentation
and use it as a reason not to do documentation at all. It's ambiguous, and can clearly be read as "you should not work on documentation when there is software to work on", and there's always software to work on.
It's perfectly OK to blame the agile manifesto. Part of the issue with the agile manifesto is it was written by developers, which makes it sound credible. In addition, you have a lot of cult adoption by developers, which made it difficult to refute. Once law is written in stone and some boundaries are established, that's when business processes come in and do what they do best: see how to manipulate their actions around that language to get what they desire from what is accepted/legal. They tend to always find paths around the bounds that lead to new undesired behaviors.
I used to run public community driven online video game servers in a different era and they were quite popular, sometimes the most active/hearts in their communities. One thing I always struggled with was writing down rules for player behavior on the servers. Once I write a rule it does two things: establishes what NOT to do explicitly, but opens a huge gray area of what isn't explicitly defined that can be done or opens up a subjective gray area that shouldn't be done but is not clearly defined. I now have to enumerate everything I don't want people to do which may be a massive list if you want clarity and no ambiguity. People get creative, always, and find new undesirable behaviors within your rule framework.
In the end, when you write some base rules, the only real solution is to continually ammend the bounds of your rule system over time to adapt and adapt, leaving less surface area to attack. This is why the US legal system is so darn complex. Basic constitional laws are established, some explicit don'ts, some explicit dos, and everything missing becomes questionable. I didn't want to do this on a video game server because... it's a video game server, nor did I have the time. I instead took the "it's private property and I am the tyrrant approach" and wrote a very simple rule to play with etiquette, then ruled over the server benevolently (at least I think so, joining anonymously for occasional sampling to adjust some server settings I found being abused and never banning people just because they were unenjoyable to play with) and it worked well. The servers remained the most popular servers.
The agile manifesto never adapted and business leadership is who calls the shots. A culture said let's adopt this and businesses said ok, sure, then this is how we're going to interpret these poorly defined bounds. You said this is what you wanted and everyone agrees so here you go. For the US constitution, vagueness and broadness works well because it was designed to be a living, extendable, changeable document. The agile manifesto is not. Given how well businesses skirt around the meaning of law to do legally, ethically, and morally questionable practices, what hope does some silly manifesto with no teeth someone writes have? Business rule as small little hierarchical dictatorships with tyrants ontop within a democracy and I've found the characteristics that compose leadership is often the opposite of benevolence. Be careful what you ask for in such environments, your requests will be twisted against you.
> Individuals and interactions over processes and tools
The points should be phrased "Processes and tools after individuals and interactions", meaning we want both, but one side first. In this case, it better implies we want processes and tools that work well for the individuals and their interactions.
Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact
> Poorly written or out of date documentation is worse than no documentation.
No, it's not. I _can_ be, but it can also be much better. Documentation is hard, we know that. But it's also incredibly useful in many cases. There are plenty of times where software is nearly useless, or the time required to use it becomes untenable, without documentation.
Honestly, I feel the same way about the code; if you can't be bothered to put a note in a file indicating what it's for (unless it's clearly obvious to a casual observer with limited domain knowledge), then you shouldn't be writing software at all.
If the software cannot be used for its intended purpose without some special knowledge, and that knowledge is not available to everyone who uses that software, then the people who don't have access to that knowledge are going to be unable to use the software for its intended purpose.
To some people in some kinds of organizations, this is a feature. The people with the hidden knowledge are more powerful than those without it.
If the software is written well enough that it doesn't need much or any documentation, then great! If that's not true, though, there had better be documentation if you want people to use it.
Here's the root cause of your bug:
https://agilemanifesto.org/
> Individuals and interactions over processes and tools
> Working software over comprehensive documentation
I remember when my employer adopted agile. One of the first things they did was lay off their team of technical writers.
Also you wasting your time flailing about probably makes some manager's budget numbers look good, because they got to "save" the money that would have prevented you from flailing about.