I’m sitting in an Indian restaurant as I write this, killing time while I wait for the auto-dealer to prep my new pickup truck. I’m convinced the delay is intentional since they know I was coming in with a confirmed purchase agreement. Still never having worked at a car dealership I really have no idea what they’re doing, and as an article Credulity and Politics in this week’s Economist points out, we appear to be hard-wired to believe people, so I’m giving them the benefit of the doubt.

I had an interesting session with the finance guy signing forms with an electronic signature. I narrowly avoided buying a maintenance package I didn’t want. The options page on the tablet that the manger handed me presented three options. They were labeled something like Maximum, Premium, and Standard – or some such language – leading me to believe that Standard was the lowest you could select. We are also hard-wired to expect three options. Each of the three options had similarly labeled buttons, encouraging you to click one of them. I selected [Standard]. Tablet moved to the next page with a signature block. I signed. Then the finance guy slipped up. He asked me if I drove into Cambridge every day. I said, no – I drive to the train station and take the commuter rail in from South Acton, and that I didn’t expect to put more than a few thousand miles on the truck each year. “Oh, in that case, we can change your coverage from 8 years, miles to 10 years miles.” Back to the options page. This time it dawned on me that I was being offered additional coverage beyond the manufacturer’s coverage. I asked him if I had to pick any of the options. The answer was no, so I told him that I didn’t want the additional coverage, and that was that, I just had to sign that I declined additional coverage. Here’s the observations:

1. The options page may have had a checkbox or something to indicate that I didn’t want any of the options, but I certainly didn’t notice anything. Presented with three buttons on a page and little else, it seemed obvious that I was expected to pick one of them.
2. The signature block was on a different screen that did not show the options. With wet signatures, the signature line is usually at the bottom of the page or block, and it’s clear what it refers to. In the tablet version it was disconnected visually from the options page.

One more observation. Although some of the signing was electronic, there were still some forms that had to have a traditional wet signature. I assume that’s because those forms were covered by regulations that don’t allow for electronic signatures.

All of this has bearing on the work I’m currently engaged in for FAA where they are building a system that will do way with the need for wet signatures on forms and items that currently require them. Yes – I know wet signatures are “old century” things, and that electronic signatures offer many improvements, but they need to be accompanied by commonly understood design pattern so that folks that are e-signing have an understanding that is at least as good as wet signatures. A couple of top level requirements might be in order:

1. When selecting options, all options should be presented in a visually similar manner.
2. The signature block should be presented on the same page as the options

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

The project manager doesn’t talk, he acts.
When his work is done,
the team members say, “Amazing:
we did it, all by ourselves!”

Tomorrow is the last day of fiscal year 2009, and you know what that means to a government contractor, don’t you. It means that you have to have all your plans in place for next year, even though the dollars haven’t shown up yet, you don’t have the staff, and the sponsor is continuing to shape the SOW. I’ve been a PMP for a number of years and while I find value in the PMBoK discipline and the common language that it provides, there’s a lot to be said for the agilist point of view. There are a slew of articles on the internet about integrating Agile with high ceremony approaches to software development. Two of the groups that I belong to on LinkedIn are the Agile CMMI (3,788 members) and the Agile Project Management Group (4,048 members). Some would say that they can’t be integrated, and others are trying to develop hybrids, but who says you can’t have both? Now I know that “Truth by analogy is fraud.” (Stroustrup) but isn’t this a bit like having an argument about whether Newtonian Mechanics or Quantum Mechanics is correct. It seems to me that Agile is just a better approach to running a software development team of skilled practitioners, and that high ceremony approaches (PMBoK, CMMI) are better at providing accountability to the customer. Agile works in short sprints, and although they may be the same length, the character of the sprint can change from the beginning of the project when you’re trying to figure out what to build, to the end of the project when you’re trying to tie all the loose pieces together and ship the product. Projects have a longer view – at least they do around here – and cover a lot more ground than just software. The unifying feature is that both sprints and projects deliver something of actual value to the customer for an expenditure of effort over a period of time, and both have measures. Agile has its burn-down charts and project velocity, and PMBoK has its EVM. Now if I can just figure out how to derive one from the other without increasing my workload, I’ll be happy. And that’s my next project.