Scrum According to Me

David Shirey
Sep 7, 2018 · 6 min read

In the last two articles we started looking at Scrum; What Scrum Isn’t, and The Essence of Scrum.

So what is next? Obviously, ‘Scrum According to Me’, my take on what is really important and what isn’t.

Scrum Masters vs Project Managers

And the first thing I need to talk about is the role of the Project Manager.

As you probably know, the Gods of Scrum do not provide a place for the Project Manager. At the same time, they do not provide for the Scrum Master to do the PM’s job (tracking what has happened, developing staffing plans, budgets, etc.). They don’t usually say who should do that and you can argue that in a truly Agile environment you don’t have those tasks.

But — most of the people who I see using Scrum are not in a truly Agile environment. They call it that, but they still develop project spec’s, have budgets, etc. They use Scrum in what is essentially a waterfall environment. And that’s OK.

At the same time, most businesses aren’t crazy about paying for a BA, a Scrum Master, and a Project Master. So in many Scrum environments, the PM is dropped.

But I believe in PM’s. And, unless you are in a true Agile environment as defined by the Agile Manifesto, you need one to do tasks that a Scrum Master can’t / won’t do and which the Project Owner is probably too busy to do. Fortunately for me, I believe that the PM can do a very good job as both a PM and a Scrum Master. A lot of folks would disagree but I have seen it work very effectively.

The Stand Up

The next thing I change is the most well known of the Scrum artifacts; the Stand Up.

Most of the time, when I see people doing Scrum, this is the main (and sometimes only) Scrum thing they do. And for most, the important part of this artifact is the standing up part.

But standing up is not the reason for the season. The purpose of the Stand Up is to give everyone a very brief chance to check in and report any problems they may be having so they can be identified and resolved. Yes, you get to find out what everyone else is doing, but often I could care less. What is important is me saying what I oplan to do today and if there is anything standing in my way.

First, we don’t stand up. We sit down. I know Scrum aficionados are howling disapproval right now but I don’t care. The idea of the stand up is not to have everyone stand up but to keep the meeting brief and focused.

If you have a decent Scrum Master (or PM!), then it is their job to keep it moving and short, not abrogate that to how long people are able to stand.

The stand up is not about making everyone feel a part of the team. It is not about what your plans are for the weekend. It is not about the current weather, how many people are out sick, or the fact that you had to park miles away from the building today. Those things fall under the heading of ‘Team Meeting’.

The Stand Up is about what you did yesterday, what are you planning on doing today, are there any problems you are dealing with? Short and sweet and everyone on the team is responsible for sticking to that format. And if they don’t then the leader has to gently but forcefully move the conversation on.

The other thing I do is take notes (as the Scrum Master) on what everyone says they are going to do today. And I will bring them with me tomorrow.

Why? Cause I’m a grizzled veteran and, like Woody Harrelson in Solo, I don’t trust any one.

And the deal is, taking notes is a lot harder to do if you are standing. The advantage of taking notes is that my notes tell me what somebody planned to do yesterday. So I can now compare that to what they say they did.

It’s not enough for someone to just do ‘something’ yesterday, it has to be what the plan calls for and if it isn’t completed, then that must be looked at. Failure to include this feedback loop makes most standups worthless.

The Sprints

I know the Scrum Master doesn’t really have much to say about the sprints. But nobody said anything about what the PM can do.

I am willing to let the dev team decide what they want to do, but the main advice, say directive, I would give them as they decide this, is how does this moves us forward? And what can we show the user to indicate that movement? The goal is to have constant interaction with the business user during the sprint.

Unfortunately, most companies want a constant sprint length, probably two weeks.

And there seems to be a feeling that those two weeks are to be spent heads down by the developers. Users will get to see what has been developed at the end of the sprint as part of the Retrospective. Too late. Way too late.

The thing I do is try to ensure that this does not happen. I can live with a two week sprint time but I want to ensure that every time the developer has something that is visible to the naked eye done that we get the users involved, show them what we’ve got, and get some feedback on it.

And so, as the sprints are set up, the dev lead and someone who represents the users a little more than the typical dev lead, who is a pure technical person, needs to push to get something out of the sprint that is visible to the users.

The Retrospective

Unless led carefully, the Retrospective can be just a waste of time.

For many teams it is more of a celebration of the end of a sprint than anything else. I guess there is nothing wrong with that although I am never in favor of all out frivolity unless it can end up with a cocktail party or something. But too often, we get caught up in feeling good about what has been done and miss the deeper significance of the Retro.

For example, every two weeks may seem too frequent to say that among the ‘What Could We Have Done Better’ things that ‘Team B just responds very slowly to our requests for infrastructure changes’. But often it comes down to that. We need to remember that the things that are said should either be shouted down or else be taken up as a near future project of it’s own. Maybe there are things we can do about our interactions with Team B other than just hating them.

Same thing for ‘What Did We Do Well’. Was it something different, do we have an opportunity here to improve the process? Some times that is difficult because as much as we like to think Scrum and Agile are spontaneous, most organizations have a host of rules in place about how they will both go down.

Perhaps most important, however, is that we should not look at the Retrospective as a chance to demo what we have done, unless that demo is being done for management.

That is, as I noted above, demos for the users should occur continuously throughout the sprint, not just at the end. If you wait for the end, chances are anything that the user doesn’t like will require some tearing apart of things to fix it. Worse yet, users may be very hesitant to speak up before a relatively large group and complain about the work that has been done. And that starts us down the road to developing something that IT really likes but the business not so much.

Parting Shots

Seriously, Scrum is not that complex.

If you want to do Scrum, whether you are doing Agile or Waterfall, put the stress on making it meaningful. Is there really any point to a Stand Up that doesn’t hold folks accountable for what they said yesterday? Is there a point to getting the same list of things that could be improved at each Retrospective and not setting up a plan to address those issues? Do we really need to wait two weeks to show off what we have done to our customers (i.e., the users)?

Scrum can be a very powerful way to inject energy and results into your projects. Or it can just be another methodology that we slog our way through. It’s honestly up to you.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade