5 ms·

Obviously, it's a biased study that shouldn't be taken seriously, but while we're on the topic of Agile: Consulting Agile, grew out of web development consulti

Obviously, it's a biased study that shouldn't be taken seriously, but while we're on the topic of Agile: Consulting Agile, grew out of web development consulting firms as a defensive methodology for managing shitty stakeholders. They incorporated some genuine industry best practices, but they also have a lot there that's simply meant to blunt the worst impacts of having to deliver software in an environment where the person paying you doesn't understand the basics of software development (or project management really). It actually works pretty well in those environments - you don't get hyper-productive engineering teams, but you do get somewhat consistent delivery and a stable enough working environment that the worst outcomes (not delivering anything at all) are avoided. No large tech company that I'm aware of implements this type of Agile but plenty of big non-tech companies do. If you have a CIO in your company and the business refers to software engineers as 'IT' there's a good chance you do this. This is inefficient but it's probably good enough for those companies, especially if it's established, the switching costs alone would be a nightmare. If you're using it as a startup then something has gone terribly wrong and you should seriously reevaluate what you think the future of the company will be.

giantg2 2y ago
Yep, and the big companies basically use Agile as an excuse for not thoroughly planning and vetting ideas. Just build it and figure it out as you go. Then rebuild everything in 2 years since you're left with outdated and unmanageable spaghetti code and you burnt out all your SMEs so they took the knowledge with them.
- Pet_Ant 2y ago
  Do they ever rebuild things? Or just add features ontop of features till the whole thing creaks.
  - mrbombastic 2y ago
    generally they wait until something explodes or they cannot add any features to the unmaintainable mess and they have no choice :)
    - giantg2 2y ago
      Yep, this is what my experience is. It could be a cost explosion too, like using expensive mainframes and migrating to something else before the MIPS cost explodes.
      - Muromec 2y ago
        Did somebody successfully migrated from a mainframe? Asking for a friend.
        giantg2 2y ago
        Yes, I've heard of some systems successfully migrating from the mainframe at my company. It tends to be a painful process. There are still some apps that need to be migrated.
  - dopylitty 2y ago
    Several years after a project completes when the system is finally sort of working and the end users know what to expect new management will come in at a high enough level and demand everything be rebuilt using their tech stack of choice because they need the resume entries. Then of course you'll get a buggy second system that is back at square 0 which the business doesn't understand/hates and the developers hate because they're constantly fighting fires.
- happymellon 2y ago
  You make it sound like Waterfall had full plans and completely vetted ideas. It didn't. > Just build it and figure it out as you go. That sounds like hundreds of waterfall projects that I was pulled into after they hit the 1/2 way mark and we're running behind because of unexpected scenarios.
  - giantg2 2y ago
    It had better plans than the way Agile has been done on the teams I've been on. You can certainly misuse either. In my experience, planning is neglected more Agile.
- SillyUsername 2y ago
  Waterfall and spiral model failed in the general case for the reason of plan everything in advance, so unless it's a safety critical system I'd say Agile is still better. I say this because no matter what methodology is used there will be spaghetti code regardless, mid tier devs like to over engineer solutions, junior devs don't know better and do whatever is first on stackoverflow. Business execs also don't ever know what they want so change a system half way through when they see prototypes so then you still end up with Franken-systems. To that end, you might as well start with a half spec'd system as it saves time.
