Proto-agile in the Time of Hair Bands

Join me now, as we journey back to those golden days of yesteryear…. Yes, we’re traveling back in time to revisit the 1980s, the decade of Reagan and bands with Very Big Hair.

In 1987, I took a job as the one and only technical writer at a little start-up company called Colorado Memory Systems. The company made consumer tape drives to help ordinary people hang onto 40MB or so of vital data. Forty whole megabytes was a lot in those days, considering that most hard drives only held half that much.

Aside from the nostalgia of those innocent days of yore, an interesting thing happened at CMS. First off, when I started there all of us could fit in a single, not-very-large conference room. In addition, we had no QA department. As a bootstrap start-up, we couldn’t afford the inefficiencies inherent in specialist silos. As the company grew, we still had no QA department. The upshot was that everyone tested, every day, including yours truly, the tech writer.

The developers ran builds every day, which was quite an accomplishment considering that a clean full build could take five hours. Before leaving for the day, everyone grabbed the latest build, plugged a test tape into the drive, and ran a test script that would use said tape to beat on the software – and the tape drive itself since we also made the drives – all night long. We tested error rates, recovery from data error, heroic retry data recovery, and on and on. Every night. For several years.

In my roles there, first as the one-and-only technical writer and later as manager of technical publications, I worked hard to write the user documentation iteratively and incrementally as the software and hardware were being built. The user docs served as our UX test lab: if a feature or procedure could not be described simply, the feature or procedure was either poorly designed or too complex. The whole idea was to make tape drives a consumer commodity. Software and hardware that was difficult to install or use simply wouldn’t cut it. So early engagement with technical writers, beginning in the prototyping stage of both the hardware and software, was the norm. And feedback from technical writers in the form of the written user documentation and face-to-face conversation was highly effective in helping to improve the design of the hardware and software iteratively.

Buy the time I left CMS in the early 1990s to pursue yet more education, we had grown to over 200 employees and Grunge had replaced hair bands. But we still had no QA department. There were still daily builds. Everyone still tested every night. User documentation still provided vital feedback on hardware and software design.

Only now, in the 21st century can I put a name to what we were up to all those years ago. We were doing proto-agile. True, we did not release incrementally. We did not work in timeboxes. We did not have formal cross-functional teams. We did not test first then code. We did not consciously practice continuous improvement. Those practices were still locked in the future, scarcely a gleam in the early agilists’ eyes. We simply all worked together to build the best product possible in what were essentially daily iterations. Feedback was face-to-face. Testing and user docs were done early and often.

It’s no wonder I still have a soft spot for bands with Very Big Hair.

All for now….

…-.-

Why Stand during the Daily Scrum?

I’ve been asked this question surprisingly often in recent training classes and coaching engagements. The easy answer is that standing with your teammates for a few minutes every day is a part of Scrum.

“You’ll have to do better than that….”

Okay, let’s do better then. In my experience, teams that stand during the daily Scrum:

  • Display a higher energy level
  • Speak more directly and to the point, referring to defined tasks
  • Are more willing to ask for help
  • Engage their teammates rather than reporting to the ScrumMaster
  • Are more likely to raise impediments
  • Talk about 50% less, but convey twice as much meaning
  • Leave the daily Scrum energized and ready to work
  • Find the daily Scrum a vital part of their day

On the other hand, teams that sit during the daily Scrum:

  • Display a lower energy level, both in the content of their discourse and in their body language
  • Tend not to refer to defined tasks
  • Get bogged down in reporting minutiae
  • Tend to report to the ScrumMaster
  • Are easily diverted off-topic
  • Spend the entire meeting looking at mobiles/laptops
  • Hold side conversations
  • Rarely raise impediments
  • Talk about twice as much, but convey far less meaning to their teammates
  • Leave the daily Scrum bored and disengaged
  • See the daily Scrum as useless and sometimes drop the practice entirely

These results are subjective, based solely on three years of observing Scrum teams in action. On the other hand, these observations are extremely consistent across teams, organizations, and industries.

