The problem is that it's a neverending treadmill of naming if you do that. Every good idea will be taken over by fraudsters. A lot of good ideas are already tainted by this, and while you have to pick your battles, there's something to be said for standing your ground on naming.
> The problem is that it's a neverending treadmill of naming if you do that.
OKRs (Objectives and Key Results) have replaced KPIs (Key Performance Indicators) due to some kind of contrived negative connotation that became associated with KPIs over time
But they're the exact same thing.
Something else will replace OKR in a few years so that management can sound as if they're more in tune with the sensitivities of their employees and, yes, OKRs were a bit on the nose, so luckily we've got FCKs now, they're modern and progressive, like us!
This is just how language often works. A term is co-opted and becomes increasingly associated with more things. Rarely are people able to reverse this process, so to narrow the associations requires a new term.
> That can be fixed by defining something new, more precisely.
I do not think that we're going to find a single precisely-defined process that will work well for everyone.
The strength of the OG Agile thinking was the iterative, "inspect and adapt", "shorten the feedback cycle" thinking. Which is somewhat in opposition to your desire for a precisely defined process. The Agile manifesto specifically stated that "process" was one of the "items on the right" that had less value.
So what you propose is not a fix to it, it is a different mindset. It is process-first. And because it is a more rigid and inflexible, it is less suitable to the business of software.
I absolutely don't think we need a single precisely defined process that will work for everyone. That's scrum and it's shit.
I think we just need some criteria which can provide clear answers to whether you're doing agile or bullshitting around or doing cargo cult agile. The manifesto/principles aren't that but they should have been. Instead they were some sort of vague inspiring motivational bullshit. "Build projects around motivated individuals!". Yeah, ok whatever. No mention of the word iterate though.
My proposal isn't a different mindset. I actually think I have the same one as you because when I think "agile" my interpretation centers more around short feedback cycles and iterative development. I use those words. People who have done it use those words. The manifesto doesn't. The CEOs who want to bring in "agile consultants" while still keeping quarterly milestone planning sure don't. They think it's a kind of software they install in their devs are are generally oblivious to the idea that it means they have to change too. The fact that they do needs to be brought into sharp focus. The fact that the consultants who promise them waterfall in agile clothing are bullshitting needs to be brought into sharp focus.
My proposal is to codify more precisely the things which make "agile" "agile" so that it becomes at the very least harder if not impossible to bullshit about it. I'm not suggesting making it less flexible. I'm suggesting we describe what it is in a way that we can categorically rule out what it isn't.
And then give it a different name, to avoid all the baggage from the old one. Some name I can point to and say "we need to be doing that" which rules out at least 95% of the bullshit artists.
It turns out that iteration (and recursion) are pretty mind blowing concepts to have to explain to people. Like for instance just explaining why is it important to iterate faster?
I've gotten lucky explaining it once or twice, [1][2]; but mostly I think it needs to be something someone experiences somehow. Either by programming or engineering or some other way.
[1] Some engineers understand what a control loop is, and you can explain why iterating (faster) actually leads to better precision than trying to measure things precisely in one go inside the loop. ( https://en.wikipedia.org/wiki/Closed-loop_controller )
> for instance just explaining why is it important to iterate faster. I've gotten lucky explaining it once or twice; but mostly I think it needs to be something someone experiences somehow.
Agreed, your "once or twice" is once or twice more often than my success rate at that. You're better off finding an employer who already gets it, and hoping that they don't forget.
I find it perfectly precise in what it tells you what you need to optimize for. It just doesn't tell you how because it couldn't possibly know. But finding out is hard work.
What the fraudsters are telling you is that you don't need to do any of the things in the manifesto because they know everything already. A general lack of industriousness on the part of software companies is really what makes not just Agile, but the consulting space in general, ripe for fraud.
https://agilemanifesto.org/ does this look like a clear and precise proscription for a good way to engineer software? Or does it look more like a bunch of "inspiring quotes" from a discount southern baptist church website from the 1990s?
I learned this the hard way when I was younger when I tried to write some tests for some bugs and my boss told me that we needed to deal with it with meetings instead. People over process he said. I actually couldn't argue with that.
They couldn't be more precise than that because each team and project has their own set of constraints and capabilities that determines how they achieve the Agile goals.
I think the only problem is that the authors took for granted that everyone understands that it takes an actual empirical process and not just a bunch of magic incantations to do that, like the enterprise world seems to think.
>They couldn't be more precise than that because each team and project has their own set of constraints and capabilities that determines how they achieve the Agile goals.
Part of the reason I think we need this is to be able to categorically rule "agility" given the constraints a team is under. We need a framework that can say with crystal clarity that if you force waterfall planning on a team, they won't be agile no matter how good their coach is.
This needs to be a simple yes/no framework - something that could easily be answered with a questionnaire with objective answers to questions that can't be bullshitted. "Does your company do X, Y and Z?" "Ok, you've rejected agility".
This could include things like "will you rule out measuring productivity?" (Y/N) or "will you expect detailed plans from your team on the features they plan to build with milestones?" (Y/N). "Will the team have unfiltered access to the customer?" (Y/N). These questions need to be the awkward kinds of questions that managers who want waterfall in agile's clothing will have to answer wrongly.
>I think the only problem is that the authors took for granted that everyone understands that it takes an actual empirical process
The authors never even mentioned the word empirical. When I said that the vagueness of the agile principles let people project their own desires onto what "agile" is, this is exactly the kind of thing I meant.
I think empiricism is quite possibly something that ought to be included in an "agile v2.0" though. For me agility does mean doing a series of small experiments on lots of different things and keeping/expanding on the things which work and dropping the things which don't. However, that's something I picked up by myself. The principles didn't teach me to do that.
The way you word it, it sounds very much like a cargo cult phenomenon.
Copying the external trappings (Towers, runways, procedures.) , not the underlying goals or process (shipping cargo across the pacific).
I only do a small number of projects myself, but my understanding is that in a lot of places, people might follow "the agile process", rather than that they are aiming at actual Capital-A-Agility (where any and all process is merely a means to that end, and is rapidly tuned and adjusted as required) .
It was a general philosophy of how people can work together.
It lacked any of the specifics that typify cargo cults. It was the exact opposite of cargo cult - an actual understanding without any specific required rituals.
How would one go about generalizing goals in the cargo cult example? To me, it would be something like "achieve your business goals," which while true, is not super useful. Maybe that would have been a better description though, given how much commodification is prioritized.
A customer of the software product need to know that after spending of $X dollars for Y days he will receive Z. In a working Agile project, PM must calculate team velocity and then use it to predict arrival time and expenses, then add/remove developers or features to meet budget and/or dead line. Agile manifesto says nothing about that.
Perhaps the customer does want to spend $X to receive Z, this is fine. Probably they should consider buying something off-the-shelf.
Alternately, a different thing the customer might want is to Solve Their Problem; which is a fundamentally different thing, and requires a fundamentally different process.
The customer can demand that, but they need to understand that that also demands waterfall. It's unrealistic to have that kind of expectation and get anything other than cargo cult agile.
There are lots of consequences of doing "agile" properly that go way above the programmers' heads. That includes clients being able to specify requirements and price but not both at the same time.
I've worked on tons of teams where it was dictated from up on high that we should do agile and also do waterfall planning (always called something else). Agile consultants often have a tendency to accommodate this contradiction because up on high controls the purse strings and they need to eat.
The danger is that over time the things they do to eat become their identity and the genuine people get washed out of the industry.
We do need a sensemaking framework and a term which can be used to rule this type of thing out.
This has been my favourite approach as well. Once you label something, you get discussions about what is and isn't the label. Once you label something, the debate on semantics starts and the discussion of the problem stops.
At the same time, unnamed things exist in a state where you can't even think about them without thinking about what it really is. You don't have a word for it, so you have to use the description.
And that makes it easier to change too, if it doesn't work or when circumstances change.
