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....

...-.-

Build a Team Improvement Backlog

Retrospectives are the last thing a team does during a Sprint. There are a wide variety of approaches and formats one can use for Retrospectives, but the one thing all have in common is that the Retrospective must produce tangible results. One extremely effective way I have found to help ensure that the Retrospective meets this vital goal is to build a Team Improvement Backlog using the items the team identifies as action items.

A Team Improvement Backlog is nothing more than a prioritized list of action items the team comes up with during its Retrospectives. The most common recommendation, and one I heartily endorse, is that the team collectively chooses the top one or two items on the Team Improvement Backlog at or near the end of each Retrospective and then decides how to implement them and how to demonstrate success. Just like user stories, Team Improvement Backlog items need to have acceptance criteria -- the all-important definition of done.

There are a couple of nuances that can play into management of the Team Improvement Backlog. In general, items teams add to their improvement backlogs are public in keeping with the agile and Scrum values of openness and transparency. There are occasions, however, when I have recommended that certain items be kept private to the team. Examples include specific team interaction items, particularly when those items address individual behaviors. Retrospectives are sometimes more like the closed locker room meetings sports teams hold when they are experiencing a crisis. Teams typically do not allow reporters or even coaches into the locker room during such meetings simply because what the team members have to say to each other is strictly for their benefit as a team. In my coaching experience, private improvement backlog items are rare, but it's a handy tool to have in your bag especially when teams are storming.

Keep the Team Improvement Backlog visible in the team room and track progress at each Retrospective at the latest. Individuals who take on improvement items should also be talking about their work and plans during the Daily Scrum.

If you're not already using a Team Improvement Backlog, add this handy tool to your repertoire and use it to help your teams grow.

All for now....

...-.-

ScrumMaster Dilemmas

A few weeks ago, during a Product Owner class I was teaching, the lone practicing ScrumMaster in the room raised his hand after I had finished the section of the course reviewing Scrum roles. His question was basically this: "So, you just said one of the ScrumMaster's functions is to be a bulldozer, but when I solved a problem for my team last week, they accused me of 'throwing them under the bus' and now they won't talk about impediments anymore. What am I supposed to do?"

After learning more about the situation, I understood what had happened. At the last Retrospective, the team had raised an issue they were having with their Product Owner and, seeing himself as the fullback, snowplow, bulldozer, problem-solver, the ScrumMaster had simply taken the team's concerns to the Product Owner and worked out a solution. When he (the ScrumMaster) reported back to the team during a Daily Scrum his progress in resolving the issue with the Product Owner, the team reacted very negatively, as the ScrumMaster had described in his original question.

His confusion and genuine sense of hurt were palpable. He thought his role was to clear the road for the team so that they could get their work done as efficiently and effectively as possible. His point is entirely valid, but his experience demonstrates one of the many dilemmas that face ScrumMasters.

Take it to the team!

In her excellent book*, Lyssa Adkins gives this advice again and again. Self-organizing teams need to be empowered to solve their own problems -- or at least to devise prospective solutions to the problems they face. The ScrumMaster in my class did not realize that self-organizing teams, even those that have only been practicing for a few months, do not want to be presented with solutions to problems. Instead, as Lyssa points out, self-organizing teams want, and need, to be presented with problems. The team is then empowered to devise solutions -- and the team's solution will be the best one for that team. It may not be the solution the ScrumMaster would have chosen, but that does not change this essential fact.

Despite the best of intentions, ScrumMasters run into difficulties with their teams when they take on problems and solve them without team involvement. The team may ask their ScrumMaster to implement the solution to a problem, but the team itself needs to solve the problem. Many ScrumMasters came from backgrounds where individual problem solving was a major part of their job descriptions. Perhaps they were even evaluated on the basis of their individual problem-solving prowess. In a Scrum (or other agile framework) team environment, the equation changes. Problem solving abilities are still valuable, but within the context of of the self-organizing team.

