In response to: Refactoring The Scrum Lexicon

This is a comment I posted on Jordan Bortz’s blog in response to Refactoring The Scrum Lexicon (read this first). Apparently, it was too long as a comment. Jordan says:

Your reply is way too long To approve and aside from that, you just trot out the standard stuff….. If you have a shorter comment that is somehow relevant, that is fine, but all you are saying really is that we should just do it the way scrum wants and there is nothing unique or value added there

Still, here it is anyway:

Hi, I’ve subscribed to your blog as there’s some great posts here, but some of this one seems a little … contrary.

I totally agree with your chicken and pig comments, but I think that, if you understand the context, it’s not that insulting. You’ve worked with engineers right? They call each other much, MUCH worse. ;)

The daily scrum is a name I have no opinion for. You could call it the daily ballet and I wouldn’t care, it’s the content that counts. Most teams I’ve coached call it a standup.

I don’t mind scrum master, but team leader or team advocate is the WRONG title. I don’t lead the teams I’ve been SM for. I’m merely a facilitator and a tool to be used for removing impediments/buying donuts.

Continuing your marathon analogy, you could run a marathon with a series of sprints. Then stop, have a bottle of sports juice and see how well you did. Then repeat. If you’re fit enough to run a marathon, you’re fit enough to sprint it in stages and that’s the point. After each sprint, you have evidence on how well you did which will indicate how well you *could* do. I prefer iteration over sprint however, because I don’t have to explain iteration to people.

Sonja hit the nail on the head, the backlog is a prioritised list of user stories with acceptance criteria and estimates. That cannot be said of a todo list or feature list although, it doesn’t preclude those from being the same.

Finally, I totally disagree with your last point. A commitment is not a guarantee that the work will be done, just a commitment that the team will focus on getting that work done during the iteration, if they don’t, they don’t, but they’ve committed to getting it done and that’s what is important. There are real psychological reasons for doing this. Best efforts sounds like an excuse and projection sounds like a feature of a gantt chart. Commitments are one of the foundations of doing scrum correctly, removing that term will make it less clear what is going on.

I’m not entirely sure on your reason for suggesting these changes. Scrum and the framework should be judged on delivered working software. Not on whether the management agrees with or understands the nomenclature. By making it more professional, or more like traditional management will make it that more difficult to adopt. Scrum is often a radical change and requires decisive action to implement, it cannot be a gradual change from one methodology to another, it will ‘surface organisational dysfunction’ and for that, it needs to stand alone in order to be understood as not just a slight modification to what we’re doing, but a completely different way of doing things, regardless of whether that is true, that is what people will see when it starts shining a light in the cracks of dysfunction.

3 thoughts on “In response to: Refactoring The Scrum Lexicon

  1. you said “I’m not entirely sure on your reason for suggesting these changes.”

    I think that is now clear in Jordan’s response to Jay… he’s anti-Scrum, this was just one (simple) way to bash on it.

  2. I *am* anti-Scrum. However I do far more than bash. Go read my blog.

    Whether I use Scrum or not, a large part of my reason for suggesting these changes is to bring respectful terminology to the workplace.

    If the Scrum community isn’t willing to use respectful terminology, then, that is yet more one reason to avoid using it.

    Saying that the “ONLY” reason for posting what I did is to “bash” Scrum is not only blatantly false, it seems like a smear tactic.

    It’s possible to have conversations between pro Scrum and antis as long as people attack the issues and not the motives.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s