8 ms·

I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when appl

I've come to dread any formalization of Agile. Agile development is fine. I've built a 40+ engineering team with it. I can vouch for its effectiveness when applied to small, excellent teams. For reference, here's all the Agile you need, it's 4 sentences: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan The real problem is that capital-A Agile is not agile at all, but exactly the opposite: A fat process that enforces following a plan (regular, rigid meeting structure), creating comprehensive documentation (user stories, specs, mocks, task board) and contract negotiation (estimation meetings, planning poker). It's a bastardization of the original idea, born by process first people who tried to copy the methods of successful teams without understanding them.

operatingthetan 5mo ago
I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.
- prerok 5mo ago
  I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.
  - steinsgatezero 5mo ago
    Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
    - ryandrake 5mo ago
      A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.
- t43562 5mo ago
  Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th." "Oh, feature no 32 is going to take months and we realised that users can just...." "No"
  - magicalhippo 5mo ago
    > "You're going to do agile .... and this list of features will be ready on September 20th." Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then. We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.
    - ezekiel68 5mo ago
      It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"
      - operatingthetan 5mo ago
        In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.
        magicalhippo 5mo ago
        That's an important point. It may be a hard cut-off when the switch happens, but the date for the switch may be malleable. This is crucial to get surfaced early, along with how painful it is to actually move said date if possible.
      - magicalhippo 5mo ago
        Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work. If the org focuses on the customers one can work together to find a way.
- codeduck 5mo ago
  Ah yes, the old Agile-as-drunken-waterfall pattern
- mpweiher 5mo ago
  In most of the industry "Agile" is just "doing waterfall really quickly", and for some reason nobody understands you have to stand during your daily micromanagement meetings. It's a farce.
Cwizard 5mo ago
Yes, exactly. It works great. But it is not cookie cutter enough for most orgs to adopt which is what led to Scrum, SAFE and what else. And then organisations take those frameworks (often change them to get even more agility out) and adopt them like it is gospel. I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea?? Not sure what the solution is. There might not be any.
9dev 5mo ago
> […] when applied to small, excellent teams. Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated. That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more the alignment and median expertise lessen. At some point, you need to introduce control mechanisms and additional communication tools to rake in the outliers. I don't really have a better answer, though…
- Cthulhu_ 5mo ago
  That's it, "excellent teams" are a needle in a haystack; the mythical 10x developer, if you will. But at one point you need not one team, but a hundred.
- Balinares 5mo ago
  I've had good success in both high-skill teams (in one case, almost half the team's engineers ended up at Google at some point or other) and... teams that were still in the process of skilling up. I've found people generally want to do good things and have some room to grow even if they're not yet at your desired level; and when you have demotivated people around, the causes tend to be systemic. Which, thankfully, implies possibly fixable.
- mpweiher 5mo ago
  > this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated. Counterpoint: I learned a variant of agile in exactly this type of environment, long before any of this was publicized. Which is another point: agile wasn't something new, certainly not at the time of the manifesto, which was a compromise document. But not even before the manifesto. XP, arguably the first agile methodology, very clearly and deliberately stated that this is nothing new, just a distillation of things that experience has shown to work well. Anyway, at my next job I introduced agile (small-a-agile) to a team that was anything but skilled. In fact, that team was where the leftovers of that particular development organization had been shunted (public company, very difficult to get rid of people). When I arrived, the team was as non-functional as the software it was responsible for. Well... We rocked. And all the team member improved dramatically in skill during my tenure there. Including myself. We did not do Agile. No scrum, no standups, no sprints, none of that BS. We were agile. We focused on the technical practices. Test first. Red-green-commit. To trunk, obviously. Because if it's green why on earth would you not? Do the simplest thing that could possibly work. We had a design for a database and then never found a need to put it in...so we didn't. It took a while for the other parts of the org to adapt to this. The answer to the common question "well, when can you deploy?" was always "now". Well after a quick look that the tests were, in fact, green. So they stopped asking. The tests were rarely not green, and when it did happened there was usually a quick "Oops, I'm sorry" and they went green again a couple of minutes later. Our ops team got bored very quickly. Put jar on box. Start. Forget about it. What made the experience scientifically interesting is that we had a control group: the main team, much larger, working on the "important" software with all the "good" engineers started with a new project about the same time we did. They did Agile. Capital-A. Scrum, sprints, standups. They did not deliver and in fact the project had to be completely reset about two years in. My team-lead (we were co-lead, I did mostly internal/technical, he external/managerial) then got to take over that team as I left for Apple. TFA, incidentally, is just about as good summary of misunderstandings of agile as I've seen.
globular-toast 5mo ago
I never really got the "Individuals and interactions over processes and tools" one. What processes and tools is it talking about? Surely it's not saying I should talk to a colleague to track a change rather than use version control? I feel like I'm missing some context of what "tools and processes" it is talking about. The others I get, but only after having already spent years in software. I guess like many things you have to see the other way before you can appreciate the better way.
- 59nadir 5mo ago
  One example of this would be that it's better to go over to your buddy in QA to talk about the feature you just pushed instead of jumping into Jira and activating your overwrought, weirdly scripted kanban flow that requires 3 asynchronous steps to be taken for it to actually be picked up by anyone who can finally give a damn.
- mytailorisrich 5mo ago
  It is the usual and old advice that instead of, for instance, doing back and forth over emails, Jira, whatever it is more effective to just go discuss with the relevant person directly.
yc-kraln 5mo ago
> Working software over comprehensive documentation this is 100% backwards for anything safety-critical or that needs to be maintained past a butterfly's lifetime. this is what encourages yolo-driven-development instead of considering what actually should be done, and this is why agile or Agile or whatever formalization or bastardization of it can not be considered software engineering, but merely code monkeying.
- qwertytyyuu 5mo ago
  If it’s good enough for a space program it’s good enough for pretty much anything
- phba 5mo ago
  Yeah, I don't understand why it has to be agile XOR waterfall. Agile development simply doesn't work in projects that have so many externally imposed constraints that there is barely any flexibility left.
Cthulhu_ 5mo ago
Yeah we work agile, just look at this diagram, it's super agile. https://framework.scaledagile.com/safe-6-0-configurations/ https://framework.scaledagile.com/safe-6-0-configurations/ It's got loops and infinity markers, AND iconography representing humans!
- ryandrake 5mo ago
  I almost threw up looking at that. Please mark things like that NSFW!

operatingthetan 5mo ago

I can't count how many times I've seen "agile" projects that were just actually waterfall due to demands from stakeholders.

prerok 5mo ago
I've seen that too, though I have to say that none of those were as waterfally as the actual waterfall process we used to follow. Back then it was quite literally 0 lines of code until spec (100s of pages) is complete.
- steinsgatezero 5mo ago
  Which ironically makes Agile even worse at times by forcing developers to implement incomplete spec, parts of which are often rewritten over and over again everytime the PM talks to the client.
  - ryandrake 5mo ago
    A lot of managers confuse "Agile" with fast and think that "agile" teams are going to deliver software faster. In reality, it's often slower than waterfall. If you have a single feature that's never going to change, and you absolutely positively need it by Date X, then you're probably better off with waterfall.
t43562 5mo ago
Absolutely! "You're going to do agile .... and this list of features will be ready on September 20th." "Oh, feature no 32 is going to take months and we realised that users can just...." "No"
- magicalhippo 5mo ago
  > "You're going to do agile .... and this list of features will be ready on September 20th." Well often the real world forces it upon you. As in customer will switch invoicing system on September 20th, integrations have to be ready by then. We have a lot of this, and hard cut-off is very frequent. If we ain't got all those deliverables implemented by then we will lose customers.
  - ezekiel68 5mo ago
    It is difficult to explain to a division director that they do not have sufficeint capacity (enough qualified programmers) to compete features within a set time budget. The old joke goes, "It takes one woman nine months to produce a baby. But: what if we just put nine women in a room for one month!?"
    - operatingthetan 5mo ago
      In my professional consulting experience I've found most of those purported "hard deadlines" as mentioned above were usually arbitrarily defined, in other words: completely made up.
      - magicalhippo 5mo ago
        That's an important point. It may be a hard cut-off when the switch happens, but the date for the switch may be malleable. This is crucial to get surfaced early, along with how painful it is to actually move said date if possible.
    - magicalhippo 5mo ago
      Yeah that never gets old. But it may be some features can be delivered in stages, maybe some can be solved other ways than intended that require less work. If the org focuses on the customers one can work together to find a way.
codeduck 5mo ago
Ah yes, the old Agile-as-drunken-waterfall pattern
mpweiher 5mo ago
In most of the industry "Agile" is just "doing waterfall really quickly", and for some reason nobody understands you have to stand during your daily micromanagement meetings. It's a farce.

Cwizard 5mo ago

Yes, exactly. It works great. But it is not cookie cutter enough for most orgs to adopt which is what led to Scrum, SAFE and what else. And then organisations take those frameworks (often change them to get even more agility out) and adopt them like it is gospel. I have worked at an org where team members were not allowed to create tickets because that was the scrum master's job and the product owner had to approve all tickets etc. Who can even think that is a good idea?? Not sure what the solution is. There might not be any.

