It's the Estimating that Matters, not the Estimates

It seems like there is always some sort of controversy or at least discussion swirling around the merits of estimating user stories and tasks. Mike Cohn's justifiably famous book, Agile Estimating and Planning, makes the case for relative (story point) estimates for user stories and hours for tasks. I have always found his ideas useful and recommend them when coaching new teams. As many agile practitioners have pointed out, that level of estimating tends not to be necessary for mature teams. Some even think estimating isn't necessary at all.

I think the discussion of whether agile teams need to produce estimates -- particularly at the user story level -- or not misses the point. For me, particularly with newly formed teams, it's the act of estimating that is absolutely vital; the estimates produced are potentially useful, but the estimates are not the point; it's the estimating that matters.

Teams new to agile or teams that are re-forming with new members who lack deep agile experience need to engage in estimating for a variety of reasons:

• Agile teamwork is different! Most of us who have spent the majority of our working lives digging around in code or other parts of software or high-tech projects never had the luxury of providing our own estimates. We have traditionally been told what needed to be done and when it needed to be done. End of discussion. Team estimating helps bring to life the reality that working in an agile environment, on a Scrum team, really is dramatically different than anything else most of us have ever experienced. We are authorized to estimate our collective work and our estimates will be honored by the Product Owner and the rest of the organization. That is a substantive demonstration that no amount of happy talk can supplant.
• Estimating enhances understanding of the work! We cannot, as a team, commit to any work that we don't fully understand. Again, in sharp contrast to the bad old ways of working, Scrum team members are never compelled to take on or commit to work that is unclear or ill-defined. Team estimating provides a context to tear into the work -- the user stories the Product Owner thinks are coming up soon -- and really understand the details. The estimating part is important because it requires us, as a team, to agree on an estimate of effort, complexity, and risk for each user story. The discussions must be focused and grounded in reality, not vague, open-ended, or facile.
• Estimating helps us discover gaps in the work. As we engage in serious discussion about each user story, we collectively begin to see the connections between the stories and the disconnects that indicate gaps in the backlog. One of the most satisfying outcomes of a Story Time meeting, which is where I like to get the story estimates done, is a Product Owner with a stack of new stories to prioritize.
• Estimating helps us become a team! Collective estimating -- and I really like Planning Poker as a mechanism -- helps us learn to listen to and understand our teammates. Planning Poker ensures that even the shy, quiet, oppressed, or disengaged team members take part in the discussion. Odds are everyone on the team will be high or low estimator at least a couple of times during an estimating session. The rules of the game, when observed rigorously, ensure that everyone must listen to the person speaking and more than that, must take seriously what that person says. Again, the deliverable of an estimate compels everyone on the team to take the discussions seriously.
  

So what about the estimates? Perhaps they are useful to the Product Owner in Release Planning. Perhaps they are useful to the team in Sprint Planning. Perhaps, as many practitioners suggest, the estimates really are not useful in those contexts. I don't necessarily agree, but I'm fine with that opinion. It's the estimating that matters, after all!

All for now....

...-.-

In Defense of Certified Scrum Training

I have been reading and hearing criticism of certified Scrum training sponsored by the Scrum Alliance for almost as long as that body has been in existence. As a QA guy on an incipient Scrum team, I heard colleagues dismiss such training and the resulting certifications as superficial or worse. A couple of years later when I began making my living as an Agile trainer and coach, I encountered even fiercer denunciations of certified training from colleagues and from some members of the broader Agile community. I kept an open mind throughout, but did often wonder what all the fuss was about.

Recently, during the last year really, I have come to a new appreciation for certified training. Certified training, to put it bluntly, defines the parameters for the content. In the case of certified Scrum training, what is presented and learned must be Scrum, which a clearly identifiable thing consisting of the well-known values, roles, ceremonies, and artifacts. The Scrum Alliance goes to some length to ensure that its certified trainers do not teach something that is not Scrum under the label "Scrum." Some agilists get utterly bent out of shape over this seeming restriction. But to me, it makes perfect sense. No one anywhere is saying that agilists cannot teach something other than Scrum and plenty of such training is going on to great benefit of the individuals and organizations that embrace it. Kanban certainly fits that bill perfectly. But, and this is the key point, Kanban is not Scrum and should not be labeled as such.

Another benefit of certified training occurs at the organizational level. I have worked with clients that claimed a sincere desire to become "agile," but immediately rejected the implications of Scrum. In a non-certified environment, it is all too easy for a client to dispute the value of basic Scrum practices and simply demand something that looks and smells a lot like what they are doing today, hoping that the consultant, trainer, or coach can just make it all work without any of that painful organizational change stuff. In a certified Scrum environment, the selling of "fairy dust" (or snake oil or whatever metaphor you prefer) is not possible, or at the very least, much less likely. If a client wants Scrum, it's Scrum they'll get, with all the pain and eventual exhilaration that transition entails. If it turns out that the client really doesn't want Scrum, at least everyone can agree on that point and make the appropriate decisions.

Now I'm no wide-eyed naif. I am fully cognizant of the limitations of the entry level certifications. Being a Certified ScrumMaster does not make one a masterful, or even competent, ScrumMaster. I have learned this excruciatingly painful lesson first-hand in my coaching life. That is not to say, however, that the two-days of training are worthless. When competently delivered, trainees understand the Scrum framework, the roles and rhythms, and how to move forward with Scrum. As with any type of education, individuals make what they will of that abstract knowledge. Some bandy the title about as if it meant they were Scrum experts. It doesn't take much effort to expose the hollowness of such claims. Others use the certification as the gateway to successful Scrum practice, gained through hard, daily, on-the-ground experience either as ScrumMasters or in some other role on a Scrum team. But blaming certification in general for the sins of what is really a small number of people is neither valid nor useful.

I don't know what the future holds, obviously, but for now and for the foreseeable future I believe Scrum is the most broadly applicable framework for new product development and as such, I support certified training and certification in Scrum.

All for now....

...-.-