There’s no crying in Agile!

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

5 Comments

  • Mike Wethington
    November 13, 2009 - 10:28 am | Permalink

    While I completely agree with your statement “There’s no crying in Agile.” I’d amend it to read, “There is no crying in Technical Writing.” Can’t get your work done on deadline, talk to your boss about getting help or resetting expectations, don’t cry about it.

    Unless your a medical technical writer, no one, literally, is going to die because your writing is less than perfect.

    Perspective is key. Do the best you can, set expectations accordingly, keep at it, and most importantly, and this is cliche but true, work smarter not harder.

  • November 13, 2009 - 1:11 pm | Permalink

    You read my mind. I had a couple of draft titles, including, “There’s no crying in content!” and “There’s no crying in tech writing!” :)

  • E-nonymous
    November 13, 2009 - 9:57 pm | Permalink

    Well, funny you should mention this subject, because I was reduced to crying in the restroom today. Over technical writing. A week ago my manager told me to “go put gray boxes around code blocks.” I had no idea how so looked up some html on the Web and sent him/her a sample URL, was told to move it to the right but otherwise it looked okay, so I moved it and spent several days hard-coding blocks around scripts in over 75 docs. And today someone higher than my manager called me out on a big mailer: “Why would you do that [because it was stupid]??” My manager jumped in with, “Why didn’t you use CSS or a class [like I assumed you would because you can read my mind]??” I did and did not because I didn’t know better and didn’t get any direction or guidance despite attempts.

    So I guess my point here is that yes, it is important to be flexible. But people like commenter 1 have self-congratulatory attitudes at the expense of others whom they would rather judge than understand. Please (including, I’m sorry, you, Anne) don’t bust on people who are treated unfairly, and don’t make it a function of weakness, age ["seniority"] or rigidity. Not everything is so cut-and-dried or obvious. To think so is naive. And rigid.

  • November 14, 2009 - 10:16 am | Permalink

    Oh, I’m so sorry that happened to you. That type of thing has happened to me before too, and I completely empathize. You were treated unfairly (which you recognize) and publicly called out, which is unprofessional. Sometimes crying is the best stress reliever! Sorry that my attitude comes across poorly in the post – you’re right to call me on it.

  • E-nonymous
    November 14, 2009 - 2:12 pm | Permalink

    Thank you for your kindness and empathy.

    …So perhaps a column about times in which you had to deal with unfair treatment that resulted from workplace dynamics and the eternal conflicts we are faced with in tech writing–lack of direction, hyper-accountability, information lost between cracks despite diligent effort, etc.? (Not suggesting a kvetch session.)

    …Also–have you had any experiences in startups which were unique to that kind of environment?

  • Leave a Reply