6 ms·

> about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. On a first pass, I thought this was a typo. I genuinely canno

> about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. On a first pass, I thought this was a typo. I genuinely cannot think of single scenario where discussion is even close to 50% percent of developer time, bar the exception of on-boarding and mentoring a recent graduate in the first month or so. Do you mean discussion among PMs?

TameAntelope 5y ago
Between discussing what to build next with your PM, discussing how to build the next thing with the experts on your team (architects, UX, devs), collaborating with other devs (pair and mob programming), figuring out how to improve the way you work as a team, not to mention the many other shared decisions a team makes, there's no way to jam all of that into anything less than 50% of your time. Honestly, I'd expect all of that to take up your entire work day, and really to do very little else (except overhead, like filling out timesheets or training), but I understand that people are so used to working alone, it's probably not actually possible to get folks to break those (bad) habits. Software development is done best as a team sport. I just don't see how anyone could do the prioritizations listed out in the Agile Manifesto without talking to one another, a lot: > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan [0] Every single one of these promotes communication ("talking to one another") and pushes aside "alone time". There's a reason for that. [0] https://agilemanifesto.org/ https://agilemanifesto.org/
- kungito 5y ago
  Half my company has this much talky talky time and its horrible for efficiency. I work on internal tooling so requirements are more clear, I spend 2-3 hours a week in meetings and I'm 3x more productive than them. My feeling is the biggest issue for the engineers spending time in meetings is that PMs are very bad at seeing technical challenges in what they are selling so there needs to be a lot of time wasted of more technical people helping them finalize the spec. In Micosoft PMs had a lot more technical background/former programmers so way less dev time was wasted in meetings
  - TameAntelope 5y ago
    I can imagine the time may seem wasted to a developer if your focus is on personal productivity (which seems to be the case since you cite your productivity rather than your team's productivity), but the lost value is in making sure what you're building is aligned with what your customers need. The fact that you're talking about "spec" here, in addition to your focus on individual productivity makes me wonder if what you're doing fits in with what's described in what I linked (the Agile Manifesto). Agile isn't for every team, and you can succeed despite not communicating, but there are risks and costs involved that, if made explicit, would not likely create costs you or your team would actually want to pay.
    - nicoburns 5y ago
      I totally agree that aligning with customer need is more than worth the time taken, but that shouldn't be taking 50% of developers time. More like 20% in my opinion. Internal collaboration between devs can take another large chunk of time, but that depends on how experienced (and how good) the developers are. I've worked on teams with all senior developers where the dev collaboration was mostly covered within that 20%, and minimal synchronisation was needed because we were all on the same page. I've also worked on teams with lots of junior developers, and that did require a lot more detailed planning and discussion that probably did take us close to 50% discussions overall. It was probably a necessary evil, but I wouldn't call it efficient, and it certainly isn't necessary in all cases.
- losteric 5y ago
  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)
- BlargMcLarg 5y ago
  This feels like a huge leap to justify "quantity of communication = quality of communication", while disregarding the effects it has on individuals, or the product. It also pushes people further into constant synchronous communication. >Every single one of these promotes communication It promotes adaptation. It doesn't specify whether it should take half your workday or just 30 minutes, that's for individuals to figure out and progressively adapt to.
  - TameAntelope 5y ago
    If you can't see how "interaction" and "collaboration" requires "communication", I probably can't help you.
    - BlargMcLarg 5y ago
      Fortunately I do not require your help. If you would instead highlight where exactly the manifesto requires a quantity of communication as large as half a day if not more, or prove that this is so valuable it warrants bypassing individual needs, I'm all ears.
      - TameAntelope 5y ago
        What, do you think, I meant when I wrote about "interactions" and "collaboration"? Am I quoting something or are those words I chose on my own?
BurningFrog 5y ago
If you're pair programming, you're discussing all day. Outside of that, yeah it's hard to imagine more than 10%, even for me.

TameAntelope 5y ago

Between discussing what to build next with your PM, discussing how to build the next thing with the experts on your team (architects, UX, devs), collaborating with other devs (pair and mob programming), figuring out how to improve the way you work as a team, not to mention the many other shared decisions a team makes, there's no way to jam all of that into anything less than 50% of your time. Honestly, I'd expect all of that to take up your entire work day, and really to do very little else (except overhead, like filling out timesheets or training), but I understand that people are so used to working alone, it's probably not actually possible to get folks to break those (bad) habits. Software development is done best as a team sport. I just don't see how anyone could do the prioritizations listed out in the Agile Manifesto without talking to one another, a lot: > Individuals and interactions over processes and tools > Working software over comprehensive documentation > Customer collaboration over contract negotiation > Responding to change over following a plan [0] Every single one of these promotes communication ("talking to one another") and pushes aside "alone time". There's a reason for that. [0] https://agilemanifesto.org/ https://agilemanifesto.org/

kungito 5y ago
Half my company has this much talky talky time and its horrible for efficiency. I work on internal tooling so requirements are more clear, I spend 2-3 hours a week in meetings and I'm 3x more productive than them. My feeling is the biggest issue for the engineers spending time in meetings is that PMs are very bad at seeing technical challenges in what they are selling so there needs to be a lot of time wasted of more technical people helping them finalize the spec. In Micosoft PMs had a lot more technical background/former programmers so way less dev time was wasted in meetings
- TameAntelope 5y ago
  I can imagine the time may seem wasted to a developer if your focus is on personal productivity (which seems to be the case since you cite your productivity rather than your team's productivity), but the lost value is in making sure what you're building is aligned with what your customers need. The fact that you're talking about "spec" here, in addition to your focus on individual productivity makes me wonder if what you're doing fits in with what's described in what I linked (the Agile Manifesto). Agile isn't for every team, and you can succeed despite not communicating, but there are risks and costs involved that, if made explicit, would not likely create costs you or your team would actually want to pay.
  - nicoburns 5y ago
    I totally agree that aligning with customer need is more than worth the time taken, but that shouldn't be taking 50% of developers time. More like 20% in my opinion. Internal collaboration between devs can take another large chunk of time, but that depends on how experienced (and how good) the developers are. I've worked on teams with all senior developers where the dev collaboration was mostly covered within that 20%, and minimal synchronisation was needed because we were all on the same page. I've also worked on teams with lots of junior developers, and that did require a lot more detailed planning and discussion that probably did take us close to 50% discussions overall. It was probably a necessary evil, but I wouldn't call it efficient, and it certainly isn't necessary in all cases.
losteric 5y ago
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)
BlargMcLarg 5y ago
This feels like a huge leap to justify "quantity of communication = quality of communication", while disregarding the effects it has on individuals, or the product. It also pushes people further into constant synchronous communication. >Every single one of these promotes communication It promotes adaptation. It doesn't specify whether it should take half your workday or just 30 minutes, that's for individuals to figure out and progressively adapt to.
- TameAntelope 5y ago
  If you can't see how "interaction" and "collaboration" requires "communication", I probably can't help you.
  - BlargMcLarg 5y ago
    Fortunately I do not require your help. If you would instead highlight where exactly the manifesto requires a quantity of communication as large as half a day if not more, or prove that this is so valuable it warrants bypassing individual needs, I'm all ears.
    - TameAntelope 5y ago
      What, do you think, I meant when I wrote about "interactions" and "collaboration"? Am I quoting something or are those words I chose on my own?

BurningFrog 5y ago

If you're pair programming, you're discussing all day. Outside of that, yeah it's hard to imagine more than 10%, even for me.