When I participated in SCRM Master class few years ago I was told that all the “authority and control” has to be given up in favor of Team Ownership, and that there will be no need in management involvement in the development process. I liked the concept of more team ownership and less management control , and I still think it makes sense. However, from observing and coaching multiple teams over the last 18 months I do not think this is a slam dunk. There are several factors that have to be considered:
2. Complexity of the project
3. Novelty of the project (an incremental feature vs. new technology)
What I have found was with lower team seniority, higher project complexity and higher project novelty, the “team ownership with less management involvement” model can break.
Here are some of the consequences of operating in such environment:
1. Missed design reviews leading to missed functional and non-functional requirements, as well as sub-optimal technical implementations. 2. Less communication between the team members and the PO, leading to disconnects between them
3. Misunderstanding of Agile practices and ideas, leading to something that looks like SCRUM from outside but in reality is worse than Waterfall.
It’s true that in the world before Agile we had many problems, but it’s also true that we had some good practices including certain oversight by senior team members and development managers who would help the team to ask the right questions and would enforce some of the practices such as design reviews.
In my opinion each situation should be assessed on a case-by-case basis and certain combinations of projects and teams may need to have a development manager involved during the development cycle, to help compensate for lower seniority of the team and higher complexity of the projects. If the Scrum Master for these teams happen to be a development manager then the risk is mitigated.
