6 ms·

We have been to all ends of the earth on this sort of thing. The final conclusion I have arrived at: The amount of process and ceremony required is inversely p

We have been to all ends of the earth on this sort of thing. The final conclusion I have arrived at: The amount of process and ceremony required is inversely proportional to the trust level on the team. Once we had some difficult conversations and realigned expectations, we found our daily standup was extremely redundant. Team members began to realize that others would simply reach out as needed. Everything is much more async now. Only 3rd party interactions require explicit scheduling these days. Prod down, vendor integrations, etc. Other observations: We seem to somehow spend more time on adhoc calls than our prior scheduled calls, but A Lot More (tm) is getting done regardless. Stress levels seem down as well. Weird how you can have cake and eat it too sometimes. I don’t know if I would sit here and proclaim that process is exclusively a bandaid for lack of trust, but it certainly seems like one indicator of this condition.

woutr_be 4y ago
I've had a similar impression in my previous company, this was a large multi-national bank who proclaimed they want to go agile. Spared no expense in hiring agile coaches and scrum masters. It even went as far as some people having two standups a day, one with their own scrum team, and another with the "leaders" of other scrum teams. Our scrum ceremonies were always stretched and highly moderator, except for the one that mattered, the retrospective. This was always hijacked by the agile coach, who pushed his agile believes and wouldn't listen to the actual developers who were trying to improve the process. Obviously following agile to the letter, caused a lot of frustration amongst developers, and lead to almost every project failing. But at least the coaches got paid well.
- nprateem 4y ago
  IME it's just scrum masters trying to prove their worth. Since they're either non-technical or not close to the tech, they're reduced to robots asking "do you need me to escalate that?", or "so can we move it to done?". I'm sure most scrum masters could be replaced by chatbots. It really gets quite tiresome, especially since if I needed something escalating I'd have asked them already, and I'm perfectly capable of moving a ticket myself. Instead I just disengage for the hour and half of standups I have per day (yes, I know)
  - throwawaysleep 4y ago
    Scrum masters are one of the reasons I chose to be overemployed. Their presence in an organization taught me that it is highly rational to be performative over performing.
    - nfhshy68 4y ago
      Rule 1.
    - germinalphrase 4y ago
      How’s it working out for you?
  - hef19898 4y ago
    Do you also have scrum-of-scrums? Because that is out DevOps team's latest idea to speed up an ERP project. So we get scrum masters instead of functional ERP experts and consultants. I am curious so, what a scrum-scrum would actually look like...
    - scruple 4y ago
      > Do you also have scrum-of-scrums? I remember my previous employer trying that out in one or two departments. Ultimately that company landed on SAFe Agile and it was a complete and utter shit show. Where I'm at now is "doing" Kanban but the standup is really just a daily status update. I'm slowly getting the management to recognize that these things are problems, why they are problems, and what can be done about them. But I'm much happier with this situation because I can actually push back against it and try to improve the thing. At my previous employer, any attempt to even begin highlighting problems would render you standing alone against what amounts to a committee of management (in this case, specifically, people who are only employed because of the fact that they use these extremely heavy processes) if you wanted to discuss these things.
      - hef19898 4y ago
        Your previous employer sounds a lot like my current one. Add to that a DevOps head who currently holds his first job in anything IT related and actual developers that are almost exclusively external and subcontractors... All our internal developers are doing is Palantir dashboards and some interfaces to get the data into Palantir.