ScrumMasters must engage in a delicate balancing act, being the bulldozer, fullback, or snowplow for their team, yet not imposing solutions on the team. It is more difficult to achieve this balance when a ScrumMaster is responsible for more than one team. Under pressure to help their teams succeed and with a severely limited amount of time and attention to offer to each team, such ScrumMasters are naturally inclined to gather lists of problems and run with them, handing solutions to their teams in rapid succession. This situation is bad for the teams, stunting their growth and inviting resentment against their ScrumMaster; it is also bad for the ScrumMaster who never really has time to get to know each team and the various individuals at the depth necessary to achieve the highest degree of effectiveness.

So what's a ScrumMaster to do? "Take it to the team," let the team solve problems, and keep the wolves at bay.

All for now....

...-.-

*Lyssa Adkins, Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition. Upper Saddle River, NJ: Addison-Wesley, 2010.

Scrum is more than just iterative and incremental

People often talk about Scrum as if it were nothing more than an iterative, incremental development process. Taking just these two aspects of Scrum makes it seem like it would be easy just to bolt Scrum onto existing development practices and organizational structures. I have trained and coached and talked -- either in person or on discussion lists -- with people who were completely comfortable calling their functionally delimited, mini-waterfall processes "Scrum" or "Agile."

"Well, we deliver a release every month that builds on previous month's release," is a common refrain.

A few quick questions reveal what's actually going on:
"Great! How's your quality? Is it getting better with each release? Are your teams getting better? Does every release contain the most valuable features you could possibly deliver?"

"Um, well...." is the usual response when an organization has adopted the superficial qualities of Scrum while ignoring the deeper principles and the practices they inform.

Iterative and incremental development are two results of Scrum done well, not the essence of Scrum. So what, you ask, is the essence of Scrum? I believe Scrum is about building cross-functional teams that are capable of learning how to do better work every day. Focusing on working software as the primary measure of progress by making use of the Sprint and daily planning cycles and the Sprint Review (to show our work) provides the framework for technical innovation -- and more basically, getting the job done, which is a huge challenge by itself in most organizations. The Retrospective gives teams the mechanism to improve both their degree of teamwork and, to a greater or lesser extent, the organizational environment in which they work. Learning teams, when propagated and nurtured, produce learning organizations that have a built-in competitive advantage over their less dynamic competitors.

Scrum is also about letting go of false measures, unrealistic planning, and failed control mechanisms. Measuring team throughput (Velocity) rather individual utilization provides a realistic tool for planning. The planning itself changes from activity and milestone-based to feature- and value-based, using teams' demonstrated ability to deliver working software as the key metric. Having teams pull work from the top of a prioritized Product Backlog ensures that, by definition, the highest-priority features are being worked on at all times and that each release contains the highest-priority, and therefore most valuable, features that could be delivered. Finally, allowing teams to deliver features, instead of relying the thoroughly discredited industrial practice of externally assigned individual tasks, opens the door to creative solutions -- and breakthrough productivity.

Where does quality fit into all of this? Returning again to the agile principle of working software as the primary measure of progress, non-working, buggy, software cannot demonstrate progress and therefore cannot be called "done." Teams and organizations that hold true to this principle have the capacity to do truly amazing things in an industry too often characterized by the poor quality of its products.

This is by no means a comprehensive list, but for me, right now, these are the key features of Scrum.

All for now....

...-.-

WFH Scrum

Working From Home (WFH) is an amazing thing. I have done it for years, off and on, and I really like it. Studies have repeatedly shown that people are more motivated, more focused, and more productive when working from home than when working at the office. Another major benefit is for people who face long daily commutes. Not only do they not have to spend two or more hours of utterly unproductive time driving to and from the office, people working from home also reduce traffic volume and air pollution, both major concerns where I live on the Front Range of the Rocky Mountains of Colorado.

