Agile project management allows you to produce smaller deliverables more frequently and efficiently, making it an excellent choice for teams that work in product development, programming, business analysis, and other collaborative areas. But it's a fragile process that requires the right scope, goals, and management. In this course, we show…
The conversation goes on in the Scrum and Agile circles about how far a team can stray from the hard and fast “Rules of Scrum” before becoming a “Scrum Outcast” and … earning the derision and scorn of the “True Believers.” But there is something about the stasis of staying the same and always playing by those rules that might bother some people.
Here are some thoughts on the concept of keeping to the rules or improving out of them.
The Rules Of Scrum
Scrum, despite its definition by Ken Schwaber and Jeff Sutherland as “a framework for developing and sustaining complex products” , has a distinct set of rules. Unbreakable rules. In fact, the subtitle of the Scrum Guide from which that definition is taken is “The Definitive Guide to Scrum: The Rules of the Game.
The rules are what make Scrum, Scrum. If you don’t follow the rules you are not doing Scrum.
Now this is not a consideration uniquely tied to Scrum. If you want to play chess, you follow the rules of the pieces (the way they move), the board (8 x 8), and the other rules of the game. If you want to do something else (say, introduce a new piece, for example, the “jester” (moves 2 up, 2 over, and the player has to tell a joke) then you are no longer playing chess. There are many variations of a game with balls, bats, bases, and players, but there is only one set of rules governing baseball. And so forth.
Each of the agile approaches has rules. Extreme Programming (XP) has its Twelve Principles which establish the rules for XP. If you do not follow all twelve of the Principles, you are not doing XP. Feature Driven Development (FDD) has its processes. And so on.
The concerns of the Scrum elite are valid. They are trying to make sure that teams that only follow some of the Scrum rules and not others, and fail, do not blame Scrum for the failure. In other words, the belief is that if you follow Scrum exactly as it is defined in the rules of Scrum, the software development (or the product development) effort will be successful. If not successful, the rules were not followed, in the form of software development called “Scrumbut” (“we are doing Scrum, but [specify some rule that is not followed. e.g. we still have a project manager] ).
When asked if Scrum can be performed without various of the defined components, such as having a Scrum Master, or daily stand-ups, or a retrospective, the Scrum community is fairly unanimous is saying, “no.”
Here are some random comments from the Yahoo Scrum Development Group and the LinkedIn Agile and Lean Software development Group over the past several years.
When asked if it were possible to “do Scrum” without Scrum Master (names withheld):
“No, it is not possible to have Scrum without Scrum Master. Have a great day.”
“You can still go and do the development work without a Scrum Master, but you can’t call that Scrum.”
“If you do not have a Scrum Master on your team, you are not doing Scrum. If you do not have two bishops at the start of a chess game, you are not playing chess.”
Similar responses applied to doing Scrum without a standup and without a formal end of sprint retrospective: “It’s not Scrum, it’s Scrumbut.” So changing the rules should be avoided since no one likes to be called a “but” especially a “Scrumbut.”
What If The Rules Stop Applying?
But what happens when the team or the players find the rules constraining or restricting or decidedly non-Agile?
Is that possible?
The team had been together over three years, using Scrum as their software development approach. They were by any measure a performing team under the Tuckman model. They regularly made all their sprint commitments and performed at a high velocity especially when compared to the other Scrum teams in the department.
Over the years, in their quest for continual process improvement, they made a number of changes which affected the basic tenets of Scrum.
Because they were co-located and talked among themselves continually, they decided that their Daily Stand Up was redundant. At the Stand Up, they retold what everyone already knew from the day before. Basically, they all knew what each other was doing. They said that they didn’t miss the Stand Ups and liked the extra fifteen minutes a day the got by not having it.
They also decided that waiting until the end of the Sprint to review what they were doing was too late, making the Retrospective also redundant. They were making changes during the Sprint and adjusting and having ad hoc meetings to address issues. The Retrospective had become a review of what already happened and a waste of time.
They eliminated it.
Finally, they realized they were able to deal with all the obstacles and impediments themselves. They didn’t need to go to a Scrum Master to act as an intermediary. They ran their own Sprint Planning Sessions, and Reviews with the Product owner and they certainly needed no further instruction on how Scrum works.
Since they were functioning as a high performing team, they also worked out all their issues among themselves. They suggested that the Scrum Master could better spend his time with other teams. The Scrum Master did. (I talked to the Scrum Master, who voiced no feeling of failure or resentment at being relieved of his duties. He had more of a sense of a parent watching the child graduate from college and enter the workforce on his own. He expressed that he hoped other teams would ask that he be removed.)
Their velocity and output continued to be high in terms of both quantity and quality. But they were not doing Scrum because they were not following the Rules of Scrum. And this is all right. Certainly, the team was not concerned about labels and in any case they still assumed they were doing Scrum. The Scrum Sheriff had not arrived in town as yet to tell them to cease and desist.
First Follow All The Rules
You have to follow the rules because you need a baseline from which to evolve. Otherwise, how would you know you have improved? To paraphrase the comment from Seneca, how are you going to know the direction you want to take if you don’t have a point to start from?
If you improve your process and change one of the rules of Scrum to make it better for you, then you are no longer doing Scrum. You can call it something else. Maybe Cricket or NuScrum or Murcs (Scrum spelled backward).
What Do You Call It?
So if it is not Scrum then what is it? We can probably call the process whatever we want. The team mentioned above had just such a discussion. One suggestion was to call it “Elvis” (from an Elvis fan) because “We’re fast and we rock.” Other suggestions included “Super Scrum” (with appropriate uniforms), “Uber Scrum,” “Scrumptious,” and, of course, “Over Scrum” which the team member highlighted the double entendre by stating, “We are so over Scrum.”
What was their final answer? What did they answer when other developers or management asked them what they were doing? What did they finally end up calling their approach?
Nothing. They decided that they didn’t need a name. Or a title. Or an “Agile approach.” They decided that they didn’t even need to call themselves “Agile.” They were simply developing software the best way they knew how. And that was enough for them.
Agile Is Not About Developing Software Or Product
Maybe we have it wrong. Maybe “Agile” is not about better ways to develop software. Maybe Scrum isn’t really a “product development framework.” Maybe Agile is a way to get a group of software developers together and work as a team and then as a high functioning team. Maybe software development is just what is done while the team is forming and performing. All of the practices and indications of Agile, from pair programming to the Scrum Master, to collective ownership of code, and so forth seem to be about improving the collaboration of the team as much as producing software.
Perhaps if we view “Agile” as a team development method rather than a software development approach, all the issues with being one approach or another start fading away. When the focus is on developing a high-performance team, backlogs, refactoring, having only three roles, Feature Lists, prototyping sessions, and all the rest become methods and techniques for developing the high-performance team.
In the public school system in the US during the 1950s (I don’t know how long it continued) a graduation ceremony was held when the children moved from kindergarten to first grade of elementary school. I have an old photograph of myself graduating from kindergarten, passed on to my wife from my mother. In sepia tones, I am standing in front of a school wall replete with suspenders (the dress of the day), mortar board and some kind of certificate in my hand.
Am I suggesting that Scrum is like kindergarten? In a way.
Just as Robert Fulghum said, “All I really need to know (about life) I learned in kindergarten” so we might say about Scrum: “All we need to know to be a highly productive software development team we learn in Scrum.”
Just as in kindergarten and throughout all school, the ultimate goal is to learn something and to graduate. With Scrum (and with all Agile approaches) our goal is to learn something (especially about being in a team) and eventually to graduate from Scrum. And it doesn’t matter what we call the process we use after we “graduate” from Scrum. We can simply call it “Agile,”
Your goal should be to start with all the rules of Scrum so that you are doing Scrum and then improve to the point where you are not doing Scrum and graduate to something better: your team’s own software development process.
As Tobias Meyer once said,” the ultimate goal of Scrum is to eventually stop using Scrum.”
Author: Steve Blais
Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development. He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.