- pydry 4y ago
  IME whenever an organization like that hires an agile coach they either get a jaded cynical jobsworth who powers through the motions implementing some process heavy thing or an idealist who ends up clashing with managers who definitely want "agile", but with status updates, quarterly planning and accountability metrics and all the other shit that makes it impossible to be agile. The latter will typically get managed out or even fired. There doesnt really seem to be a way to square this circle.
  - woutr_be 4y ago
    At least what happened at my company, is that they hire an idealist who preaches agile to management, and then gets frustrated when reality doesn’t match what they preached, because now their job is on the line. It was somehow hilarious to watch him weasel his way out of missed deadlines and failed project. Every developer ended hating him, since developers got the blame for everything, since we didn’t follow his idealistic view of agile.
    - pydry 4y ago
      In fairness Ive seen data scientists get equally surly when management hires them expecting them to work their magic and the reality is that the data is so filthy that there's nothing they can usefully do. Ideally you should quit if conditions make your job impossible - that being the economically "efficient" thing to do. But mortgages, kids to feed and the everpresent reality of the capitalist system often prevents one from doing that.
- jraph 4y ago
  > to the actual developers who were trying to improve the process I went from a company which adopted agile after I joined, to an older company which has never adopted agile. My current take is that without agile, there's no process to improve. Well, yes, but not on a bi-weekly basis. We are grown-ups, things work, brokenness gets raised when needed and there's no heavy process crushing people to fix.
  - woutr_be 4y ago
    I do agree with you, and it’s not that I hate agile, I actually think it’s a great way of working, if you allow teams to change what it means to work agile. However, more often than not, those agile coaches or scrum masters follow to handbook, without allowing real world experiences to change the process.
    - Viliam1234 4y ago
      In my experience, they don't even follow the handbook, but rather the management's decisions about which parts of "agile" we want (Jira tickets, daily meetings) and which parts can be ignored (retrospective, having no long-term deadlines).
- hef19898 4y ago
  The old form or substance discussion. Some compabies have the substance, e.g. Toyota when it come to lean, some have both form and substance while the majority implement the form without getting the substance. The latter also wonder why things don't work as expected...
- theCodeStig 4y ago
  This sounds eerily familiar. Let me guess, there were sprint planning sessions that went on for hours. More time was allocated to planning the work, than for the actual work. Replacing one dogma (waterfall) with another (dogmatic agile), is not agile.
  - stonemetal12 4y ago
    I think it is a necessary step in the process. No org is going to go from full on dogmatic waterfall to fully agile in one step. Dogmatic agile either works or fails on its own. If it works then the org might try going actual agile.
ohmahjong 4y ago
I think that you've hit the nail on the head with trust. I have felt most productive in small teams with a lot of autonomy and self-regulation. The most interesting problem to me is how to establish that trust in the first place; especially if team members have varying levels of "conscientiousness" regarding code and process
zthrowaway 4y ago
I would love this set up. However we have one team member who is a total cowboy, goes off on tangents and can spend weeks on a random idea than an epic/quarterly goal and we can’t get rid of him. So daily stand-up’s are our only way of seeing what he’s up to. There’s always looking at PRs but we only have so much time individually to babysit PRs. It’s a trust thing for sure.
- sarchertech 4y ago
  Does the whole team really need to be involved with this babysitting? What’s your manager doing?
i_am_proteus 4y ago
Process has value specifically when one should assume a lower level of trust. This is not always a bad thing. A few examples: Larger organizations with significant turnover, such as government bureaucracies. Sub-groups of the organization rely on process to interface with each other. Guild-like organizations that work on individual projects with changes in team composition. Showing up to a new jobsite with people you haven't worked with before means less trust than you'd have on a team that's been together for a while. Process is the glue that keeps things functioning. I'd rather work on a small team in a high-trust environment, but such a thing doesn't often scale well to large projects in every industry.
snarf21 4y ago
I agree that trust is a major component, especially from above. But it also requires a "team" mindset. The adhoc calls you are talking about are helpful for the team but they are disruptive to the person. This causes this approach to not work for some teams because there are people who just want to sit heads down and crank code. Those are the people that require daily stand ups to make sure they don't go off all willy nilly. These people also tend to get annoyed when someone else needs their subject matter expertise to fix/debug/tweak something as it is "interrupting" them. When the team evolves to value for team success over individual, then this sort of things is obviously more efficient because everyone is actively engaged in keeping everyone in sync. So I think it is much more about a mature and cohesive team than trust explicitly. However, ime, there are always some who just want to play whac-a-mole and be "done" even when it isn't in the team's best interest.
drewcoo 4y ago
> The amount of process and ceremony required is inversely proportional to the trust level on the team. True! Though usually the mistrust is management of the team. > Once we had some difficult conversations and realigned expectations, we found our daily standup was extremely redundant. And conversely, when the team isn't communicating with one another, that's when introducing standups does the most good. Managers wanting to micromanage leads to heavy process.

