kHUB All Member Forum

I often read through the passionate LinkedIn debates about whether Scrum has been successful. My observation is that much of the disagreement is based on the different environments in which Scrum is applied. My conclusion is that nobody’s wrong. I assert that your perspective on Agile success depends on three characteristics of your organization:

1. Modularity – The degree to which functionality can be added or changed by independent Agile teams.
2. Familiarity – The extent to which the Agile teams are familiar with the domain.
3. Flexibility – The degree to which Agile teams can vary scope and/or schedule to incorporate evolving requirements and user feedback.

Modularity allows individual Agile teams to produce meaningful and demonstratable functionality within Sprints. Development complexity grows exponentially when implementation of functionality involves multiple developers with unique skills across multiple teams.

Agile requirements challenges are greatly diminished when developers understand what they are building. As we know, the Product Owner role is one of the biggest challenges in Agile development. See my article “The Product Owner is a Unicorn.” However, Agile teams with a good understanding of the domain can work around product owner deficiencies. For example, development of music streaming applications like Spotify is very different from that of a regulated medical device company. This is why so many companies have failed to duplicate the Spotify model.

Flexibility is the characteristic that can rule out “real” Scrum. Waterfall release planning at the feature level persists, leaving teams with no time to iterate functionality based on evolving requirements and demonstration feedback – basic tenets of Scrum!  Flexibility goes out the window in organizations that are driven by sales departments to achieve short-term income commitments. See “When Scrum is not Scrum.” Also, see my article “Why the Business Needs Predictability from Agile” to understand why most companies stick with Waterfall release planning.

One might think that we would see a uniform distribution of these characteristics in the software industry. However, the characteristics tend to be related, creating large concentrations at the ends of a spectrum.

Of course, there are those in-between, but I believe that most organizations debating the success of Scrum fall into one of these two classes. In terms of development staff, Class B companies comprise most of the software industry. One might argue that Agile scaling frameworks have addressed the problems of Class B companies. However, they just constrained Scrum by imposing a Waterfall planning wrapper around it.

These classifications explain the never-ending arguments about the success of Scrum. Don’t try preaching Scrum to a Class B company when your experience is from a Class A company. I see that many Agile coaches that come from Class A companies convince developers in Class B companies that the problems are all caused by idiot managers who can’t grasp the benefits of business agility. These coaches make no attempt to solve the predictability problem, repeating the simplistic refrain, “The business needs to be more agile.”

In any event, clarify your Scrum environment in terms of Modularity, Familiarity and Flexibility. Otherwise, the discussion is about apples and oranges. If you are from a Class B company frustrated by watching “Agile experts” from Class A companies tout the magic of Scrum, you can now recognize that you're not the problem.

My recognition that larger sales-driven companies have mostly been left out of the Scrum success story led to my book, “Unlocking Agile’s Missed Potential.” The Class B companies have never been doing real Agile development! My book introduces an Agile investment planning method to provide the flexibility necessary for Agile development while increasing financial predictability for the business. Don’t throw Scrum out the window when it hasn't actually being used in most organizations.