Why You Need an Outside Coach

As a coach called into an organization to do something very specific, say, help get teams over the hump on continuous deployment or TDD or ATDD or something like that, a conversation with the sponsor frequently goes something like this:

Sponsor: "We've been doing agile for (some number of) years now and we're extremely proud of how well we're doing."

Coach: "That's great! I'd love to learn from your experience while I'm here."

Sponsor: "Absolutely!"

A few days later, after working with the teams on that specific technical practice, it becomes painfully apparent that things are not as advertised:

• Teams have abandoned the Sprint Retrospective
• Teams consistently fail to deliver stories during the Sprint, comfortably allowing them to slide into the next Sprint
• Sprint Reviews have become stale and self-congratulatory because they are conducted inside the team fishbowl, without stakeholders or customers present
• Sprint planning meetings are chaotic and painful because teams are not engaging in backlog grooming or "Story Time" meetings to get ready for the next Sprint
• Sprint planning meetings are artificially abbreviated so as not to "waste" time, leading to failure to understand stories adequately and failure to deliver those stories during the Sprint
• Teams work in personal silos, with hand-offs and queuing delays holding up story completion
• Teams prefer information refrigerators to information radiators because transparency is too hard/scary/threatening
  

These and a myriad of other problems and dysfunctions are the all-too-common result of an insular corporate culture that lacks the spark of cross-pollination. Agile can quickly become stale, stagnant, or just plain smelly when organizations look exclusively inward. Allowing team members and other agile practitioners to attend conferences is a solid strategy to keep the flow of ideas from drying up. But at some point, you need to bring in an outside coach to freshen up the organization's perspective.

Okay, I can already hear the objections. Yes, I make my living providing agile coaching services. However, I wouldn't be in this line of work if I didn't believe fervently in both agile values and principles and the benefits of coaching.

An outside coach has some advantages that are very difficult to obtain internally. First off, an outside coach is a disinterested observer (disinterested does not mean "uninterested" - it means having no vested interest in any particular outcome, an honest broker) and can therefore recommend things that people tied into the organization would be unwilling or unable to broach. An accomplished outside coach also brings wide-ranging experience to the table. After a few years of active coaching, most of us have seen the gamut of issues and can leverage that experience to help organizations overcome most any impediment, even ones we've never seen before.

Finally, an outside coach can offer that breath of clear air, the source of vital cross-pollination that helps freshen up your agile practice, providing the boost your company needs to overcome organizational gravity or get off the current plateau and move forward.

So freshen up your approach - call a coach!

All for now....

...-.-

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

...-.-