Project decision making with Agile

Some mythologies (like SCRUM Agile) favor a certain flatness and decentralization of the project structure. Project managers become scrum masters and their mission goes from controlling all aspects of the project to removing team impediments. This is an example where the tool affects or prescribes how the craftsman uses it. The problem is that the framework also assumes that other team members can step up to compensate; that the teams can be self organizing and that they can really see the stakeholders needs. Projects are often a series of choices made with imperfect information. When you decentralize or democratize decision making, you can either improve its outcome (more brains are better than one, direct product owner involvement brings the team closer to the client's real needs), but alternatively, it can make it worse. How can the latter happen? Most project participants are specialized in one way or another and by necessity will have less information about at least some areas. Developers for example are more inclined to vote on using capacity to clear out technical debt, often at the detriment of new essential, value-add functionality. A democratic, flatten decision making process will sometimes skew the project in favor of technical gold plating. In another circumstance, the product owner might not see the 'big picture', and spend too much time in low level features; this will have an opportunity cost, since at some point time or other resources (budget, organizational support) will run out. This can happen in every project, whether agile or not. The point is that SCRUM agile tends to magnify these issues in an imperfect, unbalanced team.

The question might arise - would you rather have an unbalanced team sharing decision making, and in the process creating inefficiencies, or would you rather have a flawed project manager? Alternatively, would you rather have a good project manager or a perfect self organizing team?  I think a lot of the push towards democratizing project decision making was a reaction against concentrating (most of the) project decision making in the hand of one individual.

My point of view is that teams make mistakes just as individuals do. Given specialization, it is almost a given that decentralized decision making will not have the same potential for optimization as centralized decision making. In other words, a good project manager will always trump a good Scrum team.

At the other end of the spectrum, an unbalanced scrum team will probably be just as bad as a bad project manager. A bad project manager might be a more convenient scape goat and it might make it easier to identify places for change / improvement. A bad team will lead to the same level of underperformance, but the solution will not be as straightforward. After all, the road to hell is paved with good intentions, and each project individual contributor would be equally guilty (or equally not guilty) of the project's woes.

But shouldn't teams, aided by the right agile ceremonies (such as post mortem sprint reviews), be able to identify problems and correct them? From my experience, no. The team view point / collective bias will permeate those ceremonies, obscuring issues that are outside that view point or that are taboo to discuss. Not often would sprint reviews point out the tendency of technical project participants to reserve too much time for dealing with technical debt. Most often than not, the issue that are brought up are short sighted in nature. Retrospectives are very good at optimizing things such as communication and collaboration, but not necessarily collective decision making. Improving the latter usually relies on project participants self censoring or, conversely, picking up more responsibility when needed (kanban style). If the teams didn't start with this capital, retrospectives and continuous improvement efforts is not going to help.

I can also venture another opinion. I think that a good project manager is easier to find than a good Scrum team. Teams are often assembled by constraints that are not correlated with optimization. More often than not teams are assembled from stakeholders who have availability, not necessarily the people who have complementary skill sets or who have worked well together in the past or who have the best understanding of the domain at stake. While the likelihood of this occurring is the same under classic vs. agile frameworks, the deficiencies of an unbalanced team are magnified in agile. On the flip side, a good project manager will help minimize those deficiencies. But wait, shouldn't the scrum master remove impediments and make sure that the team is running smoothly? Yes, except that removing impediments when the team structure is the impediment is close to impossible. A scrum master is not empowered to control that aspect of the project in the same way a conventional project manager is. Furthermore, a scrum master might not feel like it's her job to do so, not without upsetting team equilibrium, and in the process reverting to a staggered project hierarchy.