4 ms·

What you're describing sounds much closer to my experience on a waterfall development cycle. Huge commitments without any dev-input, leading to the dev team con

What you're describing sounds much closer to my experience on a waterfall development cycle. Huge commitments without any dev-input, leading to the dev team constantly churning around knowledge silos or poor tooling setup. My experience on agile was very different. Senior tech folks would, yes, spend up to and even more than 50% of their day in cross-team group discussions... but the junior ICs would typically spend 90%+ focusing on implementing tasks, except for the weekly sprint planning meeting. The Agile process we had was one were stories were well-defined prior to implementation - supplemented by great documentation and test coverage. A genuine new hire would typically be able to pick up and implement small stories with zero communication overhead in their first 2 weeks. I see this as ultimate goal of an agile process - clean spec's upfront, unambiguous implementation, acceptance of potential second iterations instead of monolithic group decision making. On that team, product had an agile process in advance of the dev sprints which built mocks and got sign-offs for implementation (I've also been on teams where design+implementation fell under the same story). Even algorithmic or systems heavy work was still at least 60% independent work, with occasional meetings throughout the day to pass ideas by or brainstorm new areas of research.

TameAntelope 5y ago
I'm not sure I know how to square "Working software over comprehensive documentation" with "well defined stories with great documentation" and "clean specs upfront". Those sounds incompatible, I'd even go so far as to say. Imagine throwing out every process you just described (minimal specs and plans, no contracts, no documentation, avoiding as many processes and tools as possible), and instead replacing them with conversations. You'd have those conversations (dev to dev, dev to PM, PM to customer, dev to customer), spend a few days building software, and then have those conversations all over again, continuously looping until the product is either "done" or something more important came up to work on. Would you call that team "agile" or "waterfall"?
- losteric 5y ago
  > Imagine throwing out every process you just described (minimal specs and plans, no contracts, no documentation, avoiding as many processes and tools as possible), and instead replacing them with conversations. You'd have those conversations (dev to dev, dev to PM, PM to customer, dev to customer), spend a few days building software, and then have those conversations all over again, continuously looping until the product is either "done" or something more important came up to work on. > Would you call that team "agile" or "waterfall"? Waterfall, 100%. I've been through that hell - management comes down with a date and brief elevator pitch. Then we're in constant talks over the next two weeks to hit a date no one really understands the requirements or rationales of, ironing out responsibilities between teams without any holistic long-term architectural vision (because there isn't even a product vision). > I'm not sure I know how to square "Working software over comprehensive documentation" with "well defined stories with great documentation" and "clean specs upfront". Comprehensive documentation literally means a very high coverage, perhaps 100% coverage of architecture docs, tutorials, design specs, etc. I said "well defined" and "great" :) Agile is not contrary to documentation. Instead, there is a recognition that documentation's value is the time saved on development/discussion. That balance point depends on the team, and should always be considered in retrospectives. If you're a team of 3 that all know how everything works, without immediate growth prospects... yeah, who needs docs? On the other hand, a FAANG team of 12 growing to 30 over the next 3 months will need documentation. My "right-level" of documentation is that a junior engineer can pick up a story and ship it alone. The story is not fully-defined - implementer will have to learn some things from the docs, read through some of the code, decide on implementation strategy themselves... but they should be able to do so without meeting with others. Meetings are expensive for teams, and context switching is expensive for ICs. Meetings that require bringing in senior engineers[1] for story-level details is all but an organizational anti-pattern. [1] Generally, I'd regard having any single SME in the critical path of implementation is an antipattern (borrowing from kanban, this person invariably becomes a bottleneck on a large fast-paced team)
  - TameAntelope 5y ago
    So you understand that you're taking a literal primary tenet of agile and calling it "waterfall", yeah? "Working software over comprehensive documentation" is one of only 4 values of the Agile Manifesto, and it's in direct conflict with what you're calling Agile.
    - losteric 5y ago
      I feel like you're spouting Agile (TM) rather than https://en.wikipedia.org/wiki/Agile_software_development https://en.wikipedia.org/wiki/Agile_software_development - Agile is not one thing, it's certainly not a checklist. There are general philosophies of software development. The core is really adaptive planning and acceptance/flexibility to uncertainty, biasing towards shipping first. There is no requirement to be spending all day in endless meetings, nor an opposition to documentation. If more documentation increases velocity, why would that be anti-agile? More importantly, what works for you does not discredit another team's agile approach. I lead large and growing teams rapidly releasing greenfield software. We are definitively agile, and documentation is empirically key to that process. Perhaps your experience differs. I don't discredit that, merely provide my experience in contrast.
      - TameAntelope 5y ago
        Hm, what is your opinion of the Agile Manifesto?
      - salawat 5y ago
        I'll second the concerns at touting FrAgile (TM). Too many teams woefully underestimate the level of work yhat goes into maintaining the full delivery of product, and the fact that as you scale up, process has to be in place to keep people working independently without running into issues. Waterfall's issue was that it stipulated there shalt be process from stage 1 before anyone even understands WTF anyone is doing. FrAgile(TM) is notorious for just cutting people loose and winging it, with no regard to system design, architecture and maintaining a cohesive whole over the entire process that keeps your business functioning. You can't just NOT make SOP's you can't have an onboarding process that can't ne negotiated by the average person. Doing so is a recipe for burnout/churnout and failure.