woutr_be 4y ago

I've had a similar impression in my previous company, this was a large multi-national bank who proclaimed they want to go agile. Spared no expense in hiring agile coaches and scrum masters. It even went as far as some people having two standups a day, one with their own scrum team, and another with the "leaders" of other scrum teams. Our scrum ceremonies were always stretched and highly moderator, except for the one that mattered, the retrospective. This was always hijacked by the agile coach, who pushed his agile believes and wouldn't listen to the actual developers who were trying to improve the process. Obviously following agile to the letter, caused a lot of frustration amongst developers, and lead to almost every project failing. But at least the coaches got paid well.

nprateem 4y ago
IME it's just scrum masters trying to prove their worth. Since they're either non-technical or not close to the tech, they're reduced to robots asking "do you need me to escalate that?", or "so can we move it to done?". I'm sure most scrum masters could be replaced by chatbots. It really gets quite tiresome, especially since if I needed something escalating I'd have asked them already, and I'm perfectly capable of moving a ticket myself. Instead I just disengage for the hour and half of standups I have per day (yes, I know)
- throwawaysleep 4y ago
  Scrum masters are one of the reasons I chose to be overemployed. Their presence in an organization taught me that it is highly rational to be performative over performing.
  - nfhshy68 4y ago
    Rule 1.
  - germinalphrase 4y ago
    How’s it working out for you?
- hef19898 4y ago
  Do you also have scrum-of-scrums? Because that is out DevOps team's latest idea to speed up an ERP project. So we get scrum masters instead of functional ERP experts and consultants. I am curious so, what a scrum-scrum would actually look like...
  - scruple 4y ago
    > Do you also have scrum-of-scrums? I remember my previous employer trying that out in one or two departments. Ultimately that company landed on SAFe Agile and it was a complete and utter shit show. Where I'm at now is "doing" Kanban but the standup is really just a daily status update. I'm slowly getting the management to recognize that these things are problems, why they are problems, and what can be done about them. But I'm much happier with this situation because I can actually push back against it and try to improve the thing. At my previous employer, any attempt to even begin highlighting problems would render you standing alone against what amounts to a committee of management (in this case, specifically, people who are only employed because of the fact that they use these extremely heavy processes) if you wanted to discuss these things.
    - hef19898 4y ago
      Your previous employer sounds a lot like my current one. Add to that a DevOps head who currently holds his first job in anything IT related and actual developers that are almost exclusively external and subcontractors... All our internal developers are doing is Palantir dashboards and some interfaces to get the data into Palantir.
pydry 4y ago
IME whenever an organization like that hires an agile coach they either get a jaded cynical jobsworth who powers through the motions implementing some process heavy thing or an idealist who ends up clashing with managers who definitely want "agile", but with status updates, quarterly planning and accountability metrics and all the other shit that makes it impossible to be agile. The latter will typically get managed out or even fired. There doesnt really seem to be a way to square this circle.
- woutr_be 4y ago
  At least what happened at my company, is that they hire an idealist who preaches agile to management, and then gets frustrated when reality doesn’t match what they preached, because now their job is on the line. It was somehow hilarious to watch him weasel his way out of missed deadlines and failed project. Every developer ended hating him, since developers got the blame for everything, since we didn’t follow his idealistic view of agile.
  - pydry 4y ago
    In fairness Ive seen data scientists get equally surly when management hires them expecting them to work their magic and the reality is that the data is so filthy that there's nothing they can usefully do. Ideally you should quit if conditions make your job impossible - that being the economically "efficient" thing to do. But mortgages, kids to feed and the everpresent reality of the capitalist system often prevents one from doing that.
