Can you aim a silver bullet?

Can you aim a silver bullet?

Scrum is not a silver bullet.  Having observed the aftermaths of a number of  less than fully successful Scrum implementations, I have identified a few general problems that can plague Scrum implementations. But, none of these problems are insurmountable. Here are some pitfalls associated with Scrum implementations:

  • Over Selling:  IT departments are just as susceptible to silver bullet thinking as any other profession.  Examples include CASE (computer-aided software engineering), OO (object oriented design), CMMI (Capability Maturity Model Integration) and many others.  Each of these tools or techniques has delivered value to IT organizations, but none have been able to solve all IT’s problems.  In the marketing hype introducing the next big thing it is easy to forget that there is no one-size-fits-all solution to a problem.  The hype heaped on Agile in general and Scrum specifically can lead to excessive expectations that can’t be met.  Overly ambitious expectations leads to poor planning as organizations rush towards perceived value, attempting to implement Scrum without addressing organizational change or even without developing an initial backlog of the changes needed for the implementation. Implement Scrum with your eyes wide open. Get introduced to organizations that have made the shift and benchmark against them.  Implement Scrum using Scrum, embracing incrementalism and feedback loops. Finally, participate in the broader Scrum and Agile communities so that you hear the stories of successes and failures.
  • Organizational Design:  A related problem is that of organizational design. Scrum and most Agile frameworks leverage cross-functional teams as a delivery vehicle.  The formation of functional cross-functional, self-managed teams requires that an organization have a different perspective and different management structures than the classic matrix organization.  For example, in the classic matrix organization, when work is identified a team is assembled to address the work.  Different types of work require different capabilities; therefore the team changes to meet the work.  In a Scrum implementation, the work is brought to the team that has the capability to address business needs rather than creating teams to address the work.  Implementing Scrum (or any Agile framework) requires addressing organizational design by creating teams and then developing the self-knowledge need to understand each team’s capabilities, so that work can be fed to the teams rather than forming teams to address work.
  • Scaling: Scaling is the other oft mentioned problem with Scrum. Programs, because of their size, almost always cut across organizational boundaries. That can make communication difficult.  Communication difficulties are a reflection of problems scaling a framework.  The first tool for scaling is the Scrum-of-Scrums, which is a meeting much like the daily scrum between representatives from each Scrum team in a program.  I typically recommend that the frequency of the Scrum-of-Scrum meeting be driven by the current level of program risk (high risk equates to a more frequent meeting).  Other scaling techniques require tackling potentially difficult technological issues, such as ensuring that an integration environment exists so that the system can be assembled and tested at least daily (think of this as an overall daily build) or the acceptance of sprints dedicated to integrated testing.

Implementing Scrum requires hard decisions about how an organization is designed and how it will accept and perform work. Scrum works best when organizations embrace cross-functional teams and then provide technical environments where work can be assembled and tested on as nearly a continuous basis as possible.

Advertisements