Dysfunctions or true constraints?
Scrum is based on the lean concept of turning an idea into a feature as efficiently as possible. The Scrum framework is designed to surface obstacles that get in the way of delivering value. The game rules of Scrum are in place to protect the team from chaos so that they may finish their commitments for the customer by the end of a given sprint.
Because of the short cycle time and the relentless pursuit of identifying obstacles, there seems to be a never-ending list of challenges that the ScrumMaster needs to fix. The team surfaces—on a daily basis—any interruptions or impediments to their work. The product owner and other stakeholders inspect the product in the sprint review, which frequently leads to adaptations in product backlog and thus the evolution of the product. Finally, the retrospective provides time for the team to focus on process improvements so that the experience is smoother in the future. In conclusion, there are three built-in mechanisms in the Scrum framework for discovering obstacles. As they say in Texas, "If you go hunting for trouble, you'll sure find it." Scrum can feel very challenging because of what it brings to the surface.
So how do we handle these tough challenges as ScrumMasters? We have to ask ourselves: is this issue/challenge/hardship a constraint within our organization or is it a dysfunction? An example of a true constraint would be a document that must be written for U.S. Food and Drug Administration (FDA) compliance. The team mentioned it in retrospective because they think it's wasteful, but the product won't make it to market if it doesn't achieve FDA compliance. Therefore, it's a true constraint that must be worked around.
On the other hand, let's say that a team member mentions in the retrospective that he is being pulled away from the team to work on another project for a different manager. Is this a constraint? Maybe. But perhaps it's a dysfunction. Why? Well, Scrum says that team members are dedicated so that they can focus on and finish the functionality they've committed to implement. When a team member gets pulled onto another initiative, this makes for an unhappy developer who now must multitask and probably feels inadequate because the workload is too much to bear. It is likely that he or she won't finish either of the teams, commitments. Without finishing features, it's impossible to inspect and adapt, which breaks the benefit of empirical process control. This scenario is simply not acceptable; team members are not to be pulled from their teams. In this case, the ScrumMaster should alert the product owner that the developer's commitments are now in jeopardy. The situation may have to be escalated to managers to put a stop to this behavior. Eventually, team members must learn to say no, but that is not likely to happen in the beginning.
