Is anyone doing Scrum?


#1

I have not met any team or anyone who knows of a team who has done scrum with all roles, artifacts, events, and rules. Given that the scrum guide explicitly says that you must implement all of them to result in Scrum, is or has anyone done Scrum sustained successfully over multiple releases?

From scrumguides.org:

Scrum is free and offered in this Guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.


#2

you’ve met one now. some details about our teams:

  • our teams are 5 to 8 in size and have all the skills necessary to deliver to production
  • across the 6 technical teams, we deploy to prod an average of 5 times a day
  • we have a PO dedicated to a single team, and all team members are also assigned to a single team
  • most SM have two teams they work with
  • our sprints are 2 weeks in length, and we have all ceremonies explained in the scrum guide
  • we decide on what to implement and not based on lean startup principles such as MVPs and a/b testing
  • i’ve been with the company for 2 years, and to my knowledge, they’ve been using all parts of the framework for the last 3 years
  • we still have a crap ton of problems so scrum is just the start and certainly not the end

#3

You have met the second one now :slight_smile:

Currently, I am working with a few teams who are doing Scrum and have adopted Scrum and staying true to the spirit of Scrum. I have been a ScrumMaster for several teams in the past 7-8 years and have seen that these teams have sustained and have been following Scrum successfully.

Some teams have been successful and some not very successful.

The teams who have failed were the ones who didn’t stay true to the spirit of Scrum, or have adopted Scrum partially or have develop anti-patterns while adopting Scrum. One of the other big factors was not having the management support.

The teams who were successful were the ones who follow the rules of the , frame-work, ensuring all the events (meetings) happen, artifacts are created and roles defined/followed.

In my experience, I felt that the organizations I worked with created a safe atmosphere for Scrum teams to thrive. The teams trusted each other and also followed the values of Scrum - Courage, Openness, Focus, Respect and Commitment.

As they say, Scrum is not a silver bullet or it’s not easy but if we stayed focused and inspected and adapted, teams will definitely be successful.


#4

That’s awesome! Sounds like you’re a high functioning team. Do you guys have estimates on your backlog items?


#5

Yes! We use the modified fibanocci sequence.


#6

Some in our org are high-performing teams; others struggle. However, I need to remind myself that’s relative. As a Marine, I’d look at some and think that at a 7:30 minute mile for 3 miles, they’re freakin’ slow. Comparing that same Marine to most civilians though, reminded me that wasn’t true. :wink:

We estimate in story points using planning poker. Some teams still struggle with mentally converting points to hours. Others are pros at the relativity of it and compare an unestimated story to something estimated in their backlog. I often remind them all though that it’s not the estimate that matters but the conversation of making the implicit explicit. I could really care less what estimate they arrived at. I only care that they can explain why they did.


#7

I like the analogy of running miles/minutes. I agree story points are conversation starters/enhancers. I like the 3 Cs formula that Ron Jeffries captures as part of a user story:

What fits on a 5x7 index card-

C- Card - Front side of the Card where the User Story is written,
C- Conversation - Discussing the user story whenever conversations have happened between people and
C- Confirmation - an acceptance criteria which is written on the back of the card

For more information on this - http://ronjeffries.com/xprog/articles/expcardconversationconfirmation/


#8

Would you say that the majority of the teams you’ve been with run Scrum as defined? We know scrum is simple to understand but difficult to master but wonder if there are any common areas we see teams struggle with.


#9

Here’s some common things I’ve seen with our teams:

  • Silos. Breaking those down and ensuring they stay down require constant attention.
  • Shifting priorities. Sometimes POs forgot the cost of changing their mind or waiting to make a decision after the last responsible moment. (I’ve come to call it the first irresponsible moment.) When I see they forget this cost, I gently remind them.
  • Poorly written stories. It’s easy to write stories about the team. They’re around you throughout the week. However, stories should be written from the customer’s perspective.
  • Ownership. It’s easy to talk about what others did that would help your team, but point the finger back at yourself. What can you do? How did you fail? We can’t control the actions of others, but we can control our own.

In fact, I wrote about much of this just last weekend in a blog post of mine: http://www.spikesandstories.com/is-mine-a-high-performing-team/


#10

I’ve been on XP teams that probably satisfied the rules of Scrum without identifying as such. I’ve never seen a team claiming to be doing Scrum that actually satisfied its rules. The most common discrepancies I’ve seen have been:

  1. Not delivering a potentially shippable increment at the end of the sprint.
  2. Having a role distinction between coders and testers on the team.

#2 is particularly interesting because it’s so common even though it’s the only thing in the entire Scrum Guide called out with “there are no exceptions to this rule.”

That said, I do think having an independent group of exploratory testers providing feedback on a shipped product (outside the sprint) is very likely a good idea. My interpretation of the Scrum rule is that tasks (inside the sprint) aren’t allowed to be earmarked as just for testers or just for coders or whatever.


#11

Remember that Scrum doesn’t specify any particular form of estimation. The only important detail that the Scrum Guide seems to call out is that any estimates that do occur are the responsibility of the Development Team, and no one else (such as the Product Owner, the Scrum Master, or anyone outside the Scrum Team) can provide them.


#12

There are a few things that teams struggle with and it’s always not easy when a team is stood up soon after a 2-day training session. Teams need to experiment and get to a stage of maturity after finding their rhythm. Scrum has events, roles, artifacts and rules. If there are any deficiencies in events, roles, artifacts and rules, the team will form habits may be anti-scrum.

Tanner’s list is good.

Some of the basic list of items I have seen in my experience under each of the areas listed below.

Events -

  1. Scrum Meetings are very important- for example, it’s important to have the daily Scrum every working day, at the same time and same place. Teams need to ensure they time-box it upto 15 minutes max. Other meetings should follow the rules and the Scrum Teams are responsible to make sure it happens.

  2. Artifacts like Product backlog needs to be current, prioritized and ordered so that the Team can have enough work for each Sprint.

  3. Roles like ScrumMaster - this should be just one person and shouldn’t handle multiple roles like developer and/or Product Owner. This will be counter intuitive.

  4. Rules of Scrum -

  • Every Sprint includes Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective,
  • Time-boxing of each of these meetings with suggested times must be followed
  • There is no break between each Sprint and every sprint is the same length.

There are many more that we can talk about but you get the idea…