This was originally published May, 2017
Note: This blog assumes the reader understands the basic roles and practices of Scrum.
Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (product owner, team, Scrum Master) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an inspect and adapt approach that requires little understanding of the underlying laws of software development other than an acknowledgement that reducing the time for feedback is essential and that small batches are better than large ones.
Coinciding with the “follow the framework and remove anything impeding its adoption” approach is the promoting of Shu Ha Ri as a way of learning. Shu Ha Ri proposes three phases of learning:
- Shu – one of following, without variation, the practices a master sets forth.
- Ha – Only after competency in these basic practices can one vary them based on principles learned
- Ri – go beyond the practices entirely and use one’s own judgment.
The use of Shu Ha Ri in Agile was first introduced by Alistair Cockburn. But many people forget that Alistair was the creator of the Crystal Methodology that enabled you to apply an approach that was appropriate for the team or company adopting Agile. In the situation where someone with experience has determined the correct approach may work. Even then it has dangers in that Shu Ha Ri comes from the martial arts and in that context disengaging the mind is required for the body to learn first, then adjust with the mind. In knowledge work the mind always has to be engaged. Agile uses Shu Ha Ri a bit differently in the martial arts in that it does encourage thinking about what you are doing and how well you are doing it. Inspect and adapt is a cornerstone of Agile in general and Scrum in particular. This has us thinking about are we doing it correctly. We also need to think about if what we are doing is the right thing to be doing.
Endorsing a simple framework and saying “follow it until you get it to work” is appealing in its simplicity. However, it has some serious consequences when Scrum’s roles and practices aren’t economically feasible and there are better alternative roles and or practices for the team adopting Scrum. In this situation, the impediment shouldn’t be removed. Instead, these alternatives, that better meets of the objective of the impeded Scrum role/practice should be adopted. It would be nice if the Scrum framework was universally applicable but reality shows that it is not.
The challenge is that it is difficult for a new team adopting Scrum to tell if their impediments are something to overcome or something providing evidence that they should adopt different roles and/or practices. Without guidance, teams tend to just abandon the impeded role or practice in frustration. Scrum proponents tend to just shrug off this widespread behavior as “bad Scrum” or “Scrum-but” (that is, “we use Scrum but we don’t follow <include practice being abandoned here>). Many people talk about software development as a complex system but then ignore that a framework being adopted is now part of the system. The framework must account for the changes it will introduce to the people adopting it.
It is important to remember that Scrum was inspired by an article on how to do product development, not operations or maintenance. In that article, the presupposition was that a team building a product already existed and it was suggesting how they worked together. Scrum can be a good approach for teams in this situation as a place to start. Even then we strongly advise the adoption of several Lean principles such as visibility, explicit workflow and managing work in process (WIP).
No One-Size Fits All
To suggest that Scrum is universally applicable ignores the reality of experience over the last 20 years since it has been adopted. Note, I am not attacking Scrum here no more than I would be attacking a hammer because it’s not good to screw in screws or attacking a plier because it’s not good as a hammer. Scrum should be thought of as one of many tools available to people. It often is the best way to begin Agile at the team level. But to suggest that people adopting Agile should always follow Scrum’s core roles and practices without variation ignores the reality of complex systems. While proponents of Scrum will suggest Scrum is flexible because one can add anything they like to it, the framework itself is not flexible – teams must abide by the framework’s roles and practices.
Unfortunately, this combination of a belief in universal applicability and Shu-Ha-Ri makes for a dangerous combination when the assumption of universal applicability is not justified. In this case, teams may be encouraged to follow roles and practices of the framework by rote when they should be finding alternatives to them.
It’s not just that Scrum, as a whole, is not universally applicable (there is no one-size fits all) but none of its practices or roles are universally applicable. To be clear, this doesn’t mean Agile isn’t always appropriate, it’s just that Scrum may not be the right approach to take. Let’s consider a couple of key Scrum practices to illustrate this.
Cross-functional teams. Having co-located, cross-functional teams working from one set of requirements, has been demonstrated to create a 3-10 times improvement over a group of people who are not co-located and working on several projects (see Why Scrum Works and How This Tells Us When It Won’t). There is no question that having cross-functional teams is a good thing when economically feasible. But very often they are not.
One case I ironically encountered on my first coaching gig with a Scrum team was having 10 metallurgists supporting 100 teams. These metallurgists were very expensive (they were PhDs with a minimum of 8 years of experience). There was no need to hire 90 more metallurgists since they only required about 10% of their time to support each team. Other, more common cases of difficulty of achieving cross-functional teams, is having enough subject matter experts (SMEs) with years of experience or a team-member who was around when the original system was written. The point is that cross-training is often not financially viable or even possible. The bottom line is if there are other ways to achieve results close to that of a cross-functional team, the lower costs may make them more viable options. This is why understanding of why Scrum works right from the beginning is so important (see earlier reference).
Time-boxing. Time boxing is useful when teams need the discipline it provides. However, if the team is doing work that can’t be planned for, e.g., maintenance or shared services, it may not be the appropriate set of team practices to use. Kanban is likely more appropriate.
However, one should not just stop doing time-boxing. One must one understand alternative ways to achieve that objectives of time-boxing and implement them (see The Objective of Time-Boxing).
In Summary, Scrum + Shu Ha Ri = Danger at Times
If one is adopting Scrum in a place where some of its roles and practices aren’t appropriate, Shu Ha Ri will push the team down a path without looking for better alternatives. They are likely to just abandon a practice in frustration and head down the path to “Scrum-But.” In fact, much of the bad Kanban we see is really bad Scrum without iterations being called Kanban. As I wrote in The Question Isn’t ”Scrum vs Kanban?” or Even “Scrum and Kanban?” But Rather “What Works?” (sorry these posts are in limbo and will be restored soon). we should not be looking at either Scrum or Kanban as an answer, but rather as fertile territory for ideas to adopt. At Net Objectives we teach an approach we call Team-Agility because we don’t believe in being focused on an approach but rather what works.
For more information, see The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka, 1986.
CEO, Net Objectives