Monday, 14 November 2016 13:59

We are So Over Scrum

Written by
Rate this item
(6 votes)

The question goes on in the Scrum and Agile circles about how far a team can stray from the 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” [1], 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?

Example:

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.

Graduation Time

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.”

[1] Schwaber and Sutherland, The Scrum Guide, July 2016, Scrum.Org and Scrum Inc.

Read 8600 times
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.

Comments  

0 # Eric Naiburg 2016-11-17 09:21
Hence why Scrum is empirical, you learn, adjust, adapt and keep adapting as you learn... As you wrote, it is a framework for such empiricism. BTW, there is no Daily Standup in Scrum, there is however a Daily Scrum. I know semantics, but it is important to speak the same language as an organization and no, you don't have to stand up :-) There is also nothing in Scrum that says you shouldn't meet and adapt mid Sprint, as a matter of fact, it is recommended to do refinement and keep moving forward throughout a Sprint. The Sprint Review however is quite important to ensure that you as a team are meeting your definition of Done and actually delivering at least 1 increment. It also doesn't mean you cannot deliver continuously throughout the Sprint. A good Scrum Master gets out of the way and doesn't have to be overly involved, but having someone who can help resolve conflict, keep distractions away from the team at least at the start is important, but over time, their role should diminish as you state. I agree, don't be a purist for purist sake, but learn and adapt and adapt and learn...
Reply | Reply with quote | Quote
0 # steve 2016-11-26 07:20
Thanks for the comment, Eric, and good point about the Stand up. The team called it the Daily Stand Up. I wonder where the concept of standing up came into the lexicon?
Reply | Reply with quote | Quote
0 # Doug Goldberg 2016-11-17 13:16
THanks for a great write-up Steve. I've recently started working with a Scrum team that wasn't doing Scrum according to guiding principles, and the immediate tendency is already to revert to known habits and chiseling away at the structure. You've articulated well the "walk before you run" approach and the value obtained from the discipline. I especially like the referenced team's ability to step back and recognize their lessons learned and apply them to fullest ability. Thank you again!
Reply | Reply with quote | Quote
0 # steve 2016-11-26 07:28
Thanks for your comment, Doug
Reply | Reply with quote | Quote
0 # Scot Witt 2016-11-17 14:26
I don't know about the rest of the BA/PM community, but I'm really getting frustrated with people and all the consulting firms who have an incentive to rebrand Agile into their own image.

The fact is, none of these are separate methods, they are all tools. And each team adapts its tools for increase ease of use and productivity gains. Period.

We need not forget that "Agile is Practical." Hence the wide variety of consulting jargon- to amaze and throw smoke and mirrors before our teams.

We must always adjust, we are spending way, way too much time on method- method produces nothing and is often an annoyance to the business and the team.

Get valkue into the hands of the business as quickly as possible using tests to drive the work.
Reply | Reply with quote | Quote
0 # steve 2016-11-26 07:29
Thanks, Scot. In the end, being agile takes a will and a lot of discipline. Too many teams bail out at the first signs of failure because the "method" doesn't seem to be working.
Reply | Reply with quote | Quote
0 # Alex 2016-11-17 16:14
Could not agree more. No framework is perfect, but at least it is a starting point. You learn and improve. You take with you the best elements or the elements that work best for you.
Very well written Steve.
Reply | Reply with quote | Quote
0 # steve 2016-11-26 07:30
Thanks, Alex
Reply | Reply with quote | Quote
0 # Nancy Hannon 2016-11-18 08:42
Some development managers would not agree, and insist that all the teams follow "the rules of scrum" and that the Scrum Master's job is to insure this. No Scrum Team is perfect, but a scrum master who spends their time trying to make the team conform to the rules can be counter-product ive. The best SMs (and I have worked with a few) help the team evolve and become self-sufficient ; they steer the team but do not dictate the route they must take. The end result is that the team starts focusing on delivering value and staying on schedule - isn't that what management really wants?
Reply | Reply with quote | Quote
+1 # steve 2016-11-26 07:35
Some managers, and management layers, believe that they are doing things right by following the "rules" whatever the "rules" may be. If they follow the "rules" they cannot be faulted; they cannot get into trouble.
following the "rules" becomes more important than getting the job done right. Agile philosophy is somewhat anti-"rules" in that if focuses insted on "getting it right" and then changing it as needed to achieve the goals of the organization. Thanks for your comment, Nancy
Reply | Reply with quote | Quote
0 # Duane Banks 2016-11-18 12:34
Well said, Steve!
Reply | Reply with quote | Quote
0 # steve 2016-11-26 07:26
Thanks, Duane. Good to hear from you.
Reply | Reply with quote | Quote
0 # Etienne 2016-11-24 21:58
Agile can be achieved without scrum, to deliver value to stakeholders using kan bank. Little to no rituals, yet effective visibility and ability to track progress
Reply | Reply with quote | Quote
0 # steve 2016-11-26 07:37
A team can follow Kanban and still continue to improve until they eclipse even the "rules" of Kanban. Thanks, Etienne
Reply | Reply with quote | Quote
0 # Dave 2016-12-08 12:12
thanks for writing this.


http://davidayikuvidaz.blogspot.com/
Reply | Reply with quote | Quote

Add comment

Security code
Refresh

search Articles

© BA Times.com 2016

DBC canada 250