I loved the line, as delivered by Tom Hanks in A League of Their Own, “There’s no crying in baseball!” I know there are times when the crying must happen without delay. I don’t believe most workplaces actively encourage crying – at least not outside of acting careers.
When I’ve read Agile practitioner reports that tell tales of times when technical writers have left meetings and fled to cry, I am not just surprised but a little dismayed.In A Tale of Two Writing Teams from an Agile conference three years ago, one anonymous writing team reported one writer in particular crying during the daily standup and in retrospectives.
As the prioritization changed from the new Java web program (the new and fun stuff) to updating the old, stuffy legacy client server code, writers’ tasks switched from creating new online Help to updating old versions of end-user documentation (books). This change caused the writing team to revert to form—that is, they began to demand written design specs. It’s as if once the technology took a step back from online Help to written documentation because of the prioritization of the product backlog, so did the methodology choice. I tried my best to coach the writers to work creatively with developers on the old stuff as they had on the new, but there was an insistence that the existing specs
for the old legacy code would now become outdated, and the writers were completely uncomfortable with that. One writer—the one with the most tenure—
moved out of the team room, citing lack of privacy and her ability to contribute as the reasons (when I know that it was really a lack of embracing the change). I can remember several episodes of her crying during daily scrum meetings and in
retrospectives.
The paper author’s analysis indicates that the stress of embracing change caused the outburst I think the stress of change can bring on an emotional outburst, and sometimes people have crying as their stress release.
But what is more interesting to me as a content provider is that the change in the tools used to deliver the documentation seemed to correlate to the writer’s work habits. As I search for wiki solutions for collaborative authoring on Agile teams, I’m reminded of this article again and again. There’s no crying in Agile, and having an Agile documentation tool should help with change management. Except, of course, the change management associated with bringing in a wiki. Stewart Mader had great suggestions at the recent WebWorks Roundup: make wiki upkeep part of everyone’s job, make it as easy as email, and make it as sociable and enjoyable as riding the train to work each day. Any other ideas? I’d love to hear them.