3 ms·
Does Scrum itself empower individual members of the development team? Saying it’s on the developers not to be “mindless drones” and the managers to not be “bad
by dgreensp 8y ago
Does Scrum itself empower individual members of the development team? Saying it’s on the developers not to be “mindless drones” and the managers to not be “bad managers” may be true but doesn’t really refute the article’s point. Maybe you have Scrum disempowering developers and (at the best companies) other forces, including other practices and processes, empowering them.
For example, Scrum says responsibility for operations and testing are to be shared responsibilities; you don’t have an ops team or a testing team, or titles, or recognized responsibility. You might have a de facto ops team, but those are just some individuals who have chosen to carry pagers right now. I’ve seen things like this play out and been puzzled by it. I didn’t actually realize until reading this article that people have been giving talks and writing books saying that “subteams” are bad, but it makes sense now.
The point being, not having officially recognized responsibilities is a form of disempowerment.
- alistairSH 8y agonot having officially recognized responsibilities I feel like that's a bit of an overstatement. While scrum advocates for shared responsibility, it doesn't demand no-titles, no-roles, or no-passions. It's all about ensuring the entire team possesses 'T' shaped skills. Depth and expertise in some areas, but still generally knowledgable across all areas. My test engineer doesn't write much code, but in a pinch, she can. My PO is fully capable of "running" the team in my absence, as is the test engineer. All my developers know the full DevOps pipeline and can contribute to it, though none of them are DevOps engineers by title or primary responsibility. And I'm an ex-developer-now-manager who can do a bit of everything, though these days I'd rather go to meetings and play office politics so my developers can do their thing.
- dgreensp 8y agoScrum recognizes no titles for Development Team members, regardless of the work being performed by the person; Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis Maybe T-shaped people are required to make Scrum work, or vice versa? Like if you are running a restaurant and your company process says “there is no distinction between waiters and chefs,” then your waiters need to be decent cooks, and your chefs need to be personable and presentable. “Passion” can be a liability in this environment, for example being passionate about great food or great service. The lack of specialization doesn’t seem directly related to how to do great work, or be really happy at work.