"... This means the speed of the project is proportional to the speed at which information moves between people's heads. Every obstacle to detecting and moving information between heads slows the project. Understanding and attending to this issue is essential to playing the game effectively. ..."
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
need changing also? I think the software needs to be delivered early and continuously, but not necessarily to the customer in production.
Delivering directly to the customer made sense when there was much less software in the world and nearly anything you made was useful. These days the last thing customers need is more half baked software to have to evaluate.
The proposal elevates team learning above delivering working software, which is contrary to the point of any programming job. Expect to be fired, a lot.
Don't distract. I'm genuinely trying to help us figure out how to build quality software, using AI, while avoiding all the problems we're seeing on so many teams.
No distraction. Genuine question. The whole point of the Agile Manifesto is to encourage removal of VP and similar roles from an organization; turning to a flat organizational structure. What motivates you, a VP, to latch onto that? How do you think that will help (with or without amendments)? Do you, perhaps, think in the age of AI your org will be better off if you 'step down' into a development/AI steerer role?
I was around when the agile manifesto was drafted. It wasn't about eliminating hierarchy in organizations. That's something that started happening later, around and after 2010. The agile manifesto was singularly focused at helping people see how to deliver software without leaning on the old waterfall methodologies.
The Agile Manifesto was published in 2001. You asserted earlier your software career began in 2006. What brought you to the Wasatch Mountains at that time when you had no ties to the industry?
Winston Royce, in his book, invented the waterfall methodology as a hypothetical of what not to do in order to help explain his core thesis. It is not a real thing. Why do you suggest the Agile Manifesto was created to help avoid leaning on a strawman?
The whole thing? That is what Agile Manifesto, and the associated 12 principles, is about: A thought experiment about flat organizational structures. Each of the 12 principles outline the things one needs to consider when they don't have a manager taking watch.
Where you find a VP, Agile isn't applicable. At least not in its entirety. It it is likely that you can still cherry-pick some ideas from it to apply to your non-Agile situation. "Do your manager's job for them" is often considered common wisdom after all.
You must have worked in some very unhealthy teams where psychological safety wasn't present. I'm sorry that happened. But don't confuse your experiences with that of everyone else's. There are lots of teams that are agile from the top down, including those that happen to hold a title with VP in the name.
It’s pretty obvious that Agile as practiced in most places is a failure, only highlighted by how fast coding has become. The problem it tries to solve was always the wrong one. It has become obvious that it isn’t the speed of iteration it’s the crappy requirements most organisations generate.
This is because your average BA or project manager have long gotten away with blaming programmers for missed deadlines. If you’ve worked both sides of the fence you know the users only vaguely know what they want, the BA role is essentially an incredibly lazy one (I made a wrong ticket but nobody knows it’s wrong until UAT so who gives a fuck about making them right). No matter how your sprint is organised or how many stupid ceremonies you insist on, if you can’t be arsed doing the hard work of specification the whole process is pointless.
I truly hope AI starts doing 100% of the coding so that the tide properly goes out on this farce.
Oh, my impression is that there's many iterative approaches to writing code (and doing other things besides). All of them work for a while, and then either someone "simplifies" out the iteration part, or in some way they render the iterative part toothless.
Basically you end up with something resembling a cargo cult, with all the rituals still there, but the tightly coupled feedback loop is missing.
Quick question: There's some sort of minor UAT ~once a week (or per whatever your cycle is), RIGHT? And then you find out umpteen things wrong (with the software and with the specs) , and you fix them; RIGHT?
If you have an actual commissioning or final UAT at the end of your project, it's just a formality with cake RIGHT?
I yeah, I’m holding it wrong that’s the problem. Agile suffers from the “no true Scotsman” fallacy to a massive extent. If the methodology was any good nobody would be arguing whether they were doing it wrong or not.
My contention is not “holding it wrong”, my contention is that it’s irredeemably flawed because the nature of it puts 99% of the actual (not fabricated) work and responsibility solely on developers, making the project manages and BA useless noise you have to fight just to get anything finished.
Heh, you are probably not wrong? It's not that you're holding it wrong. It's just you're more likely to have gotten a cargo cult version of it by now, so there's no way to hold it right in the first place. Agile isn't the first and isn't the last iteration of this particular pattern.
Extreme Programming, RUP, Spiral Model, RAD, DSDM, probably some variants of CMMI, ISO 9001 , we can continue this list for a while or even get into other disciplines. Each time you start out with a real feedback loop doing real work, and in the end everyone has cargo culted it. Mostly because a lot of people don't grok what feedback loops are, and think they can leave 'em out. I'm not even sure the project managers and BAs are the only ones to blame here. The whole organization conspires to replace scary feedback (and it really is scary!) with comfortable processes. Users don't want to talk to devs. Devs don't want to ship half-baked things. Managers need predictability for their spreadsheets. Everyone gets the cargo cult they deserve. "We mostly just took the good parts" := We left out the active ingredient.
After a while someone comes along with this radical new invention: "let's ACTUALLY apply a feedback loop", and here we go again.
To be fair, it DOES work for a while. you can start out dressing in drag and doing the hula[1] for all I care, so long as you iterate and run a feedback loop! At some point you'll actually successfully build a million dollar product anyway. .... Of course people will then copy you and dress in leaf skirts and dance all night long, and THEIR projects all fail.
This has been "Kim's overly oversimplified history of innovation in development methodologies". You're welcome, I'm sure.
> lot of people don't grok what feedback loops are
or they grok it very well, esp. the scary part..
Very few people want/enjoy negative feedback. On ANY level, bottom to top, the higher, the less probable to like/take it, esp. from underlings. Because that needs understanding of common goal at very different level, and incentives aren't aligned that way. Maybe in tiny companies / teams-left-on-their-own , corrective feedback works. for a while. But scaling it?
> We left out the active ingredient.
yea, thrown out the baby with the dirty water. In most cases last decade, i am only seeing rituals without essence, "monkey-policy" style. But i have not seen much dedication either, people want to get-on-with-their lifes, and doing work is just a vehicle
Sure personal feedback is scary, but to be frank it's only a small part of it, and doesn't need to get personal at all. And the machines participating in systems don't have feelings. (mostly at least ;-) )
Just to be sure, I'm talking closed loop control, right?
Observe current state, compare to desired state, figure the difference, act to reduce the difference, repeat until current state is close enough to desired state within tolerance. How else do you close the gap reliably?
Very important concept in tech (lots of control theory), biology (neural closed loop control), business (pdca), and military (ooda, guided weapons) . Some places it does work, FAA has Just Culture with blameless post-mortems; that works. Boyd had to fight for it, but military do have OODA in a lot of their theory now. Demming's PDCA is of course famous because of the japanese companies applying it (and then people started copying the idea and it didn't always work :-P) . But... people do keep missing the secret of tightly monitored closed loops and instead use ritualized open loops.
Agile started out the same way: plan on a short horizon, check how well you're adhering to it, improve both the planning process and the process under control, wash rinse repeat until you're on target.
this new "understanding" priority reminds me of :
from Alistair.Cockburn's 2004 "The end of software engineering and the start of economic-cooperative gaming " - https://web.archive.org/web/20140329202313/http://alistair.c...Even then , coding is not mentioned..
What do you think of it?
I like what you've done but doesn't
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
need changing also? I think the software needs to be delivered early and continuously, but not necessarily to the customer in production.
Delivering directly to the customer made sense when there was much less software in the world and nearly anything you made was useful. These days the last thing customers need is more half baked software to have to evaluate.
The proposal elevates team learning above delivering working software, which is contrary to the point of any programming job. Expect to be fired, a lot.
> I'm a VP of Engineering ... Happy to discuss and defend any of it.
The original Agile Manifesto abolishes VP roles. Are these amendments an effort to try and save your job?
Don't distract. I'm genuinely trying to help us figure out how to build quality software, using AI, while avoiding all the problems we're seeing on so many teams.
No distraction. Genuine question. The whole point of the Agile Manifesto is to encourage removal of VP and similar roles from an organization; turning to a flat organizational structure. What motivates you, a VP, to latch onto that? How do you think that will help (with or without amendments)? Do you, perhaps, think in the age of AI your org will be better off if you 'step down' into a development/AI steerer role?
I was around when the agile manifesto was drafted. It wasn't about eliminating hierarchy in organizations. That's something that started happening later, around and after 2010. The agile manifesto was singularly focused at helping people see how to deliver software without leaning on the old waterfall methodologies.
The Agile Manifesto was published in 2001. You asserted earlier your software career began in 2006. What brought you to the Wasatch Mountains at that time when you had no ties to the industry?
Winston Royce, in his book, invented the waterfall methodology as a hypothetical of what not to do in order to help explain his core thesis. It is not a real thing. Why do you suggest the Agile Manifesto was created to help avoid leaning on a strawman?
I'm curious: where exactly does it abolish VP roles? I don't see it.
The whole thing? That is what Agile Manifesto, and the associated 12 principles, is about: A thought experiment about flat organizational structures. Each of the 12 principles outline the things one needs to consider when they don't have a manager taking watch.
Where you find a VP, Agile isn't applicable. At least not in its entirety. It it is likely that you can still cherry-pick some ideas from it to apply to your non-Agile situation. "Do your manager's job for them" is often considered common wisdom after all.
You must have worked in some very unhealthy teams where psychological safety wasn't present. I'm sorry that happened. But don't confuse your experiences with that of everyone else's. There are lots of teams that are agile from the top down, including those that happen to hold a title with VP in the name.
No, words in a document do not change by an unrelated party having living some kind of experience. Not even if that experience is negative.
It’s pretty obvious that Agile as practiced in most places is a failure, only highlighted by how fast coding has become. The problem it tries to solve was always the wrong one. It has become obvious that it isn’t the speed of iteration it’s the crappy requirements most organisations generate.
This is because your average BA or project manager have long gotten away with blaming programmers for missed deadlines. If you’ve worked both sides of the fence you know the users only vaguely know what they want, the BA role is essentially an incredibly lazy one (I made a wrong ticket but nobody knows it’s wrong until UAT so who gives a fuck about making them right). No matter how your sprint is organised or how many stupid ceremonies you insist on, if you can’t be arsed doing the hard work of specification the whole process is pointless.
I truly hope AI starts doing 100% of the coding so that the tide properly goes out on this farce.
Oh, my impression is that there's many iterative approaches to writing code (and doing other things besides). All of them work for a while, and then either someone "simplifies" out the iteration part, or in some way they render the iterative part toothless.
Basically you end up with something resembling a cargo cult, with all the rituals still there, but the tightly coupled feedback loop is missing.
Quick question: There's some sort of minor UAT ~once a week (or per whatever your cycle is), RIGHT? And then you find out umpteen things wrong (with the software and with the specs) , and you fix them; RIGHT?
If you have an actual commissioning or final UAT at the end of your project, it's just a formality with cake RIGHT?
Else how is that even agile? :-P
I yeah, I’m holding it wrong that’s the problem. Agile suffers from the “no true Scotsman” fallacy to a massive extent. If the methodology was any good nobody would be arguing whether they were doing it wrong or not.
My contention is not “holding it wrong”, my contention is that it’s irredeemably flawed because the nature of it puts 99% of the actual (not fabricated) work and responsibility solely on developers, making the project manages and BA useless noise you have to fight just to get anything finished.
Heh, you are probably not wrong? It's not that you're holding it wrong. It's just you're more likely to have gotten a cargo cult version of it by now, so there's no way to hold it right in the first place. Agile isn't the first and isn't the last iteration of this particular pattern.
Extreme Programming, RUP, Spiral Model, RAD, DSDM, probably some variants of CMMI, ISO 9001 , we can continue this list for a while or even get into other disciplines. Each time you start out with a real feedback loop doing real work, and in the end everyone has cargo culted it. Mostly because a lot of people don't grok what feedback loops are, and think they can leave 'em out. I'm not even sure the project managers and BAs are the only ones to blame here. The whole organization conspires to replace scary feedback (and it really is scary!) with comfortable processes. Users don't want to talk to devs. Devs don't want to ship half-baked things. Managers need predictability for their spreadsheets. Everyone gets the cargo cult they deserve. "We mostly just took the good parts" := We left out the active ingredient.
After a while someone comes along with this radical new invention: "let's ACTUALLY apply a feedback loop", and here we go again.
To be fair, it DOES work for a while. you can start out dressing in drag and doing the hula[1] for all I care, so long as you iterate and run a feedback loop! At some point you'll actually successfully build a million dollar product anyway. .... Of course people will then copy you and dress in leaf skirts and dance all night long, and THEIR projects all fail.
This has been "Kim's overly oversimplified history of innovation in development methodologies". You're welcome, I'm sure.
[1] https://www.youtube.com/watch?v=Etkws_5mexg
> conspires to replace scary feedback
> lot of people don't grok what feedback loops are
or they grok it very well, esp. the scary part..
Very few people want/enjoy negative feedback. On ANY level, bottom to top, the higher, the less probable to like/take it, esp. from underlings. Because that needs understanding of common goal at very different level, and incentives aren't aligned that way. Maybe in tiny companies / teams-left-on-their-own , corrective feedback works. for a while. But scaling it?
> We left out the active ingredient.
yea, thrown out the baby with the dirty water. In most cases last decade, i am only seeing rituals without essence, "monkey-policy" style. But i have not seen much dedication either, people want to get-on-with-their lifes, and doing work is just a vehicle
Sure personal feedback is scary, but to be frank it's only a small part of it, and doesn't need to get personal at all. And the machines participating in systems don't have feelings. (mostly at least ;-) )
Just to be sure, I'm talking closed loop control, right?
Observe current state, compare to desired state, figure the difference, act to reduce the difference, repeat until current state is close enough to desired state within tolerance. How else do you close the gap reliably?
Very important concept in tech (lots of control theory), biology (neural closed loop control), business (pdca), and military (ooda, guided weapons) . Some places it does work, FAA has Just Culture with blameless post-mortems; that works. Boyd had to fight for it, but military do have OODA in a lot of their theory now. Demming's PDCA is of course famous because of the japanese companies applying it (and then people started copying the idea and it didn't always work :-P) . But... people do keep missing the secret of tightly monitored closed loops and instead use ritualized open loops.
Agile started out the same way: plan on a short horizon, check how well you're adhering to it, improve both the planning process and the process under control, wash rinse repeat until you're on target.
[dead]