But how does one accommodate WFH within a Scrum team? I have coached a few teams that wrestled with this issue. It is tempting to say "everyone needs to be here, every day." And indeed, that is the only way to ensure the highest-possible bandwidth communication within a team. Given my own affinity for WFH, however, I decided the dogmatic approach would be neither effective nor realistic.

The approach I have adopted consistently -- and successfully -- is to work with the team to make sure everyone understands the importance of the principle of face-to-face communication and then recommend a few WFH ground rules for the team's consideration:

• During the first Sprint or two, everyone needs to be physically present while we learn how to apply the rules of Scrum in practice
• When the team decides it is ready to run a WFH experiment, I suggest the following ground rules:
• Everyone is present for Sprint Planning, Story Time, Sprint Review, and Retrospective, which generally works out to be three days in each two-week Sprint
  
• Use Skype or other video conferencing technology to facilitate the Daily Scrum -- voice-only dial-in may suffice temporarily, but is not adequate over the long-term
• The team needs to adopt a standard, high-bandwidth communication medium/technology, such as Skype with video, that all team members commit to use for daily collaboration
  
• The Daily Scrum rules: if team members decide pairing or other face-to-face contact is needed, the necessary team members must be physically present even if it means driving to the office after the Daily Scrum, although we try to avoid the latter whenever possible
  
• Try to give people as much predictability as possible, but the team's needs trump all else

This is just a basic set of ground rules that I recommend and that teams I've coached have successfully adopted to accommodate WFH. Teams always refine, change, and adapt the initial WFH ground rules, of course, but this list serves as a good starting point.

Let me know if you find these suggestions reasonable, useful -- or not.

All for now....

...-.-

Rehumanize Your Work

I was -- and remain -- a big fan of the popular music that characterized the 1980s. One of my favorite bands was The Police and one of my favorite songs was "Rehumanize Yourself" from their album Ghost in the Machine. That song was never a radio-play hit, but it always hit home with me. Listening to that album the other day on my iPod reminded me why it is exactly that I now spend my working life at what is essentially Agile evangelism.

Many of the key reasons companies decide to adopt Agile are based on hard-nosed financial, business, value, and competitiveness calculations. And that is as it should be. After all, without a competitive business there would be no employment. So yes, the competitive boost companies derive from Agile is a key benefit. But for me, the greatest benefit is the rehumanization of work and of the workplace.

Among the most insidious results of Frederick Winslow Taylor's Scientific Management was the utter and complete de-humanization of work and the workplace. In the software development world, the various pre-packaged methodologies that have come along have all contained the spirit of Taylorism with its cynical, command-and-control approach to the people doing the work.

The real genius of the Toyota Production System, to me, was its inventors' realization that the assembly line was not mechanistic; it was, in fact, a social system that could only work properly if it took into account the human element. The result was the andon cord, which gave all workers on the floor both the responsibility and the authority to control their work.

Henry Ford once said: "Why is it that when I want to hire a pair of hands, a brain comes attached to them?" This is the essence of Taylorism -- and the antipathy of the entire concept of the andon cord. No worker in any of Henry Ford's factories was ever given authority to stop the line.

Software development -- or any other type of product development -- obviously requires hands that are attached to a brain, but traditional methodologies assume that the brain thus involved must be allowed to work only within rigid constraints because the people doing the work obviously have neither the capacity nor the inclination to take responsibility for their work. This, too, is the essence of Taylorism.

The genius of XP and Scrum, which are my main focus within Agile, is the recognition of the human element, of the fact that product development is primarily a social activity. By offering the people doing the work the authority to accomplish that work as they see fit, by giving them the responsibility to ensure that the work is done in the best possible way, and by establishing the social environment in which that authority and responsibility can be expressed to its fullest, Scrum and XP provide the best known framework for rehumanizing the work and workplace.

Along with the values, principles, and practices of XP and Scrum, conscientious, dedicated leadership completes the puzzle. So how about it? What will you do, today, to rehumanize your work?

All for now...

...-.-