6 ms·

I almost agree with all of this, with the caveat of "leave developers alone". A well functioning Agile team is talking to one another (within the team) about 5

I almost agree with all of this, with the caveat of "leave developers alone". A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. If you're on the development team (and you should be), you should not think of yourself as "bothering" the other members of the team when you need to discuss something with them. Doors should be open, and lost coding productivity gets made up for by making extremely sure the code that does get written is the right code. I know it's super popular to think of alone time for developers as sacred, but it leads to worse outcomes. Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are used to being treated a certain way will tolerate. If you're not on the development team, fine. Leave the development team alone. But a team who doesn't have a person dedicated to figuring out what to work on next (often called the "PM"), is not going to be autonomous, and will suffer as a result.

ianbutler 5y ago
> Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are. Heavy disagree, there is deep work that requires working a lone. Anything actually technically complex requires both enormous communication AND execution time. Ive worked in companies with pairing all the time and solo execution. By far solo execution of different parts with communal design and heavy communication produced the best outcomes.
Clubber 5y ago
>A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. I've never been on a team where developers talk 50% of the time. We have a meeting to prioritize tickets once a week and talk to other devs when necessary. If I worked at a company where devs were poking me 50% of my day, I'd leave screaming.
- brimble 5y ago
  > I've never been on a team where developers talk 50% of the time. We have a meeting to prioritize tickets once a week and talk to other devs when necessary. Shit, I have—but if you count only productive hours, it's more like 10-20% are talking :-)
btown 5y ago
It's also strange that this is written as if there's no option other than "have a meeting" or "save it until tomorrow." That's what Slack is for! Start a thread, notify the right folks, but also ensure you share context about time urgency e.g. "I'd like to respond to $stakeholder today" or "Can you share thoughts sometime before standup tomorrow?" - and importantly, especially for engineers who might take things literally, make sure you share whether or not any coding action (EDIT: including digging into existing code) is requested as part of that effort. Engineers also appreciate that their opinions are valued. Be a buffer so they don't feel like they're getting the full force of the stakeholder, but package the requests in realtime, and build a rapport so that you'll know if you're over-asking!
mkl95 5y ago
> I almost agree with all of this, with the caveat of "leave developers alone". > A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. I have been part of several Agile teams, starting as a junior engineer at a small startup, and eventually becoming a tech lead at a wannabe unicorn. There's something common to all those places, and it's that spending a significant amount of time discussing things is just not possible. Spending 50% of your time discussing stuff will put a target on your back. The pressure to deliver moderate to unrealistic amounts of work is always there. In that sense, POs and BAs never leave developers alone. Most of their time is spent making product's kitsch dreams come true.
DoingIsLearning 5y ago
> 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
gashmol 5y ago
50% of the time talking sounds like a nightmare. I don't think you can build anything nontrivial if you get interrupted all the time.
- TameAntelope 5y ago
  I would argue that the only way to build something meaningful to someone other than you is to talk about it approximately half of the time you work on it.
  - stitched2gethr 5y ago
    I believe many highly successful products would contradict this claim.
  - zeroonetwothree 5y ago
    Well you would be wrong. I’ve built many such things spending far less time discussing them.
908B64B197 5y ago
> I know it's super popular to think of alone time for developers as sacred, but it leads to worse outcomes. As Carl Sagan said, extraordinary claims require extraordinary evidence. Have you attempted this in your organization? And measured tangible results? > Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are used to being treated a certain way will tolerate. I have to be honest here: it depends a lot on the market you are hiring from and the caliber of programmers you employ. Sure, if you offshore or go for “best cost” programmers or bootcamp grads you should probably try pairing them up or at least expect to do quite a lot of handholding. But if you hire real engineers you won’t need to do that. Anyways, if you do try it… good luck keeping them in your org for more than a month!
sanderjd 5y ago
Communication is important but 50% seems really high to me. I would feel very hassled and would before long quit a team structured the way you describe here. Diff'rent strokes for diff'rent folks I guess.

ianbutler 5y ago

> Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are. Heavy disagree, there is deep work that requires working a lone. Anything actually technically complex requires both enormous communication AND execution time. Ive worked in companies with pairing all the time and solo execution. By far solo execution of different parts with communal design and heavy communication produced the best outcomes.

Clubber 5y ago

>A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. I've never been on a team where developers talk 50% of the time. We have a meeting to prioritize tickets once a week and talk to other devs when necessary. If I worked at a company where devs were poking me 50% of my day, I'd leave screaming.

brimble 5y ago
> I've never been on a team where developers talk 50% of the time. We have a meeting to prioritize tickets once a week and talk to other devs when necessary. Shit, I have—but if you count only productive hours, it's more like 10-20% are talking :-)

btown 5y ago

It's also strange that this is written as if there's no option other than "have a meeting" or "save it until tomorrow." That's what Slack is for! Start a thread, notify the right folks, but also ensure you share context about time urgency e.g. "I'd like to respond to $stakeholder today" or "Can you share thoughts sometime before standup tomorrow?" - and importantly, especially for engineers who might take things literally, make sure you share whether or not any coding action (EDIT: including digging into existing code) is requested as part of that effort. Engineers also appreciate that their opinions are valued. Be a buffer so they don't feel like they're getting the full force of the stakeholder, but package the requests in realtime, and build a rapport so that you'll know if you're over-asking!

mkl95 5y ago

> I almost agree with all of this, with the caveat of "leave developers alone". > A well functioning Agile team is talking to one another (within the team) about 50% of the time. Of a 40 hour work week, 20 of those hours ought to be spent discussing. I have been part of several Agile teams, starting as a junior engineer at a small startup, and eventually becoming a tech lead at a wannabe unicorn. There's something common to all those places, and it's that spending a significant amount of time discussing things is just not possible. Spending 50% of your time discussing stuff will put a target on your back. The pressure to deliver moderate to unrealistic amounts of work is always there. In that sense, POs and BAs never leave developers alone. Most of their time is spent making product's kitsch dreams come true.

DoingIsLearning 5y ago

> 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

gashmol 5y ago

50% of the time talking sounds like a nightmare. I don't think you can build anything nontrivial if you get interrupted all the time.

TameAntelope 5y ago
I would argue that the only way to build something meaningful to someone other than you is to talk about it approximately half of the time you work on it.
- stitched2gethr 5y ago
  I believe many highly successful products would contradict this claim.
- zeroonetwothree 5y ago
  Well you would be wrong. I’ve built many such things spending far less time discussing them.

908B64B197 5y ago

> I know it's super popular to think of alone time for developers as sacred, but it leads to worse outcomes. As Carl Sagan said, extraordinary claims require extraordinary evidence. Have you attempted this in your organization? And measured tangible results? > Honestly, at this point, developers probably shouldn't ever be coding alone to begin with, but there are limits to what people who are used to being treated a certain way will tolerate. I have to be honest here: it depends a lot on the market you are hiring from and the caliber of programmers you employ. Sure, if you offshore or go for “best cost” programmers or bootcamp grads you should probably try pairing them up or at least expect to do quite a lot of handholding. But if you hire real engineers you won’t need to do that. Anyways, if you do try it… good luck keeping them in your org for more than a month!

sanderjd 5y ago

Communication is important but 50% seems really high to me. I would feel very hassled and would before long quit a team structured the way you describe here. Diff'rent strokes for diff'rent folks I guess.