7 ms·

I have been an engineer or in engineering leadership most of my life. Now CTO of a large company. Nobody wants to say it out loud, but what we really need to do

I have been an engineer or in engineering leadership most of my life. Now CTO of a large company. Nobody wants to say it out loud, but what we really need to do is treat engineers with respect. Give them a quiet place to work and leave them the fuck alone. Agile is just a watered-down compromise. We still get to have project managers, we just call them scrummasters and they get to bother the engineers slightly less.

Consultant32452 7y ago
I go back and forth on whether I should even call what we do a scrum. My understanding of a developer scrum is that it's supposed to benefit the developers by encouraging communication about status and issues. What we do is more like a round robin status update for the project manager who runs the meeting. The only discussions that ever come out of it are at the project management/schedule level, not the technical level. Calling it a scrum checks a box on someone's review for implementing agile practices, so at work I just let it go.
kristoff_it 7y ago
In my case what made the difference was holding the meeting without any management in it. To be fair to the agile movement, self-orgainizing teams and the value of individuals are all themes expressed quite clearly. Maybe you could try a small pilot and see where it goes.
- bradknowles 7y ago
  IMO, no standup should have anyone attend that is not a direct member of the one specific team in question. At least, not without really good reason. So, the project manager/Scrum Master for the team, plus the technical members of the team. That's it. You can have guest attendees, if there is a good reason. You can have temporary members, if they're working with the team for a short period of time. But the basic rule should be just the engineers plus their project manager/scrum master. And no one should be in multiple standups without a really good reason. Maybe the PMs or Scrum Masters should be in a Scrum of Scrums, but that's about it.
  - loopz 7y ago
    Bad management will find a way. Allow all guests, even announce all times. People will learn to attend where it matters, and simply won't have time for many standups. Format should cut off bad management and time-sinks too. Harder to contain democratization (the opposite of every other suggested model!).
NikolaNovak 7y ago
Interesting, and I think a lifelong consideration/debate. Having been a sysadmin / various kinds of techie for the majority of my career,nevertheless from most of my initial visibility into business & management worlds; and now having been full-time manager for 18 months; my feeling is that absolutely you need to understand, support, and enable your engineers to work on and in the way that makes them productive and satisfied... but last thing you should possibly do is "leave them the fuck alone". Otherwise, very quickly, there would be no salary for anybody :| That being said, to the topic here, most "standups" I've been to have been a "spoke and hub" model where a PM elicits list of one-on-one status updates, and having done their part, people can doze off for rest of the meeting. In meetings I own, I try to change that to "Tell us of things that matter / are interesting to everybody here". It's not an easy criteria to fulfill though, for management or techies alike.
GoToRO 7y ago
We do call them scum masters and they are not engineers and not managers. It's like "let the blind lead the way". Same for managers that have no clue about what they are supposed to manage.
watwut 7y ago
I dont think it is that simple. Mostly because I was lucky enough to be in teams that were exactly "quiet place to work and leave them the fuck alone" and did not worked all that great. First, people got demotivated due to seemingly no one caring what they do and when they are done. Some people were unable to finish tasks or self-organize. And this was the most functional team under the circumstances. Second, in one team where cooperation was necessary, actual lack of defined responsibilities and leader meant that important tasks were not done. There were fights over how less important tasks should be done. Some controlling people tried to take over leadership, fighting among themselves. Then for a while everyone gave up leading to no one having initiative. Then fights again followed by people not talking to each other. Third, customer ended up complaining over low performance and having to tell everyone the same thing again and again, cause people did not shared info.
commandlinefan 7y ago
> Agile is just a watered-down compromise. In my experience (27 years worth), agile is a watered-down compromise _on paper_ but is actually worse in practice.
mavelikara 7y ago
I am going to have conversation on this exact same topic with my boss' boss later this week. I am influenced by Martin Fowler's State of Agile talk from 2018 [1]. Agile has driven all the developers out of the room, and now it is a playpen for all the process mavens. [1]: https://martinfowler.com/articles/agile-aus-2018.html https://martinfowler.com/articles/agile-aus-2018.html
alicorn 7y ago
How cute. I tried your suggestion once. What I got was an overengineered, poorly documented delivery that matched the spec about 50%. Oh, it was also a year late. Sorry, but processes are there for a reason, and the reason is, broadly, that getting an average team of engineers to deliver on time, according to spec and without diving all the way down every overoptimization / navelgazing / random interest / flamewar / framework flavor of the day rabbithole there is is otherwise impossible. With process it becomes at least a tiny bit more akin to herding cats instead of just watching them run amok every which way.
- musicale 7y ago
  > on time, according to spec time, features, reliability: pick two
  - NikolaNovak 7y ago
    Typically, the triangle involves money on one of the axis. In principle you could have those three if you throw enough resources at them.