9dev 5mo ago

> […] when applied to small, excellent teams. Isn't that the biggest issue here, though? I think all of us can agree on the four sentences you wrote, but this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated. That is the case for a small founder team and maybe a while after that if you're lucky, but IME the more people join a company, the more the alignment and median expertise lessen. At some point, you need to introduce control mechanisms and additional communication tools to rake in the outliers. I don't really have a better answer, though…

Cthulhu_ 5mo ago
That's it, "excellent teams" are a needle in a haystack; the mythical 10x developer, if you will. But at one point you need not one team, but a hundred.
Balinares 5mo ago
I've had good success in both high-skill teams (in one case, almost half the team's engineers ended up at Google at some point or other) and... teams that were still in the process of skilling up. I've found people generally want to do good things and have some room to grow even if they're not yet at your desired level; and when you have demotivated people around, the causes tend to be systemic. Which, thankfully, implies possibly fixable.
mpweiher 5mo ago
> this only works in a team of professionals with shared goals (and alignment on them!), each individually competent and motivated. Counterpoint: I learned a variant of agile in exactly this type of environment, long before any of this was publicized. Which is another point: agile wasn't something new, certainly not at the time of the manifesto, which was a compromise document. But not even before the manifesto. XP, arguably the first agile methodology, very clearly and deliberately stated that this is nothing new, just a distillation of things that experience has shown to work well. Anyway, at my next job I introduced agile (small-a-agile) to a team that was anything but skilled. In fact, that team was where the leftovers of that particular development organization had been shunted (public company, very difficult to get rid of people). When I arrived, the team was as non-functional as the software it was responsible for. Well... We rocked. And all the team member improved dramatically in skill during my tenure there. Including myself. We did not do Agile. No scrum, no standups, no sprints, none of that BS. We were agile. We focused on the technical practices. Test first. Red-green-commit. To trunk, obviously. Because if it's green why on earth would you not? Do the simplest thing that could possibly work. We had a design for a database and then never found a need to put it in...so we didn't. It took a while for the other parts of the org to adapt to this. The answer to the common question "well, when can you deploy?" was always "now". Well after a quick look that the tests were, in fact, green. So they stopped asking. The tests were rarely not green, and when it did happened there was usually a quick "Oops, I'm sorry" and they went green again a couple of minutes later. Our ops team got bored very quickly. Put jar on box. Start. Forget about it. What made the experience scientifically interesting is that we had a control group: the main team, much larger, working on the "important" software with all the "good" engineers started with a new project about the same time we did. They did Agile. Capital-A. Scrum, sprints, standups. They did not deliver and in fact the project had to be completely reset about two years in. My team-lead (we were co-lead, I did mostly internal/technical, he external/managerial) then got to take over that team as I left for Apple. TFA, incidentally, is just about as good summary of misunderstandings of agile as I've seen.

globular-toast 5mo ago

I never really got the "Individuals and interactions over processes and tools" one. What processes and tools is it talking about? Surely it's not saying I should talk to a colleague to track a change rather than use version control? I feel like I'm missing some context of what "tools and processes" it is talking about. The others I get, but only after having already spent years in software. I guess like many things you have to see the other way before you can appreciate the better way.

59nadir 5mo ago
One example of this would be that it's better to go over to your buddy in QA to talk about the feature you just pushed instead of jumping into Jira and activating your overwrought, weirdly scripted kanban flow that requires 3 asynchronous steps to be taken for it to actually be picked up by anyone who can finally give a damn.
mytailorisrich 5mo ago
It is the usual and old advice that instead of, for instance, doing back and forth over emails, Jira, whatever it is more effective to just go discuss with the relevant person directly.

yc-kraln 5mo ago

> Working software over comprehensive documentation this is 100% backwards for anything safety-critical or that needs to be maintained past a butterfly's lifetime. this is what encourages yolo-driven-development instead of considering what actually should be done, and this is why agile or Agile or whatever formalization or bastardization of it can not be considered software engineering, but merely code monkeying.

qwertytyyuu 5mo ago
If it’s good enough for a space program it’s good enough for pretty much anything
phba 5mo ago
Yeah, I don't understand why it has to be agile XOR waterfall. Agile development simply doesn't work in projects that have so many externally imposed constraints that there is barely any flexibility left.

Cthulhu_ 5mo ago

Yeah we work agile, just look at this diagram, it's super agile. https://framework.scaledagile.com/safe-6-0-configurations/ https://framework.scaledagile.com/safe-6-0-configurations/ It's got loops and infinity markers, AND iconography representing humans!

ryandrake 5mo ago
I almost threw up looking at that. Please mark things like that NSFW!