Tuesday this week saw the launch of the Agile Special Interest Group at the Center. It was standing room only and we had 71 federal staff and contractors attend. Stefan and Andreas presented from Frankfurt and we handed out Jim’s white paper. I was pleased at the turnout; it seems that we judged the mood of the center right and succeeded in our one chance to make a first impression. The SIG team met this afternoon and we looked at the feedback. My boss, who till now has been somewhat skeptical on the topic of Agile, said he appreciated the realism that Stefan and Andreas brought to the discussion and he’s signed up to attend the Agile Boston event next week featuring Jeff Sutherland and Ken Schwaber, the co-creators of Scrum.

We had a few questions from the audience at the end of the presentation that illustrated a healthy recognition of the challenges that face us as we try to introduce Agile methods to the Center. With that in mind, I talked with Larry, our organizational change management guy, about doing an assessment of As-Is stakeholder positions on Agile, where we want them in the To-Be, and how we’re going to get there. My question of the moment is how to make Agile robust under a range of customer styles and preferences and team skill levels. Alistair Cockburn in his Agile 2009 presentation I come to bury Agile… revisits Shu-Ha-Ri and the three skill levels in an Agile team. Right now I think we have precious few Level 3s, some more Level 2s, and a lot of Level 1s. Of this latter group there are necessarily going to be some that have no interest in being anything else than a Level 1, and I don’t want that to derail the initiative. Having said that, I think we have a good shot of being better than we are, and am looking forward to the journey.

I attended a presentation on Scrum last week, and afterwards my boss made a telling observation that none of the artifacts of Scrum (the Product Backlog, the Sprint Backlog, and the Burndown Chart) are of any use after the product is developed. Agile’s preference for working code over documentation makes it an easy target in the government world, where the objection is that we need both. One of the smartest and most productive developers I ever worked with rarely sent emails or wrote anything down – he used the whiteboard a lot though, and you could always drop in on him and he’d be happy to show you what he was working on. Customers, however, almost always want the documentation since it gives them the sense of security that they could, if they wanted, hand the product to another developer. Since customers define value, not developers, who are we to tell the customer that they are mistaken?

That’s not to say that there isn’t a lot of effort put into developing documentation that will never be used, either because it’s not needed or because it’s poorly produced. Bad documentation sends a message to the reader that his (or her) time is not valued. On the other hand, good documentation, printed on paper, can convey ideas in ways that other modes of communication can’t. You can skip ahead if the current topic is already clear, you can page back to see where a topic was introduced, you can annotate it, and you can take it on the plane with you and not have to turn it off for take-off and landing. Creating documentation (not just writing – I include modeling in this category) can also help you think through difficult topics. The brain works differently when you are putting things down on paper or on the computer screen.

One of the causes for the proliferation of useless documentation results from folks not collocated with the team, assuming that documentation is the main mode for how the team communicates. It’s not. Team members do a good deal of their thinking, communicating, and learning by talking, listening, and challenging each other. Team members typically work with short time horizons. When they’re done with a problem it’s time to move on to the next. Notes and whiteboards and remembered conversations work well for developers. Customers work with longer time horizons, and want a longer lifetime for the ideas that they’ve paid for. For ideas to persist they have to be recorded in some permanent and reproducible medium. In this respect, writing code and writing documentation are not that different