3 ms·

>Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. I

>Agile wasn't meant for project management but instead as as a tool to organize work in development teams and respond to situation arising in such landscape. I wouldn't describe it as such. Such descriptions are how managers got the idea they can put development teams into their bubbles while restricting their access to assets required, demanding they go through multiple layers of management to get simple things done. Ideally, you don't just have a response, but the power to change things more efficiently. Case in point: devops, CICD. Most teams would benefit from having their own CICD. Many companies silo a separate "devops" team and multiple development teams, while pipelining the demands of dev teams from manager to manager. "Devops" team gets swarmed by status pings every day, development teams are annoyed because trivial things don't get solved, management gets annoyed because "why is it taking so long?". And the team could easily teach someone the basics and get their test environment running. Of course, above scenario requires management gives the power to change things to more people. Management in general thrives on lack of trust, so that's a no-no. "We love agile!", they say. Yes, when the teams get nicely silo'd and somehow become "more predictable", but are still as powerless as before.

beny23 4y ago
I think the main thing about agile is a plan-do-study-act cycle than can be adapted to anything even project management. The trick is not to think I can just adopt a process and will then be agile. It always has to be adapted to context and what works for you. As to CI/CD pipelines: I think a centralised devops team that blocks everyone is as much an anti pattern as a wild-west approach where 3 teams operate 4 different CI/CD tech stacks. There is much to be said about building a platform (when the size of the operation is big enough to warrant it) and using golden paths or paved roads.
redditor98654 4y ago
Is this really true? That most teams depend on a separate team for th CI/CD stuff? I have only worked at AWS and all teams here completely own their deployments and operations. I thought this was how everyone does it.
- BlargMcLarg 4y ago
  I didn't say most, but many. And yes, this does happen in plenty of spaces, for no good reason other than management decision. Dev teams own the code, but they don't own the DB, the pipeline, the environment, etc. It creates a lot of friction and bottlenecks, while keeping developers from improving.
- Aeolun 4y ago
  > I thought this was how everyone does it. Everyone that has any sense, yes. Any company with a legacy ops/dba/it team? No. These people are now called devops because it’s trendy, and they have too much political capitsl to suddenly get rid off (plus such fun things as thinking devs are too irresponsible to touch prod).
  - galangalalgol 4y ago
    Where I work bigger projects have some dedicated devops people to set up infrastructure build common images the whole team uses and sit next to people working on their pipelines to help. Smaller projects its all developer driven because there is no overhead and no ine to synchronize infrastructure with.

beny23 4y ago

I think the main thing about agile is a plan-do-study-act cycle than can be adapted to anything even project management. The trick is not to think I can just adopt a process and will then be agile. It always has to be adapted to context and what works for you. As to CI/CD pipelines: I think a centralised devops team that blocks everyone is as much an anti pattern as a wild-west approach where 3 teams operate 4 different CI/CD tech stacks. There is much to be said about building a platform (when the size of the operation is big enough to warrant it) and using golden paths or paved roads.

redditor98654 4y ago

Is this really true? That most teams depend on a separate team for th CI/CD stuff? I have only worked at AWS and all teams here completely own their deployments and operations. I thought this was how everyone does it.

BlargMcLarg 4y ago
I didn't say most, but many. And yes, this does happen in plenty of spaces, for no good reason other than management decision. Dev teams own the code, but they don't own the DB, the pipeline, the environment, etc. It creates a lot of friction and bottlenecks, while keeping developers from improving.
Aeolun 4y ago
> I thought this was how everyone does it. Everyone that has any sense, yes. Any company with a legacy ops/dba/it team? No. These people are now called devops because it’s trendy, and they have too much political capitsl to suddenly get rid off (plus such fun things as thinking devs are too irresponsible to touch prod).
- galangalalgol 4y ago
  Where I work bigger projects have some dedicated devops people to set up infrastructure build common images the whole team uses and sit next to people working on their pipelines to help. Smaller projects its all developer driven because there is no overhead and no ine to synchronize infrastructure with.