Training in Scrum/ATDD
Note that Net Objectives prefers their clients to use Team Agility. However, since many 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.
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.
Before adopting Scrum, it is important to ask if Scrum is applicable to your team. If it is, use it as is until you start running into challenges. Then, adjust the practices as necessary but in a way that achieves the intentions of the practices (one cannot merely abandon Scrum’s practices and expect an improvement).
As with any approach, Scrum should not be used as a one-sized fits all. Abraham Maslow observed,
Scrum was designed for a team working on a project/product. Its inspiration lies in The New New Product Development Game which we highly recommend reading whether you are doing Scrum or not.
Deciding whether to use Scrum should be a two-step process. The first is if it is generally applicable – that is, you have a team working on a project. This enables the potential use of the core Scrum practices of the sprint and cross-functional team. The second is if the framework fits your culture.
Step 1: Is there a fit?
Can the team considering it’s adoption it plan ahead? Several types of teams can’t plan ahead. These include certain shared services teams and maintenance teams. In this case a flow model, such as Team Agility or Kanban, is more desirable.
Are cross-functional teams possible and financially desirable? Even if you don’t have cross-functional teams, you can likely make them more cross-functional than they currently are. In any event, people who are needed for more than one team can either be shared or have their own kanban board to manage the demand for them.
Trying to apply Scrum to organizations where these conditions don’t apply means that the organization must change to fit Scrum. This is sometimes a good thing and sometimes there are better ways to achieve agility. One shouldn’t be looking for change itself, but rather one should be looking for what works. Remember, different is not always better but better is always different.
In tabular form:
Step 2: If there is a fit do we want to use Scrum?
When you have cross-functional (or at least semi-cross-functional) teams that can plan their work Scrum is often a good fit. This is the situation for most teams. But the compelling reason to use Scrum has to do with whether it’s a good fit for the organization’s culture and level of team discipline.
One challenge with fitting a culture is if people are attached to the labels of their job description. Many companies don’t have career paths for ScrumMasters or developers (i.e., not differentiating between programmers and testers). However, this isn’t a big problem – just keep your old titles. A compelling reason to use Scrum is often if there is a strong need for breaking work down into smaller pieces. Scrum forces this with its time-boxed sprints. Some people believe Scrum is a requirement if you want to be able to calculate velocity, but Kanban allows for the through its use of cadence as well as Scrum (see Creating the Beat for the 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 BDD 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?”
A formalized way of doing this is to ask the following:
According to the Scrum guide:
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.
The first step of course is to see if Scrum is applicable for your team. If it isn’t, then consider using Team Agility instead. If you want to improve your current approach by improving the practices you are following, then continue reading.
After starting and using Scrum as Example for a while, you will likely run into challenges. When you do, apply the four step question process mentioned earlier to find alternative practices, roles and or artifacts to Scrum’s core framework:
There is no definitive set of alternative practices to Scrum. That is the entire point. But it is worth investigating a few of them to illustrate how Scrum by Example can be used.
No one practice fits everywhere. To look at alternatives to existing practices, we’ll go through the key practices of Scrum, see what the intentions of using them are and then mention alternative methods of achieving those intentions. We won’t cover all of the practices of Scrum but will discuss most of those Scrum practices that either don’t always apply or are often misused.
Too often, people say, “Oh, we do Scrum but we don’t do…”.
We call this “Scrum-but.” Scrum-but is usually used as a derogatory term. But in fact, most teams should be doing one or more practices differently. The challenge is Scrum doesn’t tell us how to do this, but rather insists we stick with its practices.
While “Scrum-but” is a bad thing if people just abandon practices, it can be a good thing if they substitute the abandoned practice with one that fits better for the team. To do this we need to understand what the intention of the practice is. Let’s go through each of those mentioned above.
I will be making a template for how to move from a Scrum practice to a better one and let folks fill things in themselves.
Here is a list of practices. It will grow with alternatives given as time goes on.
There are several practices that all teams, regardless of approach, should be doing. Several of these are not part of Scrum but can readily be added to it. These include:
Scrum as Example provides just as explicit a starting point as Scrum is defined now. One can even use these decisions to define Scrum. However, it also provides a way for people to adopt different approaches without losing the intent of what is needed. Teams focus on their objectives not following a mandated solution. As they learn, they can make up their own solutions if they better achieve the objective.
If you want to learn more about why Scrum as Example is so important, see this linked in post Going beyond Scrum to Scrum as Example.