Net Objectives supports both Scrum and a more refined Team Agile approach we call Team Agility. Since many companies have an investment in Scrum and want to continue to use it, we’ve created Scrum as Example. It allows for teams to continue using Scrum while greatly improving it.
‘Scrum as Example’ is intended for:
Scrum as Example provides a concrete, simple start while providing alternatives to the Scrum practices when they are needed. This enables just as simple a starting point as Scrum but informs teams how to adjust Scrum when they are ready for it. It is a way of thinking about Scrum as an example of how you can start but not as a prescription you must follow.
Scrum as Example provides guidance in the following ways:
These last two steps are very important. Scrum is based on the philosophy that if you can use its practices to remove impediments (step 3). But what do you do if you are having challenges doing so (step 4)? The fact that Scrum uncovers an impediment does not mean that you should use Scrum to remove the impediment.
Scrum as Example can be used as a method of teaching a team Scrum (“onboarding”) or to take a team doing Scrum poorly to improve (“level-up”). While you could think of Scrum as Example as a framework, it is more accurate to think of it as the set of practices, agreements and responsibilities that the team is using at the moment. They will adjust these as they learn. The focus must always be on improving methods and not on following a framework. The goal is not to be agile at the team-level but to achieve business agility across the organization. This manifests both individual and organizational purposes and creates a better place to work. Optimal teams without improvements to the organization is not that useful.
The power of Scrum as Example is that neither an organization nor any individual has to abandon what they know but can use their knowledge of Scrum as a starting point.
Scrum is a framework. While you are encouraged to add to the framework, certain practices of the framework are sacrosanct – and you are not supposed to change them. As with all frameworks this is to enable a well-defined starting point. People are then encouraged to extend the framework as needed. This is sometimes called going from Shu (following) to Ha (breaking with). These are the first two steps of Shu Ha Ri, an adoption metaphor from the martial arts popular in the Agile community.
The challenge is that starting with a set framework with core practices that you not supposed to change tends to have you stick with them longer than you should. Not all of Scrum’s practices are applicable everywhere. When a team is being led by someone with only Scrum certification, they may be reluctant to go away from Scrum because it has them go into territory in which they are not certified and may feel uncomfortable going outside of what they are certified in. This is human nature as Upton Sinclair observed, “It is difficult to get a man to understand something, when his salary depends upon his not understanding it!”
When and how to transcend Scrum is left unanswered by the Scrum Guide which repeatedly encourages following Scrum practices. If anyone does stop doing any of Scrum’s practices they are called “Scrum buts.” This lack of how to transcend is justified by the seemingly logical statement that “we need a well-defined set of practices; adding options will cause confusion.” But this is based on an unexplored assumption that options have to be confusing.
The answer is to not provide the options until after people have been trying use the practices for a little while and are now having some challenges with them. This is very consistent with learning theory. Let people struggle for a little while with new concepts but not for too long. In other words, giving options is not the problem; the challenge is knowing when to give the option.
If you want to learn more about the motivation of Scrum as Example read The Trap of Scrum.
Start with Scrum as a framework while including how to extend it when needed
The key is to think of any framework as a starting point. While frameworks allow you to add things to them, you often need to change the framework itself. Not all of the prescribed practices in Scrum, which one must do in order to be “doing Scrum” are optimal, or even possible, in all situations. Following a framework inherently focuses people on the framework and not on the real objectives at hand. Scrum as Example provides a well-defined, simple starting point but then allows for it to be adjusted after it has been used and the team has acquired both understanding of the approach and the challenges they are facing. This is the key Scrum as Example is as simple as Scrum at the start when it needs to be but enables better learning as people get more advanced.
According to the Scrum guide “Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk. Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.”
Surprisingly, no one seems to challenge that empiricism may not be the best way to base a framework on. As Edwards Deming says (paraphrased) “theory without experience is useless, experience without theory is expensive.” Although product development of any kind is complex and must be guided through feedback, it doesn’t mean the approach being followed shouldn’t have a set of laws that it attends to. In other words, in the same way one does not need a complex approach to address a complex problem one does not need an empirical approach to address an empirical problem.
This is perhaps the biggest difference between Scrum and Scrum as Example. Scrum as Example is based on the scientific method of making hypotheses, observations and adjusting the hypotheses to fit the data. But no belief or practice is sacrosanct. And deductive logic is encouraged while requiring the logic to be validated by experience. In addition, Scrum as Example takes a systems-thinking point of view. Two critical aspects of systems-thinking are that the system people are in significantly affects the behavior of the people and that parts of a system are interrelated to such an extent that the whole must be considered when making any adjustments to a part of the system.
Scrum is also based on the premise that if you change your organization to follow the Scrum framework, Scrum theory, and Scrum values, then your organization will improve.
We believe that if you can do this, your organization will improve. However, the cost of changing your organization may be higher and provide a lower return than taking another path that achieves the same objectives as Scrum but in a way that fits your organization better.
We believe the right approach is to make a decision as to when it’s more effective to change the organization to fit a framework or when to follow different practices (described below) that meet the same objectives of the framework more effectively and/or efficiently. Of course, this may take you out of the Scrum framework, so you’d no longer be doing Scrum. However, we don’t think this matters. We should remember that we should focus on our objective and not worry about the particular method of getting there
In the same way that engineering has laws (e.g., when building a bridge, we must attend to gravity, the elastic and compressive strength of our materials, and as we found out in Tacoma in 1945, the effects of wind). Some basic laws of software development we must attend to are:
This is, perhaps the biggest difference between Scrum and Scrum as Example. Scrum as Example is based on the scientific method of making hypotheses, observations and adjusting the hypotheses to fit the data. But no belief or practice is sacrosanct. And deductive logic is encouraged while requiring the logic to be validated by experience. In addition, Scrum as Example takes a systems-thinking point of view. Two critical aspects of systems-thinking are that the system people are in significantly affects the behavior of the people and that parts of a system are interrelated to such an extent that the whole must be considered when making any adjustments to a part of the system.
This section has its own page since it is referred to by several pages. See Is Scrum applicable for your team?.
After deciding that Scrum is applicable, the team can now start implementing it as close to its definition as possible. This lets them get a better understanding of both what Scrum is as well as the challenges they have in their organization. It also provides for a clear, well-defined start, something teams need.
Even when cross-functional teams are readily achievable and planning is possible most Scrum teams have two common challenges:
Breaking down stories into small chunks. Scrum intentionally provides no guidance here – it is a framework. Unfortunately, standard decomposition methods don’t take advantage of what’s been learned in the last decade with Behavior Driven Development (BDD). BDD provides a structure for decomposition that enables virtually any problem domain (including very complex ones such as operating systems and compilers) to be decomposed into small stories.
Having Something Demonstrable At the End of the Sprint. This challenge is related to the first. When teams can’t figure out how to get small stories, they tend to flow over into the next sprint. The value of having sprints degrades and teams often fall into abandoning them entirely – describing what they are doing as Kanban. This is, of course, neither Kanban nor Scrum – just bad Agile.
Because of these challenges, the best way to start with Scrum is with Scrum for the team training integrated with ATDD training.
The key after the start, however, is to provide the alternatives now that people what the intention of Scrum was. This requires that the people adopting the practices have been given the objective of the practice. At this point, with a little experience under their belt, a deeper set of options can be provided. The key here is not to abandon practices, but to find better ways of doing what you are doing, getting to the root cause of the issue (which may not be where the problem is showing up) or take on a new practice.
Scrum as Example is designed to help those doing Scrum to improve it and/or to transcend it.
Think of Scrum as Example as the top shelf of a large toolbox. Everything you need to start with is there. You only need to go into the larger part when one of the topmost tools is having a problem getting the job done. When a team is faced with a challenge in following Scrum, they go to the toolbox to ask, “What objective does this practice meet?”, “What decision have I made?”, and “Is there a better way to do this?”
While Scrum as Example says you can start with Scrum as a starting point and modify it later, it’s worth considering whether a practice should be changed upfront as well. See How to improve or change your practices.
Although Scrum as Example starts with Scrum, it should include a few basic practices that all Agile teams should be using.
This section has its own page since it is referred to by several pages. Please click on the title above before continuing.
Scrum as Example solves the dilemma that people want something specific to start with but no one size fits all approach works. Scrum as Example, therefore, provides Scrum Guide Scrum as a starting point but tells you what to do when certain practices become difficult. One doesn’t have to blindly follow Scrum but can use Lean-Thinking to provide better, more cost-effective practices to accomplish the intentions of Scrum.