7 ms·

What would you recommend as a better alternative?

stephc_int13 4y ago
As little middle management as possible. Flat hierarchy is an other kind of bullshit, clearly established leadership is important. When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them. Most of the bureaucracy problems are magically going away when middle management is gone.
- tgv 4y ago
  That's one of the reasons I work for a small company. There's just one boss, and he's also what in the US would probably be called VP, both formally and informally (there's a difference between the formal and informal hierarchy). He knows his limits, is technically adept although he doesn't know much about programming, and just cares about usability. As a consequence, there's no politics, no endless meetings (yes, I've done Agile too elsewhere, with those retrospectives, planning meetings and pointless burndown charts). There's no other team blocking me or forcing me to do something differently (because of course teams are self-organizing, but heaven forbid if you do something that touches the domain of another team). The salary is somewhat lower, but I actually enjoy my job. Middle management is just nepotism, where incompetent/not-caring managers hire from their network to gain power.
- hef19898 4y ago
  >> When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them. That ia a mjor difference between Amazon and most other places I worked at. Amazon management actually did things beyond managing. There are some of the managers in places as well, they are a minority so.
duncan-donuts 4y ago
Not op but I’ve worked in Agile™ shops, places that are agile, and waterfall-y enterprise stuff. The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. Pointing doesn’t matter, extensive grooming doesn’t matter, extensive planning doesn’t matter, sprints don’t matter, etc. Grooming your work does matter but 30 minutes is enough for a high performing team to hash out a week’s worth of work. Planning does matter but it should be kept to high level product goals and nothing more. Sprints should only be used if you have something you’re actually sprinting towards. Most of the time that’s not the case. Points straight up don’t matter. All of this being said this puts a lot of pressure on product managers because it’s hard for them to express how long something will take. The key here is that even if you do all the ceremonies you don’t really know how long it’ll take anyway. The only way you can work like this is if you have built up trust from your PM. If you can throw all of the shit away and give the PM what they want they’ll go to bat for you. For agile to work there has to be an incredible amount of trust that every team member is going to do what they say. And the lack of trust is when you get Agile™
- shade 4y ago
  > The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team. No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue tracking. Deployments scheduled every Tuesday when their QA person signed off on the feature working as expected (this was in the days before CI/CD became common). Worked great. Low friction, they got features and bug fixes, we didn't get hassled, and we could set up a call (or usually just a couple of emails) if we needed clarification or needed to explain why something was more complex to do than we or they originally thought. One of the best six month periods in my career, and I've been doing this stuff for almost 25 years. I don't mind some aspects of scrum, but the things I don't mind (mostly around team autonomy and self-organization) seem to be the same things that are quickest to get thrown out when someone gets impatient.
  - karmelapple 4y ago
    Have you read Team Topologies? This sounds like a stream aligned team, albeit a small one, and sounds like you had great success.
    - shade 4y ago
      I have not, but thanks for the recommendation - I just put it on my to-read list.
  - whynotminot 4y ago
    Who knew coordinating development work could be easy with one developer?
    - shade 4y ago
      That definitely simplified it. :) That said, we could (and for a few weeks, did) bring in a second developer with no issues. My last job had me on a ten person developer team and I would not try to use that process there - although I'd consider splitting that into a couple of smaller groups focused on a specific product/system and using a very lightweight process for those groups.

As little middle management as possible. Flat hierarchy is an other kind of bullshit, clearly established leadership is important. When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them. Most of the bureaucracy problems are magically going away when middle management is gone.

tgv 4y ago
That's one of the reasons I work for a small company. There's just one boss, and he's also what in the US would probably be called VP, both formally and informally (there's a difference between the formal and informal hierarchy). He knows his limits, is technically adept although he doesn't know much about programming, and just cares about usability. As a consequence, there's no politics, no endless meetings (yes, I've done Agile too elsewhere, with those retrospectives, planning meetings and pointless burndown charts). There's no other team blocking me or forcing me to do something differently (because of course teams are self-organizing, but heaven forbid if you do something that touches the domain of another team). The salary is somewhat lower, but I actually enjoy my job. Middle management is just nepotism, where incompetent/not-caring managers hire from their network to gain power.
hef19898 4y ago
>> When you absolutely need middle management, force them to also do some real work, if they can’t, don’t hire them. That ia a mjor difference between Amazon and most other places I worked at. Amazon management actually did things beyond managing. There are some of the managers in places as well, they are a minority so.

duncan-donuts 4y ago

Not op but I’ve worked in Agile™ shops, places that are agile, and waterfall-y enterprise stuff. The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. Pointing doesn’t matter, extensive grooming doesn’t matter, extensive planning doesn’t matter, sprints don’t matter, etc. Grooming your work does matter but 30 minutes is enough for a high performing team to hash out a week’s worth of work. Planning does matter but it should be kept to high level product goals and nothing more. Sprints should only be used if you have something you’re actually sprinting towards. Most of the time that’s not the case. Points straight up don’t matter. All of this being said this puts a lot of pressure on product managers because it’s hard for them to express how long something will take. The key here is that even if you do all the ceremonies you don’t really know how long it’ll take anyway. The only way you can work like this is if you have built up trust from your PM. If you can throw all of the shit away and give the PM what they want they’ll go to bat for you. For agile to work there has to be an incredible amount of trust that every team member is going to do what they say. And the lack of trust is when you get Agile™

shade 4y ago
> The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team. No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue tracking. Deployments scheduled every Tuesday when their QA person signed off on the feature working as expected (this was in the days before CI/CD became common). Worked great. Low friction, they got features and bug fixes, we didn't get hassled, and we could set up a call (or usually just a couple of emails) if we needed clarification or needed to explain why something was more complex to do than we or they originally thought. One of the best six month periods in my career, and I've been doing this stuff for almost 25 years. I don't mind some aspects of scrum, but the things I don't mind (mostly around team autonomy and self-organization) seem to be the same things that are quickest to get thrown out when someone gets impatient.
- karmelapple 4y ago
  Have you read Team Topologies? This sounds like a stream aligned team, albeit a small one, and sounds like you had great success.
  - shade 4y ago
    I have not, but thanks for the recommendation - I just put it on my to-read list.
- whynotminot 4y ago
  Who knew coordinating development work could be easy with one developer?
  - shade 4y ago
    That definitely simplified it. :) That said, we could (and for a few weeks, did) bring in a second developer with no issues. My last job had me on a ten person developer team and I would not try to use that process there - although I'd consider splitting that into a couple of smaller groups focused on a specific product/system and using a very lightweight process for those groups.