I think the big difference between sitting and standing is the signal it sends that the daily Scrum is not just another corporate waste-of-time snooze-fest meeting. The daily Scrum is of, by, and for the team. The symbolism of standing in a closed circle also reinforces the rational and emotional concept of “team.”

As with most of the Scrum/agile practices, there’s more going here on than meets the eye. And just because something isn’t obvious doesn’t mean it can be safely ignored. So suspend disbelief and try standing up. It might just be the catalyst that helps your team re-discover its energy and focus.

All for now….

…-.-

Mile High Agile 2011 – A Great Conference!

Yesterday (April 7, 2011) saw the beginning of what I sincerely hope becomes a long-standing tradition in the agile world — Agile Denver’s Mile High Agile 2011: Elevating Agility conference. The conference generated such interest that it actually sold out! As a conference organizer, it was my privilege to work with some of the finest people in the agile community, here or anywhere.

It was also my privilege to be a speaker at the conference. My session was very well attended (as were all of the sessions) and reviews were overwhelmingly positive. The title of my presentation was Agile Leadership for the Learning Organization. As promised to attendees of my session, a link to the presentation will live in the sidebar of my blog for a few weeks.

Moving from Train-wreck Management to Agile Leadership is a long and sometimes arduous journey, but the benefits are beyond question. The people who do the work — and create the value — gain motivation and permission to create startlingly innovative solutions to business problems. The organization as a whole gains focus, direction, and meaning. That combination offers 21st-century companies the best possible opportunity to succeed in the marketplace, earn greater profits, and provide employment for yet more creative, highly (self-) motivated people, in the virtuous cycle W. Edwards Deming identified.


I would like to offer a very special Thank You to Jean Tabaka, for participating in my session (yes!!) and for her thoughtful and thought-provoking feedback.

Until next year, keep on Elevating your Agility!

All for now….

…-.-

Good teams are like good code: Highly Cohesive, Loosely Coupled

The best Scrum teams I’ve worked with have been reflections of the code they produced: highly cohesive — meaning focused on a project or product — and loosely coupled — having minimal direct dependencies on other teams. Like excellent code, excellent Scrum teams don’t just happen; it takes careful planning and continuous attention to detail.

Let’s start with high cohesion. The highest performing Scrum teams are initially built around a purpose, a specific project or product, and allowed to focus exclusively on that project or product. But after that the team’s design is emergent, adapting to changing circumstances and increased knowledge about teamwork, the domain, and the product. Like a well-designed class, the team is directed at its purpose and resists attempts to redirect it. Once the current project or product is complete, the team can take on a new project or product, just like a cohesive class can be instantiated repeatedly. The key is that, like a cohesive class, the team is focused.

Great Scrum teams are also loosely coupled to other teams. What this means is that a great team has very few dependencies on other teams, that is, the team can complete its work without waiting on outside experts or the work of other teams. I can already hear the objections: “Okay, so a great team contains all of the skills and knowledge needed to complete its own work, fine. How can you keep even the best team from waiting on other teams to complete their work?” Okay everyone, turn your eyes to the Product Owners in the room.

A great team must have a great Product Owner. The best Product Owners ensure that their team’s backlog is independent of the backlogs of other teams. Even more, a great team of Product Owners can decouple the backlogs of all teams to the maximum extent possible, ensuring that all of their teams, like all of the objects in a well-designed application, only access each other through well-defined interfaces that minimize dependencies.

The next time you survey your organization’s Scrum teams, think like a software architect and work on making your teams highly cohesive and loosely coupled!

All for now….

…-.-

Don’t be like Homer Simpson

“In times of trouble, go with what you know.”
–Homer Simpson

Words of wisdom from a notoriously brainless cartoon character seem like an oxymoron — and in fact that is the case. Unfortunately, Homer’s prescription is something I experience over and over again with client organizations. In the midst of a difficult and challenging change, like moving the organization from a sequential development process to Scrum, there is strong temptation to fall back on old habits of mind. Whenever things get uncomfortable, whenever Scrum makes a long-standing problem unbearable, the knee-jerk reaction is to ditch the part of Scrum that “caused” the problem and revert to a previously learned behavior.

