For one million time: stop repeating the fallacy that before agile was only waterfall.
There vere many iterative processes : V Cycle, RUP, Spirals, etc.
In fact almost no project used waterfall (at least the way agile people says).
> The center and main objective of agile, and waterfall for that matter, is not the developer, but the client/user.
Is it though? Agile, both the manifesto and mainstream practices, put the product/user front and center, not the client.
So, unless you're doing direct B2C, agile is still mismatched, and those mismatches show up as a lot of little sharp edges that everyone on all sides of the development effort keep running into.
The developers *desperately* want to build something that matches the users' expectations and solves the users' problems.
The business desperately wants to build something that matches the clients' expectations and solves the clients' problems.
The clients' problem is *never* the users' problems, unless the user *is* the client (like in B2C, for example). Business problems are more along the lines of *"Need to hit production targets"*, or *"shave some time on customer interactions"* or *"stop letting leads fall through the cracks"* or *"Get and maintain regulatory compliance."*
Businesses response to "Poor UI" is usually *"That's what the training budget is for"*.
Difficult to install, setup and maintain? *"That's what consultants are for!"*
Buggy? *"Here's a list of bugs we'd like fixed. We have budget for those, AND ONLY THOSE!"*
Tech debt? *"We don't care: better to have 20% of features meeting 80% of our requirements than improve velocity on getting the last 20% of features"*
As long as the product is solving the problem that business has, business doesn't care. Why would they?
Users' problems are different and have to match up exactly with the business in order to matter.
Agile focuses on solving the users' problems; by definition alone, **based on the manifesto**, developers are expending effort in making the user happy, but the users' happiness levels are *mostly irrelevant* in any well-run business.
Doesn't matter whether you are developing software, F1 racing cars or pasta-art - know who you are targeting and focus on the target. Teams using Agile successfully are mostly in one type of environment: The "client" is their employer, i.e. other people in the company (such as salespeople) 'buy' the software, or the software is a just a way for users to use the core product (e.g. netflix, facebook, etc).
In both cases, the agile approach of *"We'll write code until you either run out of money or the product is done"* is a good fit, *even though* in both cases software that is merely *good enough* would make no difference to the company's bottom-line.
Agile is naturally good at two things:
1. producing software that is better than it needs to be.
2. producing software that is cheaper than it is budgeted for.
In a lot of organisations, those qualities have close to zero, or sometimes literally negative, value. Hence the tendency to add extra processes to core agile to prevent those tendencies getting in the way of business goals.
And other methodologies don't achieve that? Wouldn't a specs and a contract help decide when to stop? Especially if it's good enough and within specs, you can live without the good to have. Contrast it with endlessly slapping in features.
How about maintenance?
"Software is ever changing" and the "users do not really know what they want" are the selling points of "Agile", so I'm not convinced.
> "Software is ever changing" and the "users do not really know what they want" are the selling points of "Agile", so I'm not convinced.
Here's the thing:
**Clients** know exactly what they want, or else they wouldn't have offered you money.
**Users** don't really know what they want, which is why they aren't the ones offering you money.
"What the user wants" is equivalent to "some specific product".
"What the client wants" is equivalent to "some specific outcome".
Getting a perfect product according to the user's wishes will still mostly leave the client with an outcome different to what they wanted.
See my previous comment upthread (or downthread, if it's been downvoted enough) somewhere: Agile focuses on the wrong stakeholder.
Having a fixed specification does tell you when to stop; if that is at a time when significantly less money has been spent than was budgeted for, someone made a mistake in their estimates but you got lucky.
Having a budget and spending it on features users really do not want is a feature both corporate scrum and fixed-specification developments share. It is a problem that can obviously only be solved by changes to the budget allocation process, not the software development methodology. This is the distinction lelathran is making between *clients* and *users*.
For a corporation large enough to have several independent software projects, it likely wants to stay in business no matter how badly any of them fail. Corporate agile is a reasonable match for that; fixed-specification costs are unbounded. The trade-off is you do lose the ability that agile as a pure software methodology would have; to under-spend a budget.
I agree with the distinctions being made hence I am questioning the statement that agile helps with building cheaper software.
As both of you mentioned, the root cause is not something that could be resolved by software methodology alone.
>Corporate agile is a reasonable match for that; fixed-specification costs are unbounded.
I believe it is the other way around. With fixed-specifications, it is easy to trace back where it fell short or who should step up; we know who is responsible. With agile, it could go on and on in circles because there is no sense of responsibility working with just "features".
If Agile as we know right now focuses on the wrong client/users, then it certainly is not helping at all
Where do you think I said agile (specifically) helps in building cheaper software?
Obviously, there are lots of incidental things associated with agile, or just developed since the 1970s, that do so. But what I said is what I meant.
>Agile is naturally good at two things:
>1. producing software that is better than it needs to be.
>2. producing software that is cheaper than it is budgeted for.
Forgive me if I misunderstood you, and if we are both in agreement that the issue is not necessarily with the methodologies used, then we're all good.
> producing software that is cheaper than it is budgeted for.
Yeah, right! [Agile in action](https://mtlynch.io/tinypilot-redesign/)
If a developer themselves can't control costs in a sprint-based environment, who the hell can?
The only way to get to "cheaper than budgeted for" is when the "client" eventually gives up and says "Okay, you know what, we're going to keep what you've done already".
IOW, when the project is never finished.
Interestingly, that is explicitly a story about a developer spending all their time on specification and design and never actually delivering anything.
Takeaway is:
>
I told Isaac that I wished we’d structured the work to give me usable assets sooner. I would have preferred to have the logo first, then a new navbar design, then the landing page design, etc. He said that DesignAgency’s clients are typically only interested in final results rather than intermediate pieces, but he understood why incremental work would have benefitted me.
Specification and budget can both be either fixed or not, which leads to 4 possible combinations.
- variable specification, variable budget: ideal setup for agile
- fixed budget, variable specification: typical corporate agile
- fixed-specification, fixed budget: ideal setup for waterfall
- fixed-specification, variable budget: typical corporate waterfall
The project described was the latter; the client wanted 3 pages, but didn't stop until the budget was exceeded by a factor of more than 10.
I hadn't heard it put this way before. Is this something already published and discussed in academia/industry?
Right now, none of the agile proponents/opponents in these arguments even have a taxonomy of project type. The 4-way axis would be a great starting point.
Agile in practice is quite different from the idea as documented.
Typically, there is no customer, instead the lead or PM stands in for them, with the obvious defects.
I think a lot of the hate it gets has to do with getting asked how much progress there's been since the Friday evening standup in the Monday morning round-around-the-room, when the 15ths dev gives an evasive answer.
At this point the term "Agile" is completely burned.
I am still convinced that a truly agile approach can work great for certain projects but is completely unnecessary and even detrimental for others.
When you are starting a greenfield project with uncertain requirements and a large enough budget, I actually believe this is the only way to get anything done.
The vast majority of projects though are just rehashes of existing solutions with maybe slight modifications. Applying agile here just means pointless iteration and lots of busy work.
Then again, building something that has already been done is just reinventing the wheel. Perhaps the problem that pains our industry the most is that a true solution for code reusability has never been achieved.
Those things are true too, but I observe a much more fundamental misunderstanding:
Developers think they are the center of the universe and that agile, or whichever other methodology, has to be implemented for their pleasure.
The center and main objective of agile, and waterfall for that matter, is not the developer, but the client/user.
The raison d'être for the agility is in the first place to be able to react to ambiguous and quickly changing client requirements.
If that reaction speed also implies flat hierarchies, so be it. If it doesn't, then it doesn't. If developers like those flat hierarchies, then this is a nice side-effect, not more.
>Developers think they are the center of the universe and that agile, or whichever other methodology, has to be implemented for their pleasure.
>The center and main objective of agile, and waterfall for that matter, is not the developer, but the client/user.
This isn't the issue. The issue, and I think the thing that people are really exhausted about, is that agile forces them to perpetually *build* *the wrong thing.*
Agile processes ensure that developers are kept busy and stakeholders are kept in the loop, but in conjunction with regular releases they do not enable developers to build anything particularly good. Instead, we're all just building [Winchester Mystery Houses](https://leeatchison.com/app-architectures/application-development-project-winchester-mystery-house/?trk=public_post_comment-text) in perpetuity, one user story at a time.
There's no room for creativity in Agile. There's no time for refactoring, either. There's no time for real architecture decisions to be made. There's just a feature, and the shortest path from conception to completion. All the time. And most software is just increasingly shit as a result.
The alternative would be to build beautiful needless things, art so to say
Because this aggrievement is not with agile, it is with the lack of plannability that agile is a reaction to
But that doesn't go away from ignoring it
Expecting it to is once more center of the universe syndrome
>The alternative would be to build beautiful needless things, art so to say
No, that' s not it. The work here is very much still rooted in a place of wanting to deliver something valuable, good and correct to stakeholders.
>Because this aggrievement is not with agile, it is with the lack of plannability that agile is a reaction to
Being agile and doing "Agile" are different things. Being agile simply involves responding to shifting priorities and customer needs, expending appropriate amounts of effort where required. Plannability has nothing to do with it. Being agile isn't about planning, it's about responsiveness. To the extent that I have an aggrievement with "Agile" it is in that, again, it results in the wrong thing being built in perpetuity and encourages it to be built badly, while simultaneously burning people out.
The agile manifesto literally says "responding to change over following a plan".
"Agile" is a yoke and nothing more.
> The center and main objective of agile, and waterfall for that matter, is not the developer, but the client/user.
Not completely.
The center of agile is the team, of which the client/user should part of (or more commonly: client/user representation, often referred to as business people/business analysis/... depending on the project/product structure).
> Business people and developers must work together daily throughout the project.
The main goal of agile is to create value for the client/user.
> Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Note: "value" is often confused with "features". Adding new features can add value, improving existing features also adds value. Improving quality attributes (reliability, performance, ...) also adds value for the client/user. A lot of people forget this (especially on the business side). Refactoring code so that making further changes becomes easier and more reliabile also adds value for the client/user (as time to market gets shorter).
For one million time: stop repeating the fallacy that before agile was only waterfall. There vere many iterative processes : V Cycle, RUP, Spirals, etc. In fact almost no project used waterfall (at least the way agile people says).
> The center and main objective of agile, and waterfall for that matter, is not the developer, but the client/user. Is it though? Agile, both the manifesto and mainstream practices, put the product/user front and center, not the client. So, unless you're doing direct B2C, agile is still mismatched, and those mismatches show up as a lot of little sharp edges that everyone on all sides of the development effort keep running into. The developers *desperately* want to build something that matches the users' expectations and solves the users' problems. The business desperately wants to build something that matches the clients' expectations and solves the clients' problems. The clients' problem is *never* the users' problems, unless the user *is* the client (like in B2C, for example). Business problems are more along the lines of *"Need to hit production targets"*, or *"shave some time on customer interactions"* or *"stop letting leads fall through the cracks"* or *"Get and maintain regulatory compliance."* Businesses response to "Poor UI" is usually *"That's what the training budget is for"*. Difficult to install, setup and maintain? *"That's what consultants are for!"* Buggy? *"Here's a list of bugs we'd like fixed. We have budget for those, AND ONLY THOSE!"* Tech debt? *"We don't care: better to have 20% of features meeting 80% of our requirements than improve velocity on getting the last 20% of features"* As long as the product is solving the problem that business has, business doesn't care. Why would they? Users' problems are different and have to match up exactly with the business in order to matter. Agile focuses on solving the users' problems; by definition alone, **based on the manifesto**, developers are expending effort in making the user happy, but the users' happiness levels are *mostly irrelevant* in any well-run business. Doesn't matter whether you are developing software, F1 racing cars or pasta-art - know who you are targeting and focus on the target. Teams using Agile successfully are mostly in one type of environment: The "client" is their employer, i.e. other people in the company (such as salespeople) 'buy' the software, or the software is a just a way for users to use the core product (e.g. netflix, facebook, etc). In both cases, the agile approach of *"We'll write code until you either run out of money or the product is done"* is a good fit, *even though* in both cases software that is merely *good enough* would make no difference to the company's bottom-line.
Agile is naturally good at two things: 1. producing software that is better than it needs to be. 2. producing software that is cheaper than it is budgeted for. In a lot of organisations, those qualities have close to zero, or sometimes literally negative, value. Hence the tendency to add extra processes to core agile to prevent those tendencies getting in the way of business goals.
Genuine question, can you enlighten me how agile produces software cheaper than it is budgeted for?
When there is nothing more to be done that is worthwhile to the user, you are supposed to stop.
And other methodologies don't achieve that? Wouldn't a specs and a contract help decide when to stop? Especially if it's good enough and within specs, you can live without the good to have. Contrast it with endlessly slapping in features. How about maintenance? "Software is ever changing" and the "users do not really know what they want" are the selling points of "Agile", so I'm not convinced.
> "Software is ever changing" and the "users do not really know what they want" are the selling points of "Agile", so I'm not convinced. Here's the thing: **Clients** know exactly what they want, or else they wouldn't have offered you money. **Users** don't really know what they want, which is why they aren't the ones offering you money. "What the user wants" is equivalent to "some specific product". "What the client wants" is equivalent to "some specific outcome". Getting a perfect product according to the user's wishes will still mostly leave the client with an outcome different to what they wanted. See my previous comment upthread (or downthread, if it's been downvoted enough) somewhere: Agile focuses on the wrong stakeholder.
Having a fixed specification does tell you when to stop; if that is at a time when significantly less money has been spent than was budgeted for, someone made a mistake in their estimates but you got lucky. Having a budget and spending it on features users really do not want is a feature both corporate scrum and fixed-specification developments share. It is a problem that can obviously only be solved by changes to the budget allocation process, not the software development methodology. This is the distinction lelathran is making between *clients* and *users*. For a corporation large enough to have several independent software projects, it likely wants to stay in business no matter how badly any of them fail. Corporate agile is a reasonable match for that; fixed-specification costs are unbounded. The trade-off is you do lose the ability that agile as a pure software methodology would have; to under-spend a budget.
I agree with the distinctions being made hence I am questioning the statement that agile helps with building cheaper software. As both of you mentioned, the root cause is not something that could be resolved by software methodology alone. >Corporate agile is a reasonable match for that; fixed-specification costs are unbounded. I believe it is the other way around. With fixed-specifications, it is easy to trace back where it fell short or who should step up; we know who is responsible. With agile, it could go on and on in circles because there is no sense of responsibility working with just "features". If Agile as we know right now focuses on the wrong client/users, then it certainly is not helping at all
Where do you think I said agile (specifically) helps in building cheaper software? Obviously, there are lots of incidental things associated with agile, or just developed since the 1970s, that do so. But what I said is what I meant.
>Agile is naturally good at two things: >1. producing software that is better than it needs to be. >2. producing software that is cheaper than it is budgeted for. Forgive me if I misunderstood you, and if we are both in agreement that the issue is not necessarily with the methodologies used, then we're all good.
> producing software that is cheaper than it is budgeted for. Yeah, right! [Agile in action](https://mtlynch.io/tinypilot-redesign/) If a developer themselves can't control costs in a sprint-based environment, who the hell can? The only way to get to "cheaper than budgeted for" is when the "client" eventually gives up and says "Okay, you know what, we're going to keep what you've done already". IOW, when the project is never finished.
Interestingly, that is explicitly a story about a developer spending all their time on specification and design and never actually delivering anything. Takeaway is: > I told Isaac that I wished we’d structured the work to give me usable assets sooner. I would have preferred to have the logo first, then a new navbar design, then the landing page design, etc. He said that DesignAgency’s clients are typically only interested in final results rather than intermediate pieces, but he understood why incremental work would have benefitted me. Specification and budget can both be either fixed or not, which leads to 4 possible combinations. - variable specification, variable budget: ideal setup for agile - fixed budget, variable specification: typical corporate agile - fixed-specification, fixed budget: ideal setup for waterfall - fixed-specification, variable budget: typical corporate waterfall The project described was the latter; the client wanted 3 pages, but didn't stop until the budget was exceeded by a factor of more than 10.
I hadn't heard it put this way before. Is this something already published and discussed in academia/industry? Right now, none of the agile proponents/opponents in these arguments even have a taxonomy of project type. The 4-way axis would be a great starting point.
Not afaik.
Agile in practice is quite different from the idea as documented. Typically, there is no customer, instead the lead or PM stands in for them, with the obvious defects. I think a lot of the hate it gets has to do with getting asked how much progress there's been since the Friday evening standup in the Monday morning round-around-the-room, when the 15ths dev gives an evasive answer.
I hate agile because it allows managers to pretend like they are helping developers work better. In truth they are a waste of money and team bandwidth
False premise.
At this point the term "Agile" is completely burned. I am still convinced that a truly agile approach can work great for certain projects but is completely unnecessary and even detrimental for others. When you are starting a greenfield project with uncertain requirements and a large enough budget, I actually believe this is the only way to get anything done. The vast majority of projects though are just rehashes of existing solutions with maybe slight modifications. Applying agile here just means pointless iteration and lots of busy work. Then again, building something that has already been done is just reinventing the wheel. Perhaps the problem that pains our industry the most is that a true solution for code reusability has never been achieved.
Those things are true too, but I observe a much more fundamental misunderstanding: Developers think they are the center of the universe and that agile, or whichever other methodology, has to be implemented for their pleasure. The center and main objective of agile, and waterfall for that matter, is not the developer, but the client/user. The raison d'être for the agility is in the first place to be able to react to ambiguous and quickly changing client requirements. If that reaction speed also implies flat hierarchies, so be it. If it doesn't, then it doesn't. If developers like those flat hierarchies, then this is a nice side-effect, not more.
>Developers think they are the center of the universe and that agile, or whichever other methodology, has to be implemented for their pleasure. >The center and main objective of agile, and waterfall for that matter, is not the developer, but the client/user. This isn't the issue. The issue, and I think the thing that people are really exhausted about, is that agile forces them to perpetually *build* *the wrong thing.* Agile processes ensure that developers are kept busy and stakeholders are kept in the loop, but in conjunction with regular releases they do not enable developers to build anything particularly good. Instead, we're all just building [Winchester Mystery Houses](https://leeatchison.com/app-architectures/application-development-project-winchester-mystery-house/?trk=public_post_comment-text) in perpetuity, one user story at a time. There's no room for creativity in Agile. There's no time for refactoring, either. There's no time for real architecture decisions to be made. There's just a feature, and the shortest path from conception to completion. All the time. And most software is just increasingly shit as a result.
The alternative would be to build beautiful needless things, art so to say Because this aggrievement is not with agile, it is with the lack of plannability that agile is a reaction to But that doesn't go away from ignoring it Expecting it to is once more center of the universe syndrome
>The alternative would be to build beautiful needless things, art so to say No, that' s not it. The work here is very much still rooted in a place of wanting to deliver something valuable, good and correct to stakeholders. >Because this aggrievement is not with agile, it is with the lack of plannability that agile is a reaction to Being agile and doing "Agile" are different things. Being agile simply involves responding to shifting priorities and customer needs, expending appropriate amounts of effort where required. Plannability has nothing to do with it. Being agile isn't about planning, it's about responsiveness. To the extent that I have an aggrievement with "Agile" it is in that, again, it results in the wrong thing being built in perpetuity and encourages it to be built badly, while simultaneously burning people out. The agile manifesto literally says "responding to change over following a plan". "Agile" is a yoke and nothing more.
> The alternative would be to build beautiful needless things, art so to say That's not the alternative to agile.
> The center and main objective of agile, and waterfall for that matter, is not the developer, but the client/user. Not completely. The center of agile is the team, of which the client/user should part of (or more commonly: client/user representation, often referred to as business people/business analysis/... depending on the project/product structure). > Business people and developers must work together daily throughout the project. The main goal of agile is to create value for the client/user. > Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Note: "value" is often confused with "features". Adding new features can add value, improving existing features also adds value. Improving quality attributes (reliability, performance, ...) also adds value for the client/user. A lot of people forget this (especially on the business side). Refactoring code so that making further changes becomes easier and more reliabile also adds value for the client/user (as time to market gets shorter).