Your favorite Scrum deviations. Share them here!

#1

One of my best performing teams, we stopped breaking stories down into tasks because we were able to get them small enough in refinement that they started seeing it as not necessary to spend time doing the task break down. They would plan how they would attack each story at sprint planning and have an idea and then throughout the day communicate on who would work on what. They did a lot of pairing and some mob programming throughout the sprint. We also used a kanban board with stories and not a traditional scrum board because we had no tasks on the board. We also stopped caring about hours burn down and just kept a story burn down as an information radiator. Other than that it was standard scrum ceremonies and roles but that one deviation really worked well for that team.

In our retros we always looked at cycle time and cumulative flow to improve for the next sprint. IMO combining scrum ceremonies, roles and time boxed commitments with kanban based flow and XP practices was highly effective.

Anyway, if you are have used scrum what are the deviations (from OTB scrum) that have worked the best for you?

#2

Love this thread @troy! Really like the mashup of metrics you mention and I’ve seen a ton of value in blending scrum ceremonies with a kanban flow.

I’ve been encouraging teams to write their own user stories and have the product owner sign off. The PO brings a problem statement (at the EPIC level) to the team and the team figures out the “HOW.” I think this gets them more engaged in the solutions and give us better story coverage from the beginning.

#3

I think that model lends its self extremely well with high functioning Kanban teams. I am a bit hesitant with new teams or teams that rely on Scrum for structure because it starts abstracting value pretty far and in these scenarios value is generally poorly understood or measured.

#4

I had a program that had 9 relationship managers that owned their client products end to end. Each relationship manager had anywhere from 2-4 clients. Each client had a unique customer application (similar functionalities, but separate codebase and database).
When standing up the teams, there was only 14 developers and 6 testers. They supported roughly 30 custom applications from windows mobile 6.5, iOS, android, and webapp reporting.
DEVATION: 3 scrum teams with 3 product owners on each team with their own clients.

We had to do a lot of coaching and trust building with the POs to manage a team backlog with sometimes 12 clients of work, but they made it work. The POs had a client priority order, had regular stand ups among themselves to prioritize work, and overcommunicated anything going on to avoid confusion or conflicting backlog priorities.
It was probably one of the most eye opening moments seeing the POs coordinate and self organize like they did. They made a ton of custom Jira board and filters to allow the right views to prioritize their work, then had an overall team board they collaborated on the prioritize the team view so they did not feel confused. They also managed their “client WIP” to make sure the team wasn’t sporadically working on 6 clients in a sprint.

#5

Aren’t the most popular deviations more accepted practices now like Scrumban or Lean Kanban? Or a combination of the two? Or am I overthinking it a bit?

#6

I have a team working in a very similar way you are describing - even though they still do tasks, but that’s more for addressing and tracking risks from the implementation.

We have established planning on Epic level on top. No estimation of story points either. Instead we put our ambition in place when Epics should be out of the way. This creates a great link into the definition of a MVP either.

It’s the most flexible, reliable, and effective team I ever had.

#7

There’s no deviation from the Scrum framework in many of the items stated: no tasks, not using hours, no burndown chart, no Scrum board, Product Backlog items created by others. These are all simply techniques which may be used (or not) within the framework. That is the power of flexibility in Scrum.

“Although implementing only parts of Scrum is possible, the result is not Scrum.” Once one actually deviates (violates) the framework, then it is no longer Scrum. Perhaps it should be referred to ad Scrum-based to be descriptive and transparent.

#8

OpenAgile is an interesting deviation. The literature isn’t well-curated or well-kept but a lot of wisdom is still held by a few key people.

The key adaptations include:

  • Introduction of a ‘calendar’. Scrum has no calendar and therefore has no mechanism for scheduling work items beyond the current Sprint. OpenAgile introduces “Calendar Item” as a type of task.
  • Cycles can be longer than 1 month and the purpose of each cycle is not to produce “Potentially Releasable Product Increment” but to produce “a business goal”. This makes OpenAgile appropriate for executive/leadership teams whose work is often portfolio prioritization, organizational change, and smooth operation of the company.
  • The roles of Scrum are omitted. Instead, OpenAgile describes 3 “paths of service” – these are ways in which any team member can serve the team. Team members can serve as contributors (“Team Members”), or through Process Facilitation, or through Growth Facilitation.
  • OpenAgile identifies itself as a framework for continuous learning. (While Scrum identifies itself as a framework for addressing complex, adaptive problems and Product Development.)

I have borrowed a lot from OpenAgile to develop curriculum, organize not-for-profit groups, and consult with leadership teams.

#9

Also, I consider Kanban to be a deviation of Scrum in which a team is focused on service delivery rather than Product Development. I know Mr. Anderson wouldn’t like to hear me say it … but Scrum with W.I.P. limits, and without “Sprints”, looks and feels a lot like textbook Kanban.

#10

@David certainly it can feel like that at times but I’m not sure I would 100 percent agree. We had a recent podcast on Kanban that lays out more of the stuff.

The term “deviation” is an interesting word to use in this discussion because I struggle with how to apply it to Agile frameworks and ideas. Scrum is Scrum and you can deviate from it, but some would want one to not call it Scrum in that instance. Same can be said for SAFe, Kanban, Lean Startup, etc.

I go back to the famous Mike Cohn conference video where he said, “everybody does Scrumbut, why are we beating each other up about it?” I’m not one to advocate for one approach over the other, but I do find it challenging to discuss “deviation” because I wonder why they choose to do it and what is the advantage.

Most have good intentions, but I wonder if I’m okay with it. I vasilate all the time on it. Make sense?

#11

Hi Chris,

To your point, it’s probably best to never 100% agree. :sunglasses:

Seriously though: I’m very comfortable with the term ‘deviation’. Deviation is an essential facet of innovation. I’m reminded of one of Zappa’s infamous quotes: “Without deviation from the norm, progress is not possible.”

Having said that, I also appreciate the end note in the Scrum Guide where the authors simply say: “Scrum is immutable.”

How to reconcile these two contrasting ideas?

It’s important to be reminded that the authors of Scrum are not saying, “don’t deviate”. Rather, they’re politely asking us to respect the definition of Scrum as if to say, “If the way you work resembles this definition, then call your work Scrum; if the way you work does not resemble this definition, call it something else. If you want the results of Scrum, use Scrum. If you have discovered a deviation from Scrum which produces better results…great!”

I’m a huge advocate of Scrum. I teach it. I practice it. I believe it has helped thousands of organizations to improve. And I assert it ought to be a goal for some – that is, until they have uncovered every possible iota of wisdom from it and then they’d best deviate from it in the pursuit of even greater adaptability.

Good chat. Thanks!

#12

Couldn’t agree more Dave!

#13

WIP limits, no estimates (just story count), custom columns (but I don’t think that’s really a deviation from the guide; haven’t reviewed it in a while).

#14

We don’t do tasks. Not for any real reason, but because we never have. I’m not keen to reintroduce them, we are working on making any given story fit no more of three days of work.

We do use points to estimate, but they are limited to 1,3,5 and are called small, medium and large so that our PO has an idea of the work, but things that are bigger than 3 days are looked at in terms of how we think we can split the story further.

I think it is about communication. We are definitely a work in progress, and heck maybe one day we will get it right.