- dijit 5y ago
  I believe that’s the definition of agile (as defined in the agile manifesto) but what is practiced as “Agile” is actually a weird waterfall pattern.
  - rzzzt 5y ago
    Behold: http://www.halfarsedagilemanifesto.org/ http://www.halfarsedagilemanifesto.org/

TameAntelope 5y ago

I'm not sure I know how to square "Working software over comprehensive documentation" with "well defined stories with great documentation" and "clean specs upfront". Those sounds incompatible, I'd even go so far as to say. Imagine throwing out every process you just described (minimal specs and plans, no contracts, no documentation, avoiding as many processes and tools as possible), and instead replacing them with conversations. You'd have those conversations (dev to dev, dev to PM, PM to customer, dev to customer), spend a few days building software, and then have those conversations all over again, continuously looping until the product is either "done" or something more important came up to work on. Would you call that team "agile" or "waterfall"?

losteric 5y ago
> Imagine throwing out every process you just described (minimal specs and plans, no contracts, no documentation, avoiding as many processes and tools as possible), and instead replacing them with conversations. You'd have those conversations (dev to dev, dev to PM, PM to customer, dev to customer), spend a few days building software, and then have those conversations all over again, continuously looping until the product is either "done" or something more important came up to work on. > Would you call that team "agile" or "waterfall"? Waterfall, 100%. I've been through that hell - management comes down with a date and brief elevator pitch. Then we're in constant talks over the next two weeks to hit a date no one really understands the requirements or rationales of, ironing out responsibilities between teams without any holistic long-term architectural vision (because there isn't even a product vision). > I'm not sure I know how to square "Working software over comprehensive documentation" with "well defined stories with great documentation" and "clean specs upfront". Comprehensive documentation literally means a very high coverage, perhaps 100% coverage of architecture docs, tutorials, design specs, etc. I said "well defined" and "great" :) Agile is not contrary to documentation. Instead, there is a recognition that documentation's value is the time saved on development/discussion. That balance point depends on the team, and should always be considered in retrospectives. If you're a team of 3 that all know how everything works, without immediate growth prospects... yeah, who needs docs? On the other hand, a FAANG team of 12 growing to 30 over the next 3 months will need documentation. My "right-level" of documentation is that a junior engineer can pick up a story and ship it alone. The story is not fully-defined - implementer will have to learn some things from the docs, read through some of the code, decide on implementation strategy themselves... but they should be able to do so without meeting with others. Meetings are expensive for teams, and context switching is expensive for ICs. Meetings that require bringing in senior engineers[1] for story-level details is all but an organizational anti-pattern. [1] Generally, I'd regard having any single SME in the critical path of implementation is an antipattern (borrowing from kanban, this person invariably becomes a bottleneck on a large fast-paced team)
- TameAntelope 5y ago
  So you understand that you're taking a literal primary tenet of agile and calling it "waterfall", yeah? "Working software over comprehensive documentation" is one of only 4 values of the Agile Manifesto, and it's in direct conflict with what you're calling Agile.
  - losteric 5y ago
    I feel like you're spouting Agile (TM) rather than https://en.wikipedia.org/wiki/Agile_software_development https://en.wikipedia.org/wiki/Agile_software_development - Agile is not one thing, it's certainly not a checklist. There are general philosophies of software development. The core is really adaptive planning and acceptance/flexibility to uncertainty, biasing towards shipping first. There is no requirement to be spending all day in endless meetings, nor an opposition to documentation. If more documentation increases velocity, why would that be anti-agile? More importantly, what works for you does not discredit another team's agile approach. I lead large and growing teams rapidly releasing greenfield software. We are definitively agile, and documentation is empirically key to that process. Perhaps your experience differs. I don't discredit that, merely provide my experience in contrast.
    - TameAntelope 5y ago
      Hm, what is your opinion of the Agile Manifesto?
    - salawat 5y ago
      I'll second the concerns at touting FrAgile (TM). Too many teams woefully underestimate the level of work yhat goes into maintaining the full delivery of product, and the fact that as you scale up, process has to be in place to keep people working independently without running into issues. Waterfall's issue was that it stipulated there shalt be process from stage 1 before anyone even understands WTF anyone is doing. FrAgile(TM) is notorious for just cutting people loose and winging it, with no regard to system design, architecture and maintaining a cohesive whole over the entire process that keeps your business functioning. You can't just NOT make SOP's you can't have an onboarding process that can't ne negotiated by the average person. Doing so is a recipe for burnout/churnout and failure.
dijit 5y ago
I believe that’s the definition of agile (as defined in the agile manifesto) but what is practiced as “Agile” is actually a weird waterfall pattern.
- rzzzt 5y ago
  Behold: http://www.halfarsedagilemanifesto.org/ http://www.halfarsedagilemanifesto.org/