jraph 4y ago
> to the actual developers who were trying to improve the process I went from a company which adopted agile after I joined, to an older company which has never adopted agile. My current take is that without agile, there's no process to improve. Well, yes, but not on a bi-weekly basis. We are grown-ups, things work, brokenness gets raised when needed and there's no heavy process crushing people to fix.
- woutr_be 4y ago
  I do agree with you, and it’s not that I hate agile, I actually think it’s a great way of working, if you allow teams to change what it means to work agile. However, more often than not, those agile coaches or scrum masters follow to handbook, without allowing real world experiences to change the process.
  - Viliam1234 4y ago
    In my experience, they don't even follow the handbook, but rather the management's decisions about which parts of "agile" we want (Jira tickets, daily meetings) and which parts can be ignored (retrospective, having no long-term deadlines).
hef19898 4y ago
The old form or substance discussion. Some compabies have the substance, e.g. Toyota when it come to lean, some have both form and substance while the majority implement the form without getting the substance. The latter also wonder why things don't work as expected...
theCodeStig 4y ago
This sounds eerily familiar. Let me guess, there were sprint planning sessions that went on for hours. More time was allocated to planning the work, than for the actual work. Replacing one dogma (waterfall) with another (dogmatic agile), is not agile.
- stonemetal12 4y ago
  I think it is a necessary step in the process. No org is going to go from full on dogmatic waterfall to fully agile in one step. Dogmatic agile either works or fails on its own. If it works then the org might try going actual agile.

ohmahjong 4y ago

I think that you've hit the nail on the head with trust. I have felt most productive in small teams with a lot of autonomy and self-regulation. The most interesting problem to me is how to establish that trust in the first place; especially if team members have varying levels of "conscientiousness" regarding code and process

zthrowaway 4y ago

I would love this set up. However we have one team member who is a total cowboy, goes off on tangents and can spend weeks on a random idea than an epic/quarterly goal and we can’t get rid of him. So daily stand-up’s are our only way of seeing what he’s up to. There’s always looking at PRs but we only have so much time individually to babysit PRs. It’s a trust thing for sure.

sarchertech 4y ago
Does the whole team really need to be involved with this babysitting? What’s your manager doing?

i_am_proteus 4y ago

Process has value specifically when one should assume a lower level of trust. This is not always a bad thing. A few examples: Larger organizations with significant turnover, such as government bureaucracies. Sub-groups of the organization rely on process to interface with each other. Guild-like organizations that work on individual projects with changes in team composition. Showing up to a new jobsite with people you haven't worked with before means less trust than you'd have on a team that's been together for a while. Process is the glue that keeps things functioning. I'd rather work on a small team in a high-trust environment, but such a thing doesn't often scale well to large projects in every industry.

snarf21 4y ago

I agree that trust is a major component, especially from above. But it also requires a "team" mindset. The adhoc calls you are talking about are helpful for the team but they are disruptive to the person. This causes this approach to not work for some teams because there are people who just want to sit heads down and crank code. Those are the people that require daily stand ups to make sure they don't go off all willy nilly. These people also tend to get annoyed when someone else needs their subject matter expertise to fix/debug/tweak something as it is "interrupting" them. When the team evolves to value for team success over individual, then this sort of things is obviously more efficient because everyone is actively engaged in keeping everyone in sync. So I think it is much more about a mature and cohesive team than trust explicitly. However, ime, there are always some who just want to play whac-a-mole and be "done" even when it isn't in the team's best interest.

drewcoo 4y ago

> The amount of process and ceremony required is inversely proportional to the trust level on the team. True! Though usually the mistrust is management of the team. > Once we had some difficult conversations and realigned expectations, we found our daily standup was extremely redundant. And conversely, when the team isn't communicating with one another, that's when introducing standups does the most good. Managers wanting to micromanage leads to heavy process.