Agile Is a Tainted Term(pcloadletter.dev)
pcloadletter.dev
Agile Is a Tainted Term
https://www.pcloadletter.dev/blog/agile/
107 comments
As soon as "agile" became "Agile" with a capital A, the war was lost. "Doing" Agile is missing the point; one must be agile.
The closest I've found to agile is when a team says they use "extreme programming", but I still find it funny that even EP goes against the "Individuals and interactions over processes and tools", or at least walks a tightrope on whether it's a process or not.
I see people kind of assuming that this agile principle implies there should be no process at all. Do you make that assumption or where does the perceived contradiction come from?
There is a human tendency for absolutes, black and white, binary, either-or thinking, and it seems to manifest no matter what.
If this is happening here, this is a good example, as the front page of the Agile manifesto is laconically short, 10 lines of text ( https://agilemanifesto.org/ )
And includes the repeated formulation "x over y" - NB this is not "x, instead of y", not "x, not y" And then clarifies with "That is, while there is value in the items on the right, we value the items on the left more."
If people can read an absolute from that, then they can read it anywhere.
If this is happening here, this is a good example, as the front page of the Agile manifesto is laconically short, 10 lines of text ( https://agilemanifesto.org/ )
And includes the repeated formulation "x over y" - NB this is not "x, instead of y", not "x, not y" And then clarifies with "That is, while there is value in the items on the right, we value the items on the left more."
If people can read an absolute from that, then they can read it anywhere.
Yeah, I only remembered the four main lines and was, uh, "pattern matching" with other language stuff.
More or less same mistake as (unfortunately) conflating "I don't like X" with "I dislike X", which also falls into into the black-and-white tendency you mentioned.
More or less same mistake as (unfortunately) conflating "I don't like X" with "I dislike X", which also falls into into the black-and-white tendency you mentioned.
Now that you point this out, I was actually making that assumption yes. My bad.
In my defense, I forgot about the fine print on the agile manifesto website.
In my defense, I forgot about the fine print on the agile manifesto website.
I wish more people understood this. Nobody should be arguing for Agile anymore. Don't say "no, but-" or "that is not what the Manifesto says-" because you're only strengthening the case for Agile as propagated by the fraudmasters simply by virtue of it sharing the same name as the thing you're arguing for. Leave the term behind, find something else.
> Leave the term behind, find something else.
Asking software engineers to name things? Now you have two problems.
Asking software engineers to name things? Now you have two problems.
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!
How many FCKs do you give?
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!
How many FCKs do you give?
OKR is an Objective + KPIs.
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.
The thing that made agile ripe for fraudsters/cargo cultists was how vaguely it was defined.
That can be fixed by defining something new, more precisely.
That can be fixed by defining something new, more precisely.
> 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 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.
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.
"Cargo Cult Agility" should be a term!
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 )
[2] You might be lucky to find a manager who really understands PDCA or OODA. https://en.wikipedia.org/wiki/PDCA , https://en.wikipedia.org/wiki/OODA_loop . Unfortunately these are also somewhat prone to cargo-culting. On the "upside", OODA cargo-culting may be subject to natural selection.
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 )
[2] You might be lucky to find a manager who really understands PDCA or OODA. https://en.wikipedia.org/wiki/PDCA , https://en.wikipedia.org/wiki/OODA_loop . Unfortunately these are also somewhat prone to cargo-culting. On the "upside", OODA cargo-culting may be subject to natural selection.
> 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.
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.
Is it really vaguely defined?
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.
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.
>Is it really vaguely defined?
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.
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.
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.
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) .
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) .
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.
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.
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.
I think you've read my comment backwards!
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.
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.
Well, they think they need that. What they really need is accomplish some business goal.
The Agile manifesto doesn't say anything about the former because it would defeat its own purpose.
The Agile manifesto doesn't say anything about the former because it would defeat its own purpose.
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.
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.
Don’t name it, just do. As soon as you name it and becomes a bit known fraudsters come, take the name and begin the grift
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.
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.
Page wont load for me. BUT, this title is the first sensible thing I’ve heard someone say about Agile in 10 years.
I just don’t use the word Agile. Too many people like it for the wrong reasons, or hate it for the wrong reasons. Everyone has a different understanding of it. It’s just not useful.
If I say “let’s use Agile” it’s just going to lead to arguments and misunderstandings.
Id always rather be more specific about which Agile idea I think will be useful. E.g. “let’s build a prototype before we waste time planning too much detail” or “lets get something built and released so we can learn more about what our customers want” etc.
I just don’t use the word Agile. Too many people like it for the wrong reasons, or hate it for the wrong reasons. Everyone has a different understanding of it. It’s just not useful.
If I say “let’s use Agile” it’s just going to lead to arguments and misunderstandings.
Id always rather be more specific about which Agile idea I think will be useful. E.g. “let’s build a prototype before we waste time planning too much detail” or “lets get something built and released so we can learn more about what our customers want” etc.
Your last paragraph is basically the conclusion of the article. “Agile” is so loaded it’s not worth using
Agile/Scrum is one of those things that are impossible to criticize. You can come up with a well-reasoned critique of Agile and there's always some Agile evangelist that pops up to tell you that you're not doing "real agile" and, therefore, your experience is invalid.
At the same time, I have now done software engineering for over a decade, in many roles and teams, and I have never seen Agile or Scrum to lead to the development of a good piece of software. I guess we were using it wrong.
At the same time, I have now done software engineering for over a decade, in many roles and teams, and I have never seen Agile or Scrum to lead to the development of a good piece of software. I guess we were using it wrong.
I’ve seen agile done well once. Yes it does happen. The process was not described, spoken of or even considered. It just existed between a few like minded decent engineers.
Their manager got an “agile PM” forced on them and it broke.
The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.
Their manager got an “agile PM” forced on them and it broke.
The problem is charlatans, dictators and career ticket shufflers that deliver little to no ROI and generally abject chaos.
Exactly the same thing here. Once some interloper with paper qualifications and no tech background rocks up and says "this is how agile works!" you're doomed.
The only time I've ever seen this not happen was when we had a 55 year old delivery manager who viewed his job as facilitating team meetings in a way that meant everyone got the chance to speak and that consensus formed. Didn't try to dictate process or anything, just made sure everyone got heard and that decisions got made. He was patient enough to wait and not force the issues, too.
The only time I've ever seen this not happen was when we had a 55 year old delivery manager who viewed his job as facilitating team meetings in a way that meant everyone got the chance to speak and that consensus formed. Didn't try to dictate process or anything, just made sure everyone got heard and that decisions got made. He was patient enough to wait and not force the issues, too.
Not everyone deserves a voice in every conversation. We had an office assistant once’s that had really strong opinions about how to implement features. They were not well informed.
Organisations make it very hard to be that manager. On top of the human tendency to overmanage there's often push from top for "more visibility and accountability" which results in forcing stuff rather than facilitating.
Blame Mckinsey and their ilk: "what can be measured can be managed".
(I refuse to utter the above phrase without accompanying it with tjis: "not everything that counts can be counted")
(I refuse to utter the above phrase without accompanying it with tjis: "not everything that counts can be counted")
It's worse than that. Any sufficiently motivated person can phrase data any way they choose, particularly when their bonus is tied to it. Nor does the consumer of the data always validate that data. I've never seen a manager read a report they requested. That is on top of your suffix which I agree with a well.
I also had perfectly operating squads crumble to dust because of PMs, more than once.
I still don't understand the role of PMs when there are engineering managers, product owners and self-organizing teams involved.
I still don't understand the role of PMs when there are engineering managers, product owners and self-organizing teams involved.
I honestly don’t understand how teams in large companies operate without pms. In the initial 5 man design phase sure skip them but when it need 10 groups to deliver some small change that they give zero fucks about the pm is there to keep everyone annoyed enough to do their job.
It works easily without PMs if you have engineering managers and product owners.
Quality engineering has to be *repeatable*.
If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX.
I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.
If it’s not described, and only works via the “minds of a few engineers”, you get amateur treehouse-quality engineering like the 737 MAX.
I guess chance can make it work well like that “once” sporadically, but when you need to touch that code again to maintain it, we go back to the amateur treehouse.
I think that's a vast simplification. It doesn't have to be repeatable at all. Objectively repeatability is about elimination of waste and expenditure. The big one is qualification and testing because that's what filters all the crap out. Actually I've worked as an engineer where we had to throw 20% of the products we built out because they didn't pass qualification.
And of course that is where the cost savings are usually made because it is seen as a null function in some businesses. It creates waste and reduces delivery and ROI. Those are all symptoms of other problems in the business but that's how it is generally perceived. And sometimes clients are happy to receive muck if it's cheap.
But that's also how we get planes that crash and Microsoft firing their entire QA and delivering shit for the last half a decade.
And that in turn is because management and project management culture is data driven by people who have no idea what the fuck they are doing whatsoever.
And of course that is where the cost savings are usually made because it is seen as a null function in some businesses. It creates waste and reduces delivery and ROI. Those are all symptoms of other problems in the business but that's how it is generally perceived. And sometimes clients are happy to receive muck if it's cheap.
But that's also how we get planes that crash and Microsoft firing their entire QA and delivering shit for the last half a decade.
And that in turn is because management and project management culture is data driven by people who have no idea what the fuck they are doing whatsoever.
I once had to explain to a manager of hundreds of people why reproducibility in engineering (and science) is important. Not good.
What has been, in your experience, a repeatable process for quality engineering? How much does it depend on the kind of software one is engineering, or is it applicable to any kind of software with any kind of constraints?
Repeatable processes require long term strategy.
[edit] Too many of these people want tomatos, so they plant a tomato, when really they want seasonal tomatos, and need to consider a farm, and take into account growth cycles. The term I like is "sustainable development."
[edit] Too many of these people want tomatos, so they plant a tomato, when really they want seasonal tomatos, and need to consider a farm, and take into account growth cycles. The term I like is "sustainable development."
I was hoping for more actionable, or at least concrete, advice...
Some complexity is irreducible.
As mentioned by user "phkahler":
> 1) Come to work.
> 2) Look at the current state.
> 3) Decide what the product needs from you.
> 4) Do that.
> 5) Use git.
> Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).
> This is how my current job works and we are unbelievably productive.
[edit]
I like the book "phoenix project," and I think they wrote "Team Topologies" which I am curious to read.
[edit]
In general, psychological safety was the number one factor for productive teams, according to a massive google study. From this viewpoint, it's easy to see why there are so few productive teams, as there is little to no safety for most people. Remember though, "There are no silver bullets."
[Edit]
The goal should be continuous delivery imo.
As mentioned by user "phkahler":
> 1) Come to work.
> 2) Look at the current state.
> 3) Decide what the product needs from you.
> 4) Do that.
> 5) Use git.
> Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).
> This is how my current job works and we are unbelievably productive.
[edit]
I like the book "phoenix project," and I think they wrote "Team Topologies" which I am curious to read.
[edit]
In general, psychological safety was the number one factor for productive teams, according to a massive google study. From this viewpoint, it's easy to see why there are so few productive teams, as there is little to no safety for most people. Remember though, "There are no silver bullets."
[Edit]
The goal should be continuous delivery imo.
The charlatans are a serious problem in software engineering today.
The good news is that it is easy for engineers to start their own companies and keep these people out at first at least.
You will still get cold emails and LinkedIn messages from these people but you don't have to respond
You will still get cold emails and LinkedIn messages from these people but you don't have to respond
It's somewhat more difficult to start their own companies and eat though which is why a lot of us eat shit and work with project managers.
I work at a company that did Agile/Scrum ok - it wasn’t perfect but we had regular retros and we tried to improve our processes and we were given some leeway from management to have some of the work required to support those processes into our sprints.
Then the CTO left, and was never replaced, then the layoffs came and a competent PM was replaced with a junior. Entire design department replaced with a single junior as well. Engineering gutted. Ok, lay-offs happen but at least I still have a job.
Then came “we’re waterfall now”. You know what didn’t come with it? Actual planning, documentation or specs or anything typical of “waterfall”. Estimates are now guessed before anything is defined and turned into commitments. You know what we still had? “Daily stand ups”, “backlog grooming”, two week “sprints”, and no retrospectives. No opportunity or agency to try to make things better - just endlessly stuck in my own personal hell.
Now we have projects that are supposed to take 2 months now taking 6. We have last minute spec changes that require massive rewrites because UAT isn’t done until the end of the entire project. “PM is slow to write out requirements” so we’re basically expected to just guess what they are based on very small selection of unfinished design flows.
And of course, executive wonders “why does engineering take so long to deliver”.
I started calling this “scrumerfall” or even ”fragile”. It’s basically the worst of both with none of the positives.
I don’t know what point I’m actually trying to make…just get like ranting and this seemed like a good time lol
Then the CTO left, and was never replaced, then the layoffs came and a competent PM was replaced with a junior. Entire design department replaced with a single junior as well. Engineering gutted. Ok, lay-offs happen but at least I still have a job.
Then came “we’re waterfall now”. You know what didn’t come with it? Actual planning, documentation or specs or anything typical of “waterfall”. Estimates are now guessed before anything is defined and turned into commitments. You know what we still had? “Daily stand ups”, “backlog grooming”, two week “sprints”, and no retrospectives. No opportunity or agency to try to make things better - just endlessly stuck in my own personal hell.
Now we have projects that are supposed to take 2 months now taking 6. We have last minute spec changes that require massive rewrites because UAT isn’t done until the end of the entire project. “PM is slow to write out requirements” so we’re basically expected to just guess what they are based on very small selection of unfinished design flows.
And of course, executive wonders “why does engineering take so long to deliver”.
I started calling this “scrumerfall” or even ”fragile”. It’s basically the worst of both with none of the positives.
I don’t know what point I’m actually trying to make…just get like ranting and this seemed like a good time lol
> You can come up with a well-reasoned critique of Agile and there's always some Agile evangelist that pops up to tell you that you're not doing "real agile" and, therefore, your experience is invalid.
What I've seen the most is people putting up straw men in place of Agile, and proceed to attack the strawman in spite of being repeatedly pointed out they are pummelling a straw man.
What I've seen the most is people putting up straw men in place of Agile, and proceed to attack the strawman in spite of being repeatedly pointed out they are pummelling a straw man.
Problem is that managers actually tells you to follow that straw man.
Scrum is easy to criticise. Agile less so.
One such Agile criticism is about principle “that working software as the primary measure of progress”. I understand the sentiment but it’s not enough, it’s got to meet the customer’s needs.
Scrum is far too sprint release coupled. Sure you could separate them, but are you really doing Scrum then?
"Agile" was defined so vaguely in the beginning that it became a kind of template for everyone to project their (often contradictory) ideas and dreams on to.
Scrum fixed that by being as bad as it was precisely defined.
I can get what the originators of agile were getting at but they explained themselves super badly.
Scrum fixed that by being as bad as it was precisely defined.
I can get what the originators of agile were getting at but they explained themselves super badly.
Scrum is supposed to be training wheels for agile, not the end point.
I think a lot of ppl forget that.
I think a lot of ppl forget that.
I quickly searched for evidence that it was supposed to be that and found nothing except one essay on medium refuting the idea.
One of the nice things about scrum is that it has an official source who defines it and you can look at it to see what it is and what it is not intended to be.
One of the nice things about scrum is that it has an official source who defines it and you can look at it to see what it is and what it is not intended to be.
And Scrum is not even as strict as people paint it, honestly. It retains a lot of the good parts of Agile. It is a basic framework for a self-managing team.
The retrospective is where you can tweak the process, but you can honestly change things anywhere. Bad managers will resist change at any cost and will use Scrum as an excuse to resisting change, but that's true for any methodology.
The problem is it doesn't work when there's micromanagement, it doesn't work when there are waterfall-ish parts (eg: PMs not splitting tickets, QAs hogging releases). Scrum also doesn't work when the development team isn't empowered, or has no domain experts. But most methodologies also don't.
The retrospective is where you can tweak the process, but you can honestly change things anywhere. Bad managers will resist change at any cost and will use Scrum as an excuse to resisting change, but that's true for any methodology.
The problem is it doesn't work when there's micromanagement, it doesn't work when there are waterfall-ish parts (eg: PMs not splitting tickets, QAs hogging releases). Scrum also doesn't work when the development team isn't empowered, or has no domain experts. But most methodologies also don't.
>You can come up with a well-reasoned critique of Agile and there's always some Agile evangelist that pops up to tell you that you're not doing "real agile" and, therefore, your experience is invalid.
Just the typical "No True Scotsman" fallacy [1], happens all the time when there is no good defense of the position.
1. https://en.wikipedia.org/wiki/No_true_Scotsman
Just the typical "No True Scotsman" fallacy [1], happens all the time when there is no good defense of the position.
1. https://en.wikipedia.org/wiki/No_true_Scotsman
By the same logic, there are no actual quantum physicists, because various "quantum healers" outnumber them. So we need to admit that everything "quantum" is nonsense, otherwise we are committing the "No True Scotsman" fallacy.
Sometimes the fakes simply do outnumber the real ones.
Sometimes the fakes simply do outnumber the real ones.
Last time I checked, Agile had zero to say about documentation. Is there any improvement on this front ?
The second value of the agile manifesto is "Working software over comprehensive documentation."
It is important to remember also "That is, while there is value in the items on the right, we value the items on the left more."
https://agilemanifesto.org/
https://agilemanifesto.org/
What do you use that does lead to a good piece of software?
Having clear requirements, good communications with key stakeholders and empower the enginees.
That sounds familiar... Oh ! That's where agile ideas come from! http://www.extremeprogramming.org/
That existed before agile.
Good on agile for restating what works and putting it in an fashionable, easy to understand framework, then.
But bad on agile for letting charlatans co-opt the term.
But bad on agile for letting charlatans co-opt the term.
Agile does not really works. It sometimes works, exceptionally, usually the more you try to do the by the book agile the worst it gets. Every single time they make agile reform, everything stats to suck and everything turns into ritualized micro management.
I'm all for criticizing agile etc if it doesn't work, but this is such a generic complaint.
What's "by the book" agile? Scrum? The things in the manifesto? Something that some rando Scrummaster said?
And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?
What's "by the book" agile? Scrum? The things in the manifesto? Something that some rando Scrummaster said?
And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?
It is generic, because it is the most common result of agile.
> What's "by the book" agile? Scrum? The things in the manifesto?
Definitely scrum.
> And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?
Every single detail and aspect of your work is determined by someone or something else. You have zero individual autonomy, zero individual responsibility. And zero option to do something good or bad. "Self-organizing" just means that scrum master or coach or whoever is creating set of rules that dictate pretty much every aspect of work.
Yeah, it is not one person telling you how to do things. It is that every aspect of work is decided by someone else or some committee. When you have one person telling you how to do things you at least can adjust to them and negotiate some space with them.
> What's "by the book" agile? Scrum? The things in the manifesto?
Definitely scrum.
> And who is micromanaging? Both the Agile Manifesto and Scrum are about "self-organizing" teams. If someone is micromanaging, how is that self-organizing?
Every single detail and aspect of your work is determined by someone or something else. You have zero individual autonomy, zero individual responsibility. And zero option to do something good or bad. "Self-organizing" just means that scrum master or coach or whoever is creating set of rules that dictate pretty much every aspect of work.
Yeah, it is not one person telling you how to do things. It is that every aspect of work is decided by someone else or some committee. When you have one person telling you how to do things you at least can adjust to them and negotiate some space with them.
> "Self-organizing" just means that scrum master or coach or whoever is creating set of rules that dictate pretty much every aspect of work.
See, this is already not "by the book" Scrum.
The team decides those things in a retrospective, and as long as they are releasing in a reasonable timely manner, it's alright.
If someone is being unreasonable and putting their foot down too much, then it's a management issue that doesn't have anything to do with Scrum. Either the person is a dictator, or they don't have authority and there's no management to put an end to it.
Scrum also doesn't work when the team is burning in a building on fire, but we don't blame Scrum for that.
I'm all for shitting on it, but those problems have been happening in companies for millenia. Scrum won't fix them, you gotta fix each separate problem by itself.
See, this is already not "by the book" Scrum.
The team decides those things in a retrospective, and as long as they are releasing in a reasonable timely manner, it's alright.
If someone is being unreasonable and putting their foot down too much, then it's a management issue that doesn't have anything to do with Scrum. Either the person is a dictator, or they don't have authority and there's no management to put an end to it.
Scrum also doesn't work when the team is burning in a building on fire, but we don't blame Scrum for that.
I'm all for shitting on it, but those problems have been happening in companies for millenia. Scrum won't fix them, you gotta fix each separate problem by itself.
Three of the original signers of the Agile Manifesto are also the main people involved with creating XP[1][2][3].
The Agile Manifesto was just a bunch of people who were already doing XP, Scrum or some other lightweight process getting together and writing down the similarities between what they were doing. It's a blanket term invented to describe a variety of different processes, not an actual process.
[1] https://en.wikipedia.org/wiki/Kent_Beck
[2] https://en.wikipedia.org/wiki/Ward_Cunningham
[3] https://en.wikipedia.org/wiki/Ron_Jeffries
The Agile Manifesto was just a bunch of people who were already doing XP, Scrum or some other lightweight process getting together and writing down the similarities between what they were doing. It's a blanket term invented to describe a variety of different processes, not an actual process.
[1] https://en.wikipedia.org/wiki/Kent_Beck
[2] https://en.wikipedia.org/wiki/Ward_Cunningham
[3] https://en.wikipedia.org/wiki/Ron_Jeffries
What if the requirements are super clear but they change? When do you find out and what happens then? I've personally never had a project where the requirements were 100% clear and stayed exactly the same. Even when writing a v2 of an existing project from the ground up things tended to be unclear and subject to change.
The point is to use what ever works best for your team, not blindly follow some process that may or may not necessarily work for you.
Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.
Just as product requirements can change, so can the way we work. Just like there is not one singular product that solves everybody’s needs, there isn’t necessarily one process that does that either.
Sounds like you need a process that can be flexible, able to respond to change, some might say… agile ;-)
I kid, but I think the early proponents of Scrum and similar were trying to achieve a loose framework to do exactly what you’re talking about. The modern incarnations of these can be horrific, but the original intent was always to empower teams to make their own process. Ahh well.
Like so many good ideas (democracy, constitutions), you only really know how well they function once people are actively trying to subvert them. Scrum et.al. have failed in the face of corporatocracy. I honestly don’t know if decentralised structures (i.e. teams empowered to run themselves), can ever survive in large corporates. Which is a pity. Cities grow, but companies die. You have to jump off the dying colossus to find the new company that hasn’t yet succumbed.
I kid, but I think the early proponents of Scrum and similar were trying to achieve a loose framework to do exactly what you’re talking about. The modern incarnations of these can be horrific, but the original intent was always to empower teams to make their own process. Ahh well.
Like so many good ideas (democracy, constitutions), you only really know how well they function once people are actively trying to subvert them. Scrum et.al. have failed in the face of corporatocracy. I honestly don’t know if decentralised structures (i.e. teams empowered to run themselves), can ever survive in large corporates. Which is a pity. Cities grow, but companies die. You have to jump off the dying colossus to find the new company that hasn’t yet succumbed.
The modern variations of Scrum and Agile exist to empower certain people to rule over teams without having to do much, if any, work.
The team is self-organizing but person X is the decision maker in the process.
There is an engineering manager, but they will get overruled by person X more often than not.
The framework is simple, but person X will add new rules.
Agile/Scrum says people must understand the domain, but person X is the only one talking to stakeholders since engineers are "not people persons".
The team is self-organizing but person X is the decision maker in the process.
There is an engineering manager, but they will get overruled by person X more often than not.
The framework is simple, but person X will add new rules.
Agile/Scrum says people must understand the domain, but person X is the only one talking to stakeholders since engineers are "not people persons".
> The modern variations of Scrum and Agile exist to empower certain people to rule over teams without having to do much, if any, work.
I don’t think that’s why they exist, but I do think the structure is not robust to a large number of dysfunctions. This one included.
I don’t think that’s why they exist, but I do think the structure is not robust to a large number of dysfunctions. This one included.
> What if the requirements are super clear but they change?
You need to communicate with stakeholders then, to change requirements, explain mistakes, set new goals, and reprioritize tasks. Agile (SCRUM/Kanban/etc.) are designed with frequently changing requirements in mind. In SCRUM, this is done at sprint review/sprint planning stage. In Kanban, it's continuous process.
You need to communicate with stakeholders then, to change requirements, explain mistakes, set new goals, and reprioritize tasks. Agile (SCRUM/Kanban/etc.) are designed with frequently changing requirements in mind. In SCRUM, this is done at sprint review/sprint planning stage. In Kanban, it's continuous process.
Well then requirements were not 'super clear', they were simply incorrect and it doesn't matter in which way. A very bad start of any project, since beginning you are already putting out flames left and right
Individuals and interactions, over processes and tools.
By focusing on the product rather than the process.
How does that work? So you've already went through the steps of figuring out a process, or do you just pick one and stick with it - accepting shitty parts? What's the process?
1) Come to work.
2) Look at the current state.
3) Decide what the product needs from you.
4) Do that.
5) Use git.
Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).
This is how my current job works and we are unbelievably productive.
2) Look at the current state.
3) Decide what the product needs from you.
4) Do that.
5) Use git.
Steps 2 and 3 may involve communication. Step 5 is tracking changes. Have a PM that tracks main things people are working on and estimated dates (not dictated dates).
This is how my current job works and we are unbelievably productive.
I would argue that 3 and 4 already imply 5! :)
And IMO it also implies things like CI/CD.
And IMO it also implies things like CI/CD.
You failed as soon as you think "process"
A process is a hardcoded way of do thing, which is deficient because it cannot react to an ever-changing world
A better way to handle things is by defining "what" should be done, not "how" it should be done
A process is a hardcoded way of do thing, which is deficient because it cannot react to an ever-changing world
A better way to handle things is by defining "what" should be done, not "how" it should be done
I have the opposite view.
Everything you do -up to and including taking a leak- is a sort of process. Perhaps you don't think that particular example should be a corporate process, but that's not my problem :-P .
You can compose processes to get things done.
Processes can be made mutable or flexible by eg. incorporating decisions or iteration. Especially iterated processes can be very powerful (you can get a lot done with them).
Thinking of things in terms of processes instead of in terms of component steps each time frees your mind to worry about other stuff.
Compare it with dividing a program into functions. Once you've wrapped a task in a function, you can then design using the function, rather than worry about how to write the code from scratch each time. Same with process thinking: you don't have to get bogged down in particulars all the time.
That said, maybe you're thinking of the "Befehlstaktik" vs "Auftragstaktik" [1] approach to doing things. In which case we're arguing definitions instead (which can be easily resolved).
[1] https://en.wikipedia.org/wiki/Mission-type_tactics
Everything you do -up to and including taking a leak- is a sort of process. Perhaps you don't think that particular example should be a corporate process, but that's not my problem :-P .
You can compose processes to get things done.
Processes can be made mutable or flexible by eg. incorporating decisions or iteration. Especially iterated processes can be very powerful (you can get a lot done with them).
Thinking of things in terms of processes instead of in terms of component steps each time frees your mind to worry about other stuff.
Compare it with dividing a program into functions. Once you've wrapped a task in a function, you can then design using the function, rather than worry about how to write the code from scratch each time. Same with process thinking: you don't have to get bogged down in particulars all the time.
That said, maybe you're thinking of the "Befehlstaktik" vs "Auftragstaktik" [1] approach to doing things. In which case we're arguing definitions instead (which can be easily resolved).
[1] https://en.wikipedia.org/wiki/Mission-type_tactics
You should start with the developing of the product as is happens, then use Continuous Improvement process to improve the development process.
You can use SCRUM/Kanban/SaFE/LeSS, hybrid or other Agile methodology, or no process at all, but it will not help when people are not trained to be proper part of the process.
For example, a PM may replace SCRUM meeting with a status meeting, because it makes his job easier, while PM or other M should not attend a SCRUM meeting at all, unless called in by engineers. The proper moment for interaction between PM and engineer are beginning/end of a ticket, sprint review, and sprint planning.
You can use SCRUM/Kanban/SaFE/LeSS, hybrid or other Agile methodology, or no process at all, but it will not help when people are not trained to be proper part of the process.
For example, a PM may replace SCRUM meeting with a status meeting, because it makes his job easier, while PM or other M should not attend a SCRUM meeting at all, unless called in by engineers. The proper moment for interaction between PM and engineer are beginning/end of a ticket, sprint review, and sprint planning.
Yes. What I have said before, for the same reasons, is that when the average office that says "we do the Agile", what they mean is that they have top-down, upfront planned micromanagement via tools such as Jira. *
This has nothing in common with the values of the Agile Manifesto. In fact it's more like the opposite of them.
* I hate Jira. Jira is not the cause of the problem. People's desire for a tool like that is cause of Jira. Kill Jira, and it would soon be replaced with something much the same.
This has nothing in common with the values of the Agile Manifesto. In fact it's more like the opposite of them.
* I hate Jira. Jira is not the cause of the problem. People's desire for a tool like that is cause of Jira. Kill Jira, and it would soon be replaced with something much the same.
We’re going to be officially moving to Agile! Soon.
By which I mean the project planning committee has created a multi-hundred page document with precise BPM-style workflow charts (based on Jira, obviously), and non-technical managers have started being sent on multi-day training courses to learn how to follow them.
It’s going to be a shitshow!
By which I mean the project planning committee has created a multi-hundred page document with precise BPM-style workflow charts (based on Jira, obviously), and non-technical managers have started being sent on multi-day training courses to learn how to follow them.
It’s going to be a shitshow!
> the project planning committee has created a multi-hundred page document with precise workflow charts ... It’s going to be a shitshow!
A Waterfall of effluent, spilling from the end of the process pipe, branded "Agile!" (TM, sponsored by Atlassian).
What are you moving from ?
A Waterfall of effluent, spilling from the end of the process pipe, branded "Agile!" (TM, sponsored by Atlassian).
What are you moving from ?
Dave Thomas has a talk about this
Agile is Dead https://www.youtube.com/watch?v=a-BOSpxYJ9M
To oversimplify it, he says "agile" has become a noun when it was always meant to be an adjective. In other words, if you are "doing" agile, you aren't really being agile.
Agile is Dead https://www.youtube.com/watch?v=a-BOSpxYJ9M
To oversimplify it, he says "agile" has become a noun when it was always meant to be an adjective. In other words, if you are "doing" agile, you aren't really being agile.
A sales guy told me his team does Agile. I asked him what he meant.
“We have don’t have assigned desks”.
“We have don’t have assigned desks”.
Another problem is that the Agile OGs keep overselling their methodology.
They keep saying that waterfall just doesn't work, yet almost all commercially successful (and unsuccessful) software is produced that way, whether they claim to use Agile or not. Would it be better if they used "real Agile"? Of course! But you only ever have to be just good enough.
They keep saying that waterfall just doesn't work, yet almost all commercially successful (and unsuccessful) software is produced that way, whether they claim to use Agile or not. Would it be better if they used "real Agile"? Of course! But you only ever have to be just good enough.
I wish that was a joke, but it's Zed so... No, you can't replace customer collaboration with more programming. When you're in a programming hole of misunderstood solutions, you can't fix that by doing more programming. When things keep changing without good reasons, you can't fix that by doing more programming, etc.
He's not saying replacing customer collaboration with programming. He's saying replace bleeding clients dry under the pretense of customer collaboration with programming.
He's saying the customer collaboration is just a con for bleeding clients dry and he should just do programming. I read "just" as only/instead in this case.
As presently practiced they all indeed are cons for bleeding clients dry. I haven't met Zed, but I can't imagine he thinks he can read minds, he must ask at some point what the customer wants to get out of the project. But the endless bikeshedding meetings and piles of useless UML diagrams and other documents is indeed just a scam.
The most absurd thing of it all is that even in-house development organizations behave the exact same way, despite having the exact opposite incentives.
The most absurd thing of it all is that even in-house development organizations behave the exact same way, despite having the exact opposite incentives.
When things keep changing without good reasons, you
- tell the client to get their shit together
- fire the client
- walk away
- tell the client to get their shit together
- fire the client
- walk away
The rarely discussed cornerstone of Agile is trusting the team and letting them organise themselves. For most organisation this represents a huge internal change in power structure.
The Agile industrial complex can't really sell a message to their customers (i.e. managers) that the development teams should have the power and run themselves how they feel fit. This message amounts to "if this works, we can fire the managers". Not a popular message for managers.
So, instead of building on an agile foundation, companies just add some story points and funny sounding meetings on top of the old structure and nothing really changes. It is Agile cosplay.
The Agile industrial complex can't really sell a message to their customers (i.e. managers) that the development teams should have the power and run themselves how they feel fit. This message amounts to "if this works, we can fire the managers". Not a popular message for managers.
So, instead of building on an agile foundation, companies just add some story points and funny sounding meetings on top of the old structure and nothing really changes. It is Agile cosplay.
I’ll take this a step further too and say that if Agile is being introduced by management, it means they don’t trust their teams to organize themselves. Agile, as sold, can’t actually work in that environment. The battle is already lost.
That's right. It can't be pushed down from above. The team has to want to do this and take the power.
A manager can start work on this kind of culture shift without even saying the word "agile". They need to give their teams more trust and room to govern themselves. i.e. managers need to get out of the way. When a team is open to the idea of Agile or scrum, then the manager could ask the team if they would like training or coaching. But the ground has to be made fertile first.
A manager can start work on this kind of culture shift without even saying the word "agile". They need to give their teams more trust and room to govern themselves. i.e. managers need to get out of the way. When a team is open to the idea of Agile or scrum, then the manager could ask the team if they would like training or coaching. But the ground has to be made fertile first.
The agile approach is generally academic mumbo jumbo that is rarely effective/efficient in large-scale industrial practice. Coming from an industry where functional safety is paramount, I think the agile approach is rarely appropriate unless you want to effectively waste everyone's valuable time with unnecessary overheads. If the product has already been launched or is at a pre-launch stage AND the team is small and professional enough, it might even work, but then why bother with such processes and roles overheads in the first place!
Irrespective of the chosen approach, it’s crucial to systematically elicit requirements, document specifications, and rigorously verify and validate everything. Implementation should ideally be supported by thorough unit tests, and, most importantly, all artifacts must be traceable across different abstraction layers and to the required level of detail.
Irrespective of the chosen approach, it’s crucial to systematically elicit requirements, document specifications, and rigorously verify and validate everything. Implementation should ideally be supported by thorough unit tests, and, most importantly, all artifacts must be traceable across different abstraction layers and to the required level of detail.
Leaving aside the "agile is a philosophy, not a methodology" argument, there are well-defined agile methodologies other than Scrum. I've worked at a couple Kanban shops and, while our dev processes were far from perfect, most of the things people routinely hate about "agile" just didn't come up at all because they're actually Scrum features.
If the thing you don't like involves the words "sprint" or "standup," you are complaining about Scrum, not agile.