|
|
|
|
|
|
by onion2k
1526 days ago
|
|
|
However, the combination of "being in one of those majorities of companies that believes in agile" and "not being in these meetings" is not available. I hear this from lots of developers. I also hear that none of them have ever raised the problem with their management, or attempted to suggest that they could submit notes instead when they have a lot of other work on, or anything that would reduce the number of meetings they need to attend. Practically all developers just coast along believing that because that's how things are it's impossible to change anything. This is despite the fact that agile includes a retro meeting specifically for raising these things. However, FWIW I wasn't actually suggesting missing all those meetings. Just some of them, when you have other priorities. I've worked on teams where I've been invited to multiple daily standups and I'd have lost a couple of hours a day if I'd not been willing to push back. In every case I've been listened to and been able to communicate what I've been doing and whether I need any help in other ways instead (usually just by editing the standup notes myself). Here's a suggestion. One of the key things about agile is that you have to 'process your processes'. If something isn't working for the team then you should iterate on it. At your next retrospective raise the problem - say "We should stop spending N hours a week on standups because it's stopping me finding clear blocks of time to focus on delivery. We should find a way to reduce the number of meetings I have. How about we have them on Monday, Wednesday and Friday, and email our standup updates to the PM on Tuesday and Thursday." If the team agrees that would save you 40% of your standups.. |
|
|
I have. TL;DR: My managers effectively gaslighted me. "You don't understand agile" despite them being incapable of reciting the agile manifesto and not even knowing what does/doesn't belong to Scrum. "Oh but there has to be some communication", despite my argument clearly not being "there should be no communication". "You're not a team player", despite working together just fine outside those windows. It was an experience which effectively achieved nothing while wasting my time and emotional investment.
That's not to mention the obvious: a lot of managers have ulterior motives to keep the status quo.
>Practically all developers just coast along believing that because that's how things are it's impossible to change anything.
For the most part, that echoes my experience with a lot of companies. The majority don't want change. The majority don't have the power to change things alone. A lot of people don't know any better, and are afraid of the unknown. They have a positive experience with "Agile/SCRUM" because it's marginally better than what they had, even though they can't pinpoint exactly what attributes to their improved situation, leading to pointing the entire package as a big plus.
This really shouldn't come as a surprise either. You can introduce retrospectives and whatever; most companies are still top-down hierarchies at heart. The majority of people learn from a young age not to rile things up, and the IT crowd is definitely not known for being rebellious towards those in power. The entire thing points towards waiting for some people in power to try something different, or for individuals to try their own luck at entrepreneurship.
NB: I don't fault people for liking this or wanting this. The bigger problem is how quickly the far majority of companies force feed the entire development team this way of working, leaving almost no place for the people who don't want to work this way. If you don't like it, good luck finding something that isn't highly Agile/SCRUM/meeting-oriented or at risk of becoming that in the near future. It's the same thing with remote work, asynchronous work, non-standard work hours, you name it. It's the incessant need for a one-size-fits-all approach which to this day is questionable at best.