Agile as Trauma(doriantaylor.com)
doriantaylor.com
Agile as Trauma
https://doriantaylor.com/agile-as-trauma
29 comments
Agile is much more than Scrum. There many different ways to do Agile. Just as an example Scott McConnell has a great book called Rapid Application Development (1996) where he documents many best practices and approaches that are essentially Agile, but that book predates the signing of "The Agile Manifesto"(2001). One of the practices is that you should carefully select the project life cycle model. Among the options that are documented in the book:
- Pure Waterfall
- Code-and-Fix.
- Spiral.
- Modified Waterfalls.
- Staged Delivery.
- Design-to-Schedule.
- Evolutionary Delivery.
- Design-to-Tools.
- Commercial Off-the-Shelf Software.
Thanks for the reference, this will make for some interesting reading.
Agreed, I think the problem is the agile industrial complex has settled on scrum training, so when your CTO buys into agile, that is what you get. The consultants and training programs are all the same orthodoxy. Further, whatever flavor they decide on at the top ends up being applied to a wide range of teams below, which otherwise would naturally have different project life cycle models...
A firm I was at not only had agile scrum firm-wide, but mandated we all have same length sprints ending on the same day of the week. This way we would all be "aligned". Also it meant it was impossible to book a conference room as they were 200% subscribed on sprintmas day by all teams... After 6 months they at least decided we could at least start/end on different days.
Agreed, I think the problem is the agile industrial complex has settled on scrum training, so when your CTO buys into agile, that is what you get. The consultants and training programs are all the same orthodoxy. Further, whatever flavor they decide on at the top ends up being applied to a wide range of teams below, which otherwise would naturally have different project life cycle models...
A firm I was at not only had agile scrum firm-wide, but mandated we all have same length sprints ending on the same day of the week. This way we would all be "aligned". Also it meant it was impossible to book a conference room as they were 200% subscribed on sprintmas day by all teams... After 6 months they at least decided we could at least start/end on different days.
[deleted]
Start with why Agile was created in the first place: The formalisms of critical path analysis and waterfall project planning did not work well for most software projects.
Why? Because software is often entirely new, contains no repeating tasks, Therefore schedule risk is high compared to other kinds of projects.
Agile gives a team flexibility to assign tasks to team members for each iteration. While legacy project management styles entail frequent replanning because you can't do a proper resource-leveled critical path analysis without a plan for resource deployment. Agile is not as precise about projections of project completion, but you know that precise scheduling is not possible for a lot of software development.
Agile gets slagged for wireframe-driven development. If your view of Agile is colored by people drawing pictures instead of understanding data and functional requirements, that's not why Agile was created.
Why? Because software is often entirely new, contains no repeating tasks, Therefore schedule risk is high compared to other kinds of projects.
Agile gives a team flexibility to assign tasks to team members for each iteration. While legacy project management styles entail frequent replanning because you can't do a proper resource-leveled critical path analysis without a plan for resource deployment. Agile is not as precise about projections of project completion, but you know that precise scheduling is not possible for a lot of software development.
Agile gets slagged for wireframe-driven development. If your view of Agile is colored by people drawing pictures instead of understanding data and functional requirements, that's not why Agile was created.
I have exactly that in my book, in chapter 4. The chapter outline is online and will give you a good idea of what to look for:
https://www.jamesshore.com/v2/books/aoad2/invest_in_agility
https://www.jamesshore.com/v2/books/aoad2/invest_in_agility
The theories are endless but the root cause remains the same. Management sees Devs/QAs as low grade disposable workers. The fact that anyone with a 2-day certificate and some contacts ends up managing dev teams is not because they duped management but because management didn´t care at all from the get go.
https://www.harvard.com/book/dying_for_a_paycheck_how_modern...
"Management" is a public health crisis like cancer, diabetes or heart disease. Nothing else and nothing more.
Anecdotal: In the Interview I found this in, Pfeffer cites a colleague who asked managers what books they read about their job: None. They were not reading at all.
"Management" is a public health crisis like cancer, diabetes or heart disease. Nothing else and nothing more.
Anecdotal: In the Interview I found this in, Pfeffer cites a colleague who asked managers what books they read about their job: None. They were not reading at all.
Hey hedberg10. Unrelated to this topic but I couldn't find your contact info and don't know if HN even allows private messaging.
I just want to say thank you for this comment you made 21 days ago https://news.ycombinator.com/item?id=28669421. I'm reading Learned Optimism at the moment, and following your list to have a better state for myself. And I think it's working. My life was on a downward slope somewhat and your comment (well, TeMPoRaL's too) turned it around. Thank you.
I just want to say thank you for this comment you made 21 days ago https://news.ycombinator.com/item?id=28669421. I'm reading Learned Optimism at the moment, and following your list to have a better state for myself. And I think it's working. My life was on a downward slope somewhat and your comment (well, TeMPoRaL's too) turned it around. Thank you.
You're welcome, friend.
I enjoyed the article, even though I didn’t agree with all its assertions. Unlike so many people who criticize the Agile movement, this author knows what they’re talking about, both with regards to Agile and the foundational ideas of software engineering.
I disagree with some of Dorian’s criticisms, but only to the extent that the Agile community is too big to neatly characterize. And, as with all (I suspect) really big communities, what the masses do and think isn’t really reflective of what those in the know do and think. Dorian admits as much:
> I’m sure these things exist in some form or other; the point is they don’t get nearly as much attention.
I have to concede the point, although I don’t have to like it.
Anyway. The things he criticizes are discussed I in the Agile community, and have been for many years. Most of them, you’ve probably heard of. It’s just that they’ve been drowned out by the din of the Cargo Cult, and in the case of the more popular ideas, it’s not widely known that they were introduced by people who were active in the Agile community. Here’s some pointers.
Anything higher up the chain than project management: Lean Startup. Lean Software Development. Kanban.
Specificity gradient: I don’t know what Dorian meant by this, and the link went to a YouTube video I couldn’t be bothered to watch, so let’s call this one granted.
Conceptual Integrity: Domain-Driven Design, specifically its Ubiquitous Language. The CHECKS pattern language. Fit and the BDD movement.
(As an aside: Dorian has fallen for the common myth that waterfall originated in Royce’s paper. But Royce’s paper was ignored until the 1980s, when it was brought into the limelight by Barry Boehm as a vehicle to criticize standard practice and promote his Spiral Model alternative. See Bossavit, The Leprechauns of Software Engineering.)
I disagree with some of Dorian’s criticisms, but only to the extent that the Agile community is too big to neatly characterize. And, as with all (I suspect) really big communities, what the masses do and think isn’t really reflective of what those in the know do and think. Dorian admits as much:
> I’m sure these things exist in some form or other; the point is they don’t get nearly as much attention.
I have to concede the point, although I don’t have to like it.
Anyway. The things he criticizes are discussed I in the Agile community, and have been for many years. Most of them, you’ve probably heard of. It’s just that they’ve been drowned out by the din of the Cargo Cult, and in the case of the more popular ideas, it’s not widely known that they were introduced by people who were active in the Agile community. Here’s some pointers.
Anything higher up the chain than project management: Lean Startup. Lean Software Development. Kanban.
Specificity gradient: I don’t know what Dorian meant by this, and the link went to a YouTube video I couldn’t be bothered to watch, so let’s call this one granted.
Conceptual Integrity: Domain-Driven Design, specifically its Ubiquitous Language. The CHECKS pattern language. Fit and the BDD movement.
(As an aside: Dorian has fallen for the common myth that waterfall originated in Royce’s paper. But Royce’s paper was ignored until the 1980s, when it was brought into the limelight by Barry Boehm as a vehicle to criticize standard practice and promote his Spiral Model alternative. See Bossavit, The Leprechauns of Software Engineering.)
lol i suppose i should clarify that royce's paper is "generally credited as being the origin of waterfall despite actually advocating against it" or something to that effect. i know boehm refers to it but didn't know boehm was the one who originally (ab)used it as a straw man, so thanks for that. ;)
oh yeah ps the specificity gradient (https://youtu.be/dDE_y7Qri9w which I recorded much later) is stewart brand/frank duffy "shearing layers"/"pace layers" stuff; see https://doriantaylor.com/shearing-layers-applied-to-the-web
I only ever enjoyed working in waterfall and „just in time“ environments.
Anything naming itself agile or SAFe always lead to depression and my withdrawal and disengagement.
Anything naming itself agile or SAFe always lead to depression and my withdrawal and disengagement.
Yes, and a lot of agile is kayfabe.
How much do we contort ourselves around taking something that is clearly waterfall but wording it in a way the agile management gods will accept.
Non-software example. Let's say you want to bake a cake.
* First you find a recipe.
* Then you check your pantry and make a grocery list of
* Then you go to the grocery and buy the ingredients on your list
* Then you return home and unpack the groceries and begin making the batter, and maybe in parallel the icing
* Then you bake the cake
* Then you let the cake cool enough
* Then you can apply the icing to the cake
* Then you let it set a bit
* Now you can serve the cake to users
The tasks are discrete, and for the most part have a strict order.
You do not need to "iterate" and discover the steps, since its something you've done before and there's well understood industry practice.
You can project the start to finish time, and it may or may not fit into your "sprint", which is entirely due to the arbitrary nature of sprint lengths.
MAYBE you can engage with users on the recipe selection, and then later to maybe taste the icing.. but that's about it. The customers does not give a damn about the ingredients, your grocery list, how long to bake it, or how long you let it cool, etc.
Non-software example. Let's say you want to bake a cake.
* First you find a recipe.
* Then you check your pantry and make a grocery list of
* Then you go to the grocery and buy the ingredients on your list
* Then you return home and unpack the groceries and begin making the batter, and maybe in parallel the icing
* Then you bake the cake
* Then you let the cake cool enough
* Then you can apply the icing to the cake
* Then you let it set a bit
* Now you can serve the cake to users
The tasks are discrete, and for the most part have a strict order.
You do not need to "iterate" and discover the steps, since its something you've done before and there's well understood industry practice.
You can project the start to finish time, and it may or may not fit into your "sprint", which is entirely due to the arbitrary nature of sprint lengths.
MAYBE you can engage with users on the recipe selection, and then later to maybe taste the icing.. but that's about it. The customers does not give a damn about the ingredients, your grocery list, how long to bake it, or how long you let it cool, etc.
Baking a cake is not analogous to software development. Bakers will bake the same product thousands of times. Developers will only “bake” a cake once. And they have to work with the cake eater to make sure he/she gets exactly the cake they want. In other words, developers write a new recipe every time. It might be inspired by similar recipes but each one is unique.
Agreed. There is something nice about seeing the project chug along as the seasons change, as opposed to the infinite two-week “sprint”
Sprint is an extremely unfortunate term.
Do people really think that "agile" somehow magically enables employees to work at an accelerated pace for two or three weeks without exhaustion, downtime, or any negative side effects, and then turn around and do it again, indefinitely?
Do people really think that "agile" somehow magically enables employees to work at an accelerated pace for two or three weeks without exhaustion, downtime, or any negative side effects, and then turn around and do it again, indefinitely?
Exactly it should be something like marathon with 2 week splits.
The fact that management loves the term "sprint" tells you something about the motivations of management-induced agile: artificial urgency.
The fact that management loves the term "sprint" tells you something about the motivations of management-induced agile: artificial urgency.
> Do people really think that "agile" somehow magically enables employees to work at an accelerated pace for two or three weeks without exhaustion, downtime, or any negative side effects, and then turn around and do it again, indefinitely?
Yes, they're called management, and all A/agile is an excuse for them to engage in micromanagement under a different name. "We're not _micromanaging_, we're iterating!"
Yes, they're called management, and all A/agile is an excuse for them to engage in micromanagement under a different name. "We're not _micromanaging_, we're iterating!"
Agile is a disciplinary practice that asks human beings to constitute themselves as policing/policed subjects of a distributed, decentralized gaze. You know you've won when you can get a team to argue with itself about not reaching zero on the burndown chart at the sprint review every two weeks regardless of context; sprint retros that must have items that went well/wrong/actionable as "nothing" (which is what a sprint really is) is unacceptable (at least where I've worked); "you mean nothing went well?!?!? Nothing went wrong?!?".
But more, I feel like the majority of expressions of power in my life, across domains, have been manifested themselves as "work on your self", for which we are all infinitely guilty of, even though the various articles of work are not your own and never belonged to you.
I once knew someone who would manipulate people by first getting them to avow to some value/principle statement, however general, then claiming that what they wanted you to do to be a tool to fulfilling that value statement that you just avowed to, no matter how indirect the actual relationship between those things, such that you were contradicting your own avowed values if you failed to comply. Gaslighting in the first degree, but I see some variant of this tactic in other domains, wherein the source of power assertion is, in the first step made anonymous ("I'm just asking questions"), then, in the second step, made out to be your own guiltiness ("you're shutting out intellectual skepticism and debate!")
But more, I feel like the majority of expressions of power in my life, across domains, have been manifested themselves as "work on your self", for which we are all infinitely guilty of, even though the various articles of work are not your own and never belonged to you.
I once knew someone who would manipulate people by first getting them to avow to some value/principle statement, however general, then claiming that what they wanted you to do to be a tool to fulfilling that value statement that you just avowed to, no matter how indirect the actual relationship between those things, such that you were contradicting your own avowed values if you failed to comply. Gaslighting in the first degree, but I see some variant of this tactic in other domains, wherein the source of power assertion is, in the first step made anonymous ("I'm just asking questions"), then, in the second step, made out to be your own guiltiness ("you're shutting out intellectual skepticism and debate!")
Ahhh, the burndown chart, the weird whip cracking behind our back. If after a sprint it's not zero, we have to put on a whole floor show about why that happened, if it's zero before the sprint ends, everyone gets a single pat on the back and the next sprint will be loaded with more story points.
It's such a clownshow.
It's such a clownshow.
Minor note: a Shibboleth is some artifact that determines whether one belongs to a certain in-group, not a vilified concept.
It is not "vilified" except in the sense that in The Bible the term was used to identify all the Scrum Masters on Pharaoh's pyramid project by asking them about schedule estimates. If they replied in story points they were executed.
It is quite easy to predict the competency of a software development company: simply take # developers directly involved in developing products and divide by # managers at all levels. The higher the value the more competent the company.
Interesting idea. I would change it like this.
#developers / #non-developers
Where non-developers are people involved in the project who don't actually write code. (e.g. resource managers, analysts, project managers, QA, product owners, product managers, leads, architects, SRE, etc)
#developers / #non-developers
Where non-developers are people involved in the project who don't actually write code. (e.g. resource managers, analysts, project managers, QA, product owners, product managers, leads, architects, SRE, etc)
I think it’s important to make a distinction between non-developers who can reduce developer productivity and those who can’t. Which is why I mentioned managers. But other than that yep good point.
I want to like this article but it sounds like the author is more concerned with signaling what they know vs. educating/enlightening the reader. It should be a genre of writing in itself if it’s done well and tastefully.
Agile vs Waterfall isn’t “Kayfabe”. Software developers genuinely believe that there is some rivalry because they’re uncritical and inexperienced with software development management layers and don’t know any better.
Agile vs Waterfall isn’t “Kayfabe”. Software developers genuinely believe that there is some rivalry because they’re uncritical and inexperienced with software development management layers and don’t know any better.
Things like * max team size * type of application * type of user * geographic distribution
A) Agile may work for a team of 5 sitting in the same office working on the latest dating app to MVP their way from text to sending dicks pics to sending xxx videos as they A/B test on their large userbase, iterating the UI design with color/font/button/wording changes along the way. You MVP because you aren't sure what the users want and have an easy way to measure it as you go, so there's no need for 6-12 month roadmaps, maybe, or at least you an convince yourself of that.
B) Agile may NOT work on a team of 25 sitting in 5 countries, working on replacing a legacy infrastructure application that say, moves your money from one financial institution to another. The users are.. other applications interacting with your infra, you can't A/B test moving real money, and you internally have had to derive a set of requirements based on existing processes/flows, and can lay down a 6-12 month roadmap with your project manager. There's no MVP of "well first we will work on sending integer dollar values, then we'll work on sending decimal dollar values". There's no UI so theres no buttons to add/remove or change the color, font and wording of the text forms. Etc
Many of us are a lot closer to working on Type B software than we are on Type A software.