Monthly Archives: November 2012

Coaches and How to Hire Them

I really like the ideas expressed by Tobias Mayer in his post “How to Hire an Agile Consultant.” I recommend you go read his post.

I found Tobias via the comments on this anonymous “editorial”. That happens to be a post with some good ideas and concerns as well, but I have to fall in with the commenters who take it to task for its anonymity, in spite of using the personal pronouns “I” and “me” consistently throughout. Good ideas, but no-one to whom one can give credit.

I haven’t yet directly experienced the coach = scrummaster situation yet, but I can easily see how it will happen as more and more companies look for help in “doing agile.” And more and more companies spring up to offer these services.


Scrum Master != Answer Master

One thing I’ve seen in watching companies adopt agile principles, and specifically with some flavor of Scrum, is the tendency for newly-minted ScrumMasters to feel that they must have the answer for any question asked in a standup, demonstration, planning, grooming, or retrospective.

Now, it’s very typical for the existing Project Manager to assume the ScrumMaster role. It is the closest to what they were doing before.

And it’s natural for ex-Project Managers to hold on to many aspects of that role–we’re creatures of habit, after all. And in waterfall, the Project Manager was responsible–even accountable–for creating that lovely detailed work breakdown structure, and those spiffy cascading Gantt charts in MS Project. All the answers were at their fingertips: Are we On Schedule? Check with the Project Manager–they have a magical way of knowing if things are on track! What happens if we remove a feature? Subtract the tasks from the WBS, re-align any dependencies and voila, the Project Manager has calculated the answer!

Things aren’t so simple in life. Or in Scrum/agile.

If we’re building a healthy team, we should be seeing communication between team members, in a network, rather than in the hub and spoke fashion of a lot of Project Managers. ScrumMasters should encourage this networked mode of communication.

I believe it’s healthier to accept that one individual will not have all the answers. Scary? Sure. But if your team is healthy, the answer to a question is not very far away, because there will be enough communication to retrieve any answer in short order (and enough information radiated by reports the ScrumMaster maintains to answer many simple status questions straightaway). Think about the idea that the knowledge of the team is “too big to know” and that the smartest person in the room is the room.

One way to be sure that your team doesn’t get healthy is to make sure that all communication is funneled through one single individual. (For instance, what does it do to your truck number if only one person has access to the folder where the team’s release plan is stored?)

On some–or maybe even many–projects, rather than being a special expert, the ScrumMaster could be an individual from within the team who steps up to handle the ScrumMaster role in addition to their other duties. The description of the ScrumMaster from the Scrum Alliance’s Scrum 101 page reads simply “ensures that the team is functional and productive.”

So, ScrumMasters, make sure your teams are protected from outside distractions. Radiate information like a single-pipe steam radiator with a wide-open air vent on a freezing cold day. Get the team to the demonstrations, the retrospectives, the grooming, the planning by making sure they know when and where they are. But once things get underway, get out of the way. To borrow a phrase, facilitate your meetings “as though you were cooking a small fish.”

(As a sidebar, and in the interest of thoroughness–not as an endorsement–I’ll link to the “ScrumMaster Manifesto.” I’ll say that I’m pretty sure that I disagree with their statement “WE BELIEVE THE SCRUMMASTER IS A FULL-TIME POSITION FOR ONE PERSON ON ONE SCRUM TEAM.” I think a lot about team size, challenge, maturity, and capability are being assumed by that statement.)

Jilles van Gurp’s “Scrum: Agile Madness”

There is some great stuff on Jiles van Gurp’s blog. Here are a few of my favorite thoughts from “Scrum: Agile Madness

  • “…you can’t substitute experience with process and that is exactly what agile followers end up doing. Take away the experienced people and you have a lot of people executing the rituals of scrum, kanban, or whatever without really understanding what they are doing.”
  • “…often scrum is introduced to fix what is already a dysfunctional organization.”
  • “Actually, if all of the above is true [referring to four assumptions about happy and productive teams], you will have little need for process. If that isn’t the case, no amount of process is going to fix things magically.”
  • “[ironically:] A two day pep talk about scrum is apparently all the training you need to become a product manager or scrum master.”
  • “[T]here are a lot of inexperienced people who get promoted to be a product owner or worse start their first or second job being one. Likewise, the scrum master role is not considered a job very high on the corporate ladder either.”
  • “Choosing and tuning the way in which you work is more important than having everybody mindlessly follow the same process.”

These quotations of course are all presented here without the context van Gurp provides. I strongly recommend you read the whole post: . Thank you, Jilles, for your blog!

Punished by Ambition

One of the precepts that we–okay, I, for certain–take for granted in scrum is that teams should consider carefully how much work they can commit to in their sprints, use estimated size (i.e. in story points*) and past history as a guide, and only take on more work if they truly finish the work they’ve committed to. Intuitively, this makes sense. You want your teams to focus and finish work, not to start, or stub out, more than they can finish. Starting more than you can finish leads to making some progress with a lot of things, but being finished with few.

As I said, this makes sense intuitively. Recently, I came across a very nice empirical observation of the danger of over-commiting. I have to give props to one of my current clients** for providing this example, as well as providing the title of this blog post (although the phrase may have first been used by Sir Francis Bacon).

The team’s velocity, now established after more than 8 working timeboxes, is 60+ points per three-week sprint. This is shown on the graph as the 5-week moving average of points completed per sprint. But the team didn’t always know–or trust–that as a fact.

During their fourth sprint, even though they had never completed more than 81 points in a sprint, the team was pushed to accept 134 points as their committed work. They failed in a spectacular manner, completing less than a third that many. In fact, the number of points completed during that sprint was their second-lowest on record. (Their lowest-measuring sprint occurred early on when the team had almost no experience with agile techniques.)

So you can imagine what happened, right? The Product Owner, excited at seeing an upward trend over the previous couple of sprints, and perhaps agitated to release something soon, may have pushed the team to take on more work. Or the team itself, wanting to prove something, may have applied internal pressure. Whatever the exact reason, they took on more than they could handle. And the result was calamitous. Not only did the team not complete all the points they committed to, they in fact completed fewer points than they usually could.

In sprints 3.3 and 3.4, the team was more conservative, committing to 62 and 70 points respectively. And in both of those sprints, they were able to pull in work and complete more points than they committed to. (This pattern may suggest, of course, that their actual capacity is higher than 60.) But look out! Buoyed by those two successes, the team committed to 115 points in sprint 3.5, and again failed to meet their commitment. (To be fair, they did complete more than their average, so something is going right.)

The important point is that remaining focused, which in behavior translates to committing to fewer points/stories, allows the team to work more effectively and accomplish more than planned. And being aggressive in committing to work dilutes attention and results in worse than average performance.

* But for a good common sense opinion on NOT using story points for selecting work for sprints, see Mike Cohn “Why I Don’t Use Story Points for Sprint Planning.” I don’t think what he says negates the underlying message I’m trying to convey in my post.

** Not wishing to run afoul of any confidentiality agreements that may exist, I’m not going to identify the client by name in this blog posting.