One example I have experienced repeatedly is the problems caused by a widely distributed Scrum team, that is, one with some team members in North America while others are in China or India. I recently ran across an issue in which the more experienced North American team members were attempting to work with freshly minted graduates in China who lacked even the slightest shred of domain knowledge. Since the time shift in this case was exactly 12 hours, it was impossible for the team members to work together closely. Not only were there twice-daily hand offs of code between team members in the different geographies, there was also the issue of the Chinese team members lack of experience in the domain.

The response from the domain-expert team members in North America was to clamp down process on their young Chinese peers. Over time, many gates had been constructed to prevent the Chinese team members from doing any damage to the code base. By the time I arrived on the scene, the gates were so restrictive that the Chinese side of the team — and make no mistake, each geography had taken sides — was unable to do any work at all. Even the simplest tasks were impossible to complete without involving the North American side because of the gating requirements.

A better solution, which the organization actually implemented, was to create separate North American and Chinese teams. While this by itself did not solve the bigger issue of domain knowledge being restricted to the North American team, it did allow both teams to work with a degree of independence and to finish the work they committed to each Sprint. The one major adjustment was to have the Chinese team work in one-week Sprints while the North American team worked in two-week Sprints. Shorter Sprints forced the Chinese team to break its work down into very small bites that the North American domain experts could then help with during the short window of overlapping availability each day. By limiting the range of variability — implementing one-week Sprints — the organization was able to move forward with new feature development much more quickly than had been the case with a distributed team and a multiplicity of gates for the Chinese team members’ work to pass through. The organization also unknowingly implemented one of W. Edwards Deming’s credos, that of changing the system to reduce variability. More on that topic in a later post….

All for now….

…-.-

Got a Morale Problem? Get Quality!

The connection between product quality and morale isn’t a big mystery, but it seems to be one that is frequently overlooked. W. Edwards Deming and, somewhat later, Frederick Herzberg famously linked the sense of accomplishment people experience when doing good work on projects over which they are able to control how the work is done with high morale. Scrum’s emphasis on delivering a working product increment at the end of each Sprint fits into the morale equation perfectly.

So what’s the problem?

We don’t always do as we should. When teams are pushed to take on more work than they can competently deliver, quality is the inevitable casualty. Teams that find more and more of their capacity sucked away by bug-fixing rapidly experience significant, sometimes catastrophic, declines in morale. With morale goes innovation, productivity, and continuity as people seek to flee the bug storm.

An even worse situation occurred in one company’s misguided attempt to focus on its defect backlog while at the same time delivering new features at their accustomed pace. The solution they settled on was to create a bug-fixing “team” — actually a large work group — that would, in essence, clean up the messes left by the over-worked feature group. Freed from the responsibility for the quality of their work, the feature group delivered a large number of features. Unfortunately, the feature group’s freedom from responsibility produced a product strangled by defects which the poor souls on the bug-fixing work group couldn’t hope to save. Both sides blamed the other for the rotten product quality and morale throughout the company hit absolute rock-bottom. An attempt to introduce Scrum into this situation failed because of the maelstrom of blame, mistrust, horrible morale, and fear of change.

The highest morale I have had the privilege to share in occurred on Scrum teams that were allowed to play by the rules of Scrum: only pulling in the work that the team members could commit to, failing tests were simply an indication of “not done,” and nothing that was “not done” ever saw the light of day. The company provided adequate support for continuous integration, TDD, refactoring, and other good engineering practices, which allowed the teams to work without fear of unintended consequences. When a bug did surface, as bugs inevitably will, the team that produced it was responsible both for the fix and the tests to prove the fix. The teams in this organization felt the same degree of ownership and satisfaction when fixing bugs as when developing new features. In short, their morale was in the stratosphere. Their quality was also spectacular.

So the next time you notice one or more teams suffering from poor morale, work on quality. Fix the quality problem and the response to an inquiry about morale will almost certainly be “what morale problem?”

All for now….

…-.-

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.