You Suck and That Makes Me Sad - Ken Schwaber Quote

You Don’t Suck And That Makes Me Sad. Really.

---

CONSULTING | TRAINING

START | PRACTICE | COACH | LEAD

---

Some Context Around, “You Suck And That Makes Me Sad” By Ken Schwaber

The cartoon above depicts an old saying by Ken Schwaber (back when I took his original Certified Scrum Master certification over 18 years ago (I became a CSM in January of 2004)].

Time flies.

I have been a Certified Scrum Trainer with the Scrum Alliance since 2006.

In that time, I’ve traveled the world coaching, mentoring, and training teams around Implementing Scrum in the real world. I still do this today (although most of my time is now spent virtually coaching and mentoring these days, with a public training about once a month).

Also, if you have not seen these “Chicken and Pig” cartoons before, they are related to the site ImplementingScrum.com where I published ~ 100 cartoons about Implementing Scrum in the real world between 2006 - 2010ish.

As one of the benefits of taking a CSM Training with me [no matter how long ago, and I guess until I am six feet under lol], you get access to me on an ongoing basis.

I had a recent email thread between an attendee (from many years ago) that I received permission to share with you.

One of the reasons I want to share this with you is to remind you that YOU ARE NOT ALONE in the way you sometimes may feel when Implementing Scrum with your team, organization, or enterprise.

---

The Email Thread

Remember the usual threading of email - My “Response” is at the beginning and inline with the original questions…

Hi [name redacted for privacy],

Yes, you are an awful Scrum Master.

LOL NO YOU ARE NOT!!!!

I hope you are doing well and appreciate you writing to me yesterday; my apologies for the delay in responding to you.

“Officially”, there is not a requirement to track a burn down chart per the Scrum Guide.

Here is the only place “burn downs” are mentioned [copied from The Sprint in the Scrum Guide]:

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

OK… with that out of the way (smile)...

I’ve put some comments inline from your email below.

I’ve also included some links back to the definitions in the Scrum Guide.

I’ve included those not to be in “teaching mode” but to model how find some of the “answers” [and they may not agree with your current reality] per the Scrum Guide.

Let me know if you’d to chat (or schedule a quick call at calendar.mvizdos.com // give me a call at 262-MVIZDOS (if I don’t answer leave a message and I’ll call you back ASAP!)).

Thank you.

Michael Vizdos
Focus #deliver

—————

Hi Michael,

I hope you’re well.

I wanted to reach out to you about an Agile situation and see what you thought about it. It pertains to sprint burn downs.

We use Azure Dev Ops Boards for our scrum in a given sprint we could be doing research tasks, development tasks, infrastructure work, DBA work, testing tasks…etc.

What I’ve noticed in the past year and half doing Agile is that it really only makes sense for me to count development tasks towards our final burn down.

Is that crazy??

Each team I work with does this differently.

Does it “work” for your team (remember there are no Scrum Police)?

If things ARE working… don’t mess around with changing stuff.

I get the feeling that by you asking this, you are feeling it’s NOT working [saying this with deep empathy and understanding].

Development tasks are really the main tasks we estimate with regards to hours.

Testing tasks get a straight 1 hour across the board, and so do dev review tasks.

Gulp.

Getting a small bad gut feeling.

Remember it’s not individuals on a team delivering, it’s the Scrum Team.

Why is there a separation of “development” and “testing” — and, what value does it have for you to track the burn down at that level?

When I see this, an anti-pattern I recognize is that the poor testing resources [strike through that word] people get stuck getting the blame for “not finishing” because all of the tasks were waiting to be “tested” the night before the Sprint Review [and then the perceived solution is to then “add more testing resources” which only compounds the crazy and kicks the problem down the road piling on the technical debt].

Other tasks like DBA work, infrastructure work, testing, rely on people from other teams.

There are times when they cannot get to their tickets for one reason or another that I have no control over.

More eek.

The “other tasks” (from other teams) is another anti-pattern.

Yep, you don’t have any control over them [ugh, or really any output as I am always so humbly reminded in my life lol].

One of the things that will help ease that problem is to make sure that during Product Backlog Refinement you have those resources [strike through that word] people involved in the conversation to get stories “ready” for the upcoming Sprint(s).

And, during Sprint Planning, DO NOT pull a story into a Sprint unless the outside resource [strike that word] person has committed to getting that work done.

Amazing stuff happens when you do this. Think that one through a bit.

All that being said, if a testing ticket, or infrastructure ticket is not complete on the final day of the sprint, I either put it in the Backlog or move it to the next sprint and ensure hours are updated.

Recommendation:

Keep moving any “leftover” stories to the Product Backlog instead of sliding them to the next Sprint.

As you can probably recognize by now, just moving it to the next Sprint usually just builds more and more technical debt.

Just because a tool let’s you slide stories into the next Sprint (Jira and Azure seem to do this, huh) does not make it a good or even acceptable real world solution [besides allowing the tool vendors to make it “easier” to allow you to build technical debt].

Then I run my final burn down.

And then what do you do with that information?

Am I an awful Scrum Master?

Haha. Wanted to get your thoughts and make sure I’m not cheating the system here.

You are not awful.

Actually, you are doing an AWESOME job ASKING these questions.

It might be a good idea to chat with the Scrum Team (remember to include the Product Owner) in an upcoming Retrospective or even an informal lunch-and-learn.

One final resource I’d recommend is to read Ron Jeffries “Dark Scrum” (www.darkscrum.com) article.

It’ a few years old, but it spells out a lot of what you may be feeling / seeing AND gives recommendations as to how to help get the team out of that tailspin.

Hope this has helped.

Keep being awesome.

And, you are not “cheating" a system [remember that’s on the organization to reward for some strange things [like “how accurate are your estimates”] instead of focusing on delivering real value to your end users.

Would love to chat about a possible consulting arrangement (smile) — I want to put that out there as an option and, as you can see, I am here to help even without something formal.

You Suck And That Makes Me Sad - What Next?

Was this helpful? How can I help you NOT be that person who says, “You Suck And That Makes Me Sad”?

Does it seem similar to conversations you have had with your team (or inside your own head)?

Let me know your thoughts on this topic (or want some help with discussing some of these topics in your organization?).

Contact me (with feedback) or connect with me on LinkedIn to discuss this more together.

One final thing…

Subscribe to my weekly Saturday morning emails about Implementing Scrum in the real world. And get an “every two week” check in from me too.

What could be better?