This was in addition to teams having product owners and an engineering manager as well at times. At times I had 3 people managing a team with 3-6 engineers.
Very interesting tech culture.
This was in addition to teams having product owners and an engineering manager as well at times. At times I had 3 people managing a team with 3-6 engineers.
Very interesting tech culture.
>And here's something else, Bob: I have eight different bosses right now.
>I beg your pardon?
>Eight bosses.
>Eight?
>Eight, Bob. So that means that when I make a mistake, I have eight different people coming by to tell me about it. That's my only real motivation, is not to be hassled. That, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
Cue some discussion about kids these days and "quiet quitting".
My SO at the time didn't understand what I did at work all day until we saw that movie in the theater.
His cube is so big and private, and he can push to prod without going through change management! Heaven.
My last team before leaving had 3 engineers: tech lead, me, and a junior dev. It had 4 non-engineers managing us: a product owner, a head Agile Delivery Lead, a more junior agile Delivery Lead, and our manager.
Or not, in this case.
All of these chains of command had different and conflicting priorities as well as political wars with each other. The product "owner" knew very little about the ill-defined product they owned yet they set the team's 'official' priorities based on wish lists from the business while the engineers also got different priorities from their chain of command and the scrum master was a glorified admin assistant.
The result was that no strategy existed and nothing of value was done but the engineers were still ground to a paste against the mill stones of the Jira board every two weeks.
It made me miss the simpler times of having a well defined waterfall project being done by a single team of engineers with a single engineering manager and a project manager to make the gantt chart and schedule the meetings.
> Individuals and interactions over processes and tools
very few teams are willing to admit that they need to be making boring things happen.
agile is not a universal tonic.
It is certainly not universal. As an example, if you want to make something great, it has absolutely no relation to your problem.
Honestly, what bothers me the most about this is the idea that "agile delivery lead" is abbreviated "AGL". It doesn't even make it any more pronounceable compared to "ADL".
Like we follow agile principles (often take the core understanding and apply it in a way that works for the team). Usually the positions you mentioned are just EMs or tech leads with added responsibilities.