- aliswe 7y ago
  > How cute. How unnecessary!

Consultant32452 7y ago

I go back and forth on whether I should even call what we do a scrum. My understanding of a developer scrum is that it's supposed to benefit the developers by encouraging communication about status and issues. What we do is more like a round robin status update for the project manager who runs the meeting. The only discussions that ever come out of it are at the project management/schedule level, not the technical level. Calling it a scrum checks a box on someone's review for implementing agile practices, so at work I just let it go.

kristoff_it 7y ago

In my case what made the difference was holding the meeting without any management in it. To be fair to the agile movement, self-orgainizing teams and the value of individuals are all themes expressed quite clearly. Maybe you could try a small pilot and see where it goes.

bradknowles 7y ago
IMO, no standup should have anyone attend that is not a direct member of the one specific team in question. At least, not without really good reason. So, the project manager/Scrum Master for the team, plus the technical members of the team. That's it. You can have guest attendees, if there is a good reason. You can have temporary members, if they're working with the team for a short period of time. But the basic rule should be just the engineers plus their project manager/scrum master. And no one should be in multiple standups without a really good reason. Maybe the PMs or Scrum Masters should be in a Scrum of Scrums, but that's about it.
- loopz 7y ago
  Bad management will find a way. Allow all guests, even announce all times. People will learn to attend where it matters, and simply won't have time for many standups. Format should cut off bad management and time-sinks too. Harder to contain democratization (the opposite of every other suggested model!).

NikolaNovak 7y ago

Interesting, and I think a lifelong consideration/debate. Having been a sysadmin / various kinds of techie for the majority of my career,nevertheless from most of my initial visibility into business & management worlds; and now having been full-time manager for 18 months; my feeling is that absolutely you need to understand, support, and enable your engineers to work on and in the way that makes them productive and satisfied... but last thing you should possibly do is "leave them the fuck alone". Otherwise, very quickly, there would be no salary for anybody :| That being said, to the topic here, most "standups" I've been to have been a "spoke and hub" model where a PM elicits list of one-on-one status updates, and having done their part, people can doze off for rest of the meeting. In meetings I own, I try to change that to "Tell us of things that matter / are interesting to everybody here". It's not an easy criteria to fulfill though, for management or techies alike.

GoToRO 7y ago

We do call them scum masters and they are not engineers and not managers. It's like "let the blind lead the way". Same for managers that have no clue about what they are supposed to manage.

watwut 7y ago

I dont think it is that simple. Mostly because I was lucky enough to be in teams that were exactly "quiet place to work and leave them the fuck alone" and did not worked all that great. First, people got demotivated due to seemingly no one caring what they do and when they are done. Some people were unable to finish tasks or self-organize. And this was the most functional team under the circumstances. Second, in one team where cooperation was necessary, actual lack of defined responsibilities and leader meant that important tasks were not done. There were fights over how less important tasks should be done. Some controlling people tried to take over leadership, fighting among themselves. Then for a while everyone gave up leading to no one having initiative. Then fights again followed by people not talking to each other. Third, customer ended up complaining over low performance and having to tell everyone the same thing again and again, cause people did not shared info.

commandlinefan 7y ago

> Agile is just a watered-down compromise. In my experience (27 years worth), agile is a watered-down compromise _on paper_ but is actually worse in practice.

mavelikara 7y ago

I am going to have conversation on this exact same topic with my boss' boss later this week. I am influenced by Martin Fowler's State of Agile talk from 2018 [1]. Agile has driven all the developers out of the room, and now it is a playpen for all the process mavens. [1]: https://martinfowler.com/articles/agile-aus-2018.html https://martinfowler.com/articles/agile-aus-2018.html

alicorn 7y ago

How cute. I tried your suggestion once. What I got was an overengineered, poorly documented delivery that matched the spec about 50%. Oh, it was also a year late. Sorry, but processes are there for a reason, and the reason is, broadly, that getting an average team of engineers to deliver on time, according to spec and without diving all the way down every overoptimization / navelgazing / random interest / flamewar / framework flavor of the day rabbithole there is is otherwise impossible. With process it becomes at least a tiny bit more akin to herding cats instead of just watching them run amok every which way.

musicale 7y ago
> on time, according to spec time, features, reliability: pick two
- NikolaNovak 7y ago
  Typically, the triangle involves money on one of the axis. In principle you could have those three if you throw enough resources at them.
aliswe 7y ago
> How cute. How unnecessary!