bityard 2y ago
I have observed that there are two kinds of Agile. "Agile in doctrine" is the kind all of the anti-Agile crowd rail against because they've been burnt by working for some company or manager who drank the Koolaid without actually understanding what Agile is. Blindly following some consultant's Agile playbook is not Agile. "Agile in spirit" is a bit like The Zen of Python: X is usually better than Y but there are times where it makes complete sense to do Y. In order for Agile to work, you need to have leaders and CIs who understand that. Agile emphasizes communication and flexibility. Agile is advisory, not prescriptive.
- JackFr 2y ago
  I largely agree with you, but when it comes to evaluating competing methodologies, what you refer to as “agile in spirit” turns quickly into No True Scotsman. “If you project failed you mustn’t have been doing agile correctly.”
  - quacked 2y ago
    To me the single most common evidence of failure to perform "Agile in spirit" is management holding specific teams responsible for missing a deadline after a feature or due date was changed. It shows that the management doesn't understand software development. If you think you can add features or move delivery dates to the left without consequences, you've misjudged your entire industry.
    - codr7 2y ago
      Yeah, my former wannabe-boss was very surprised to realize that splitting the company in two and selling one part during my onboarding period might have a negative effect on my productivity. We're not doing a very good job of picking the right people to manage things; quite the opposite, in many cases whatever success is despite the leadercrap we have to deal with.
  - jerf 2y ago
    There is some virtue to your criticism, but it is also not entirely true. There are things you can check to see if a team is doing Agile for real, like, what's the last process change you experimented with to see if it improved your outcomes? What experiment failed and was dispassionately removed from the process because it didn't work out? When your team's workload nature changed (e.g., from new development to maintenance), how did you adapt your processes to match? Do your processes come up from the team and their experience or do they source from above with effectively no feedback? At that point, if you are doing those things, there is a certain amount of validity to the criticism that if it didn't work, you really weren't doing it right. Either something external jammed you up so you weren't able to adapt and truly follow agile, your team was personally unable to execute on the adaptation for some reason (structure, personality issues, experience levels, being simply too large to be able to be this flexible because large teams simply need more structure), or the task was simply too hard in the first place for some reason (such as "it doesn't matter how agile and smart the team is, you're not getting 4 people to produce a standards-compliant browser that is also an office suite in six months").
ano-ther 2y ago
Good observation. Having been on the “customer” side in such companies, I’d say the improvement is the result of more frequent interaction which improves mutual understanding. The internal customers are forced to think through requirements in detail (albeit in pieces). The developers are forced to explain what they are doing. Too many projects I’ve seen suffered from a lack of communication. Customers would hand things off (“just build x”, lots of customization requests that aren’t thought through). Developers would start guessing and working in the wrong direction, often going on complicated tangents as a result of the customizations). Consulting Agile as you call it really helps both sides to understand what’s actually needed and how to get there.
tinco 2y ago
It's not just a biased study, it's an article about a study of which the data is not published, so it's impossible to tell if there's any merit to it. The excerpts of the study published in the article do not inspire confidence either: 1. Agile ("Agile Requirements Engineering") is defined as: Development starts before clear requirements, no complete specification, significant changes late in development. I think even those who are opposed to Agile would agree that's a severely lacking if not completely incorrect characterisation of Agile development practices. It sounds more like a list of things that would cause an Agile project to fail. 2. Impact Engineering is defined as: Use of all engineering practices studied which increase success rates. Why doesn't the author dare to give any properties of Impact Engineering up front? This sounds like he's just baiting for people to buy the book so they could learn what magical engineering practices are studied therein. It smells scammy.

giantg2 2y ago

Yep, and the big companies basically use Agile as an excuse for not thoroughly planning and vetting ideas. Just build it and figure it out as you go. Then rebuild everything in 2 years since you're left with outdated and unmanageable spaghetti code and you burnt out all your SMEs so they took the knowledge with them.

Pet_Ant 2y ago
Do they ever rebuild things? Or just add features ontop of features till the whole thing creaks.
- mrbombastic 2y ago
  generally they wait until something explodes or they cannot add any features to the unmaintainable mess and they have no choice :)
  - giantg2 2y ago
    Yep, this is what my experience is. It could be a cost explosion too, like using expensive mainframes and migrating to something else before the MIPS cost explodes.
    - Muromec 2y ago
      Did somebody successfully migrated from a mainframe? Asking for a friend.
      - giantg2 2y ago
        Yes, I've heard of some systems successfully migrating from the mainframe at my company. It tends to be a painful process. There are still some apps that need to be migrated.
- dopylitty 2y ago
  Several years after a project completes when the system is finally sort of working and the end users know what to expect new management will come in at a high enough level and demand everything be rebuilt using their tech stack of choice because they need the resume entries. Then of course you'll get a buggy second system that is back at square 0 which the business doesn't understand/hates and the developers hate because they're constantly fighting fires.
happymellon 2y ago
You make it sound like Waterfall had full plans and completely vetted ideas. It didn't. > Just build it and figure it out as you go. That sounds like hundreds of waterfall projects that I was pulled into after they hit the 1/2 way mark and we're running behind because of unexpected scenarios.
- giantg2 2y ago
  It had better plans than the way Agile has been done on the teams I've been on. You can certainly misuse either. In my experience, planning is neglected more Agile.
SillyUsername 2y ago
Waterfall and spiral model failed in the general case for the reason of plan everything in advance, so unless it's a safety critical system I'd say Agile is still better. I say this because no matter what methodology is used there will be spaghetti code regardless, mid tier devs like to over engineer solutions, junior devs don't know better and do whatever is first on stackoverflow. Business execs also don't ever know what they want so change a system half way through when they see prototypes so then you still end up with Franken-systems. To that end, you might as well start with a half spec'd system as it saves time.

bityard 2y ago

I have observed that there are two kinds of Agile. "Agile in doctrine" is the kind all of the anti-Agile crowd rail against because they've been burnt by working for some company or manager who drank the Koolaid without actually understanding what Agile is. Blindly following some consultant's Agile playbook is not Agile. "Agile in spirit" is a bit like The Zen of Python: X is usually better than Y but there are times where it makes complete sense to do Y. In order for Agile to work, you need to have leaders and CIs who understand that. Agile emphasizes communication and flexibility. Agile is advisory, not prescriptive.

JackFr 2y ago
I largely agree with you, but when it comes to evaluating competing methodologies, what you refer to as “agile in spirit” turns quickly into No True Scotsman. “If you project failed you mustn’t have been doing agile correctly.”
- quacked 2y ago
  To me the single most common evidence of failure to perform "Agile in spirit" is management holding specific teams responsible for missing a deadline after a feature or due date was changed. It shows that the management doesn't understand software development. If you think you can add features or move delivery dates to the left without consequences, you've misjudged your entire industry.
  - codr7 2y ago
    Yeah, my former wannabe-boss was very surprised to realize that splitting the company in two and selling one part during my onboarding period might have a negative effect on my productivity. We're not doing a very good job of picking the right people to manage things; quite the opposite, in many cases whatever success is despite the leadercrap we have to deal with.
- jerf 2y ago
  There is some virtue to your criticism, but it is also not entirely true. There are things you can check to see if a team is doing Agile for real, like, what's the last process change you experimented with to see if it improved your outcomes? What experiment failed and was dispassionately removed from the process because it didn't work out? When your team's workload nature changed (e.g., from new development to maintenance), how did you adapt your processes to match? Do your processes come up from the team and their experience or do they source from above with effectively no feedback? At that point, if you are doing those things, there is a certain amount of validity to the criticism that if it didn't work, you really weren't doing it right. Either something external jammed you up so you weren't able to adapt and truly follow agile, your team was personally unable to execute on the adaptation for some reason (structure, personality issues, experience levels, being simply too large to be able to be this flexible because large teams simply need more structure), or the task was simply too hard in the first place for some reason (such as "it doesn't matter how agile and smart the team is, you're not getting 4 people to produce a standards-compliant browser that is also an office suite in six months").

ano-ther 2y ago

Good observation. Having been on the “customer” side in such companies, I’d say the improvement is the result of more frequent interaction which improves mutual understanding. The internal customers are forced to think through requirements in detail (albeit in pieces). The developers are forced to explain what they are doing. Too many projects I’ve seen suffered from a lack of communication. Customers would hand things off (“just build x”, lots of customization requests that aren’t thought through). Developers would start guessing and working in the wrong direction, often going on complicated tangents as a result of the customizations). Consulting Agile as you call it really helps both sides to understand what’s actually needed and how to get there.

tinco 2y ago

It's not just a biased study, it's an article about a study of which the data is not published, so it's impossible to tell if there's any merit to it. The excerpts of the study published in the article do not inspire confidence either: 1. Agile ("Agile Requirements Engineering") is defined as: Development starts before clear requirements, no complete specification, significant changes late in development. I think even those who are opposed to Agile would agree that's a severely lacking if not completely incorrect characterisation of Agile development practices. It sounds more like a list of things that would cause an Agile project to fail. 2. Impact Engineering is defined as: Use of all engineering practices studied which increase success rates. Why doesn't the author dare to give any properties of Impact Engineering up front? This sounds like he's just baiting for people to buy the book so they could learn what magical engineering practices are studied therein. It smells scammy.