Chris Smouse

In this tight Austin job market, I’m seeing postings for positions like “Seeking Experienced ScrumMaster.”  ScrumMaster is a role – not really a full-time job.  I realize companies are having to dig deep into their goodie bags to attract talent these days, but they’re also applying terms like “ScrumMaster” and “Agile” in full-force buzzword style.  What a shame.  I’ll explain why.

There are 2 basic types of team members in the Scrum framework – chickens and pigs.  Pigs are the ones with “their bacon on the line” and chickens are there to “watch.”  An oversimplification, but I’m going to resist the temptation to digress.

ScrumMasters are pigs.  They are developers like the other pigs on the project.  They just happen to have volunteered (or been bribed or asked) to take on the facilitatory role of ScrumMaster.  Done properly, they have some level of tasking on the iteration schedule to help keep them honest (“at the trough”).  ScrumMasters are intimate with their product and teams, and they are proficient in the technologies with which they’re developing.  ScrumMasters are not project managers.

Scrum teams are self-organizing.  Project status is emitted from the burndown charts and team-maintained task board, as a by-product of each team member doing their part.  Having said this, the short list of responsibilities for the ScrumMaster role does include “enforcing the rules.”  But that’s different than scraping status for management or beating on teams for being behind schedule.

When you hire on a full time ScrumMaster, two important – and unfortunate – things happen.  The person in this job has a slim-to-none chance of owning any individual tasks on the development schedule, which makes them a chicken.  They just don’t have the same level of investment in actually completing the work as does a developer on the team.

The second thing that happens is that the full time ScrumMaster ends up diluting the sense of the self-organizing team.  The ScrumMaster is responsible for keeping the bumper guards in place, not for driving a project or pushing teams to go faster.

If you think you’re going to get someone to serve in the ScrumMaster role on multiple scrum teams, you might really be after a Program Manager.

Even in the biggest of tech companies, nearly everyone takes on multiple roles.  Mentor, liasion or mediator, to name a few.  ScrumMaster is another such role, and you might first suggest someone already on your team step into the role before trying to hire a wolf in sheep’s clothing.  Your burndown charts will thank you.

Pop quiz: You’re wrapping up your sprint review, and summarizing requests made by your customer.  Do you:

a) commit to fulfilling those requests before the end of the sprint you’re closing out,
b) commit to fulfilling those requests in the next sprint, or
c) not commit to making any changes during the sprint review?

My answer is C.  Let’s explore why C is the best answer.

Think back to when you started the sprint.  You and your team committed to your product owner a body of work to get to Done by a certain date.  You held your daily standups and you had ready access to the product owner and/or customer during the sprint.  Maybe you even had to put in some “overtime” to get things done. (more on why overtime is in quotes in a different post).

In any event: there you are, showing off the work the team accomplished, and now you have a set of feedback items to deal with.  Inevitably, some of that feedback will contain change requests.

It’s usually easy to detect change requests.  These often are prefaced with phrases like “it would be nice if” or “I’d like to see it do this.”

If the team commits during the sprint review to fulfill the requests before the end of the sprint you’re reviewing, then you’re setting yourself up for a short number of very long nights (remember: you also committed to a date at the beginning of the sprint).  You also reinforce the behavior of accepting changes at the last minute.  Not a good path to travel.

Let’s now consider committing to those requests in the next sprint (option B).  On the surface, that sounds better, but it’s only a tiny bit better.  There are reasons why your sprint reviews are separated from your sprint planning meetings.  You won’t have the right people in the room to fairly build out the workload for the next sprint, and pre-committing the latest and greatest change requests could displace other, higher-priority issues that your product owner is responsible for managing.

This brings us to C.  It should be fairly clear why C is the best choice, but if not, here’s why: It’s in the best interest of the team and the customer for the product owner to consider with equal weight the old and the new when it comes to managing product backlog.

It’s in the best interest of the team because you really do need the opinion of the developer(s) that may not be participating in the sprint review for whatever reason, and it’s unlikely you will know enough about these new requests to assign story points on the spot.  You certainly won’t have enough data to make a rational time estimate that feeds the sprint backlog.

Option C is also in the best interest of the customer because she is also not thinking about the backlog, which is out-of-sight-out-of-mind in comparison to that shiny new GUI she is drooling over in the sprint review.  Deferring commitment, even if just until the very next sprint planning session, helps mitigate buyer’s remorse on the part of the customer.

The sprint review is the ceremonial, if not technically the end of the sprint, because it’s near or at the end of the sprint and because the team has met all of their acceptance criteria that they set out to meet at the kickoff.  Be careful to not sabotage the team and its velocity, or otherwise move the finish line, just for the sake of making fast promises to an eager customer.

Lean and Agile software development frameworks are a great starting point for identifying the bare necessities for efficiently running software projects.  The Agile Manifesto itself is timeless in that it transcends process, rules, methodology and paperwork.  It cuts through to the universal, raw values that compel us to produce working software.

I’m a certified ScrumMaster.  You can take that certification course too, and learn all about the promoted techniques, meetings and artifacts.  What the course won’t teach you, though, is how to fill in the blanks.

One of those blanks is the gap chasm that can exist in your work model between “What do we offer users?” and “what are the concrete components that we build?”

Developers don’t develop user stories; they develop features and functional components.  On the surface, this may sound like semantics, but consider building a search engine.

User Stories answer the question What can I do with the software? Examples of this are “As a user, I can search by string,” and “As a user, I can page through search results.”  Provided that the product manager/owner actually fills in the backstory – rather than offering a meager list of one-liner requirements – the goal of the user story is to give developers enough context to a) coarsely estimate the complexity of the user story and b) identify the feature(s) that fulfill the user story.

There’s where some popular frameworks, including Scrum, dive headfirst into “start the sprint and we’ll see you in 4 weeks.”  Out of the box, there are few suggestions of how to operate after planning meetings and within sprints (iterations), other than “have a daily standup” and “end on time.”

One of the glossed-over steps is the need to synthesize a design for the features (and their inter-dependencies) that your team will use to fulfill the user stories under consideration.  Your architect or technical lead may be the one that produces this.  To extend the rugby metaphor offered up by Scrum: think of this as part of your game plan.

Once you have this game plan in place, your team will have the goods to provide finer-grain estimates for the work at hand.  Also, for you Scrum purists out there: there’s no rule that says you can’t allocate time for progressively elaborating this game plan inside a sprint. The important thing is to be deliberate about your feature breakdown, account for it, and adjust the rest of your schedule accordingly.

The moral of the story is this: Don’t expect too much from the framework you choose.  It’s up to you and your organization to define the processes that govern how you behave within that framework.