Agile as Trauma
doriantaylor.com
doriantaylor.com
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.
- Pure Waterfall
- Code-and-Fix.
- Spiral.
- Modified Waterfalls.
- Staged Delivery.
- Design-to-Schedule.
- Evolutionary Delivery.
- Design-to-Tools.
- Commercial Off-the-Shelf Software.
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.
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.
"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.
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 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.)
Anything naming itself agile or SAFe always lead to depression and my withdrawal and disengagement.
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?
The fact that management loves the term "sprint" tells you something about the motivations of management-induced agile: artificial urgency.
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!"
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!")
It's such a clownshow.
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.
#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)
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.