9/8/2008: David Hussman Speaks at the Twin Cities Java User Group

David Hussman gave a presentation last night at the Twin Cities Java User Group. The topic was Architecture and Agility Are Not Mutually Exclusive. If you haven't heard David Hussman speak I recommend that you do. David will be presenting at the October 10-12 No Fluff Just Stuff Twin Cities Software Symposium, which, in my opinion, is an excellent opportunity for us to take a weekend and exchange ideas on software development.

Hussman is one of my favorite agile speakers, he promotes making processes work to fit the people. I don't want to put words into his mouth, but the takeaways I get from his presentations are to focus on the people and let everything else evolve around them. He says that processes should be descriptive and not prescriptive, that is document what you are doing and work with it and evolve it into the process that you want.

Don't come up with abstract processes that may not have any resemblence to what you are doing and try to force a team to do that.

A perfect example of that was when I worked for a company that was working to become CMMI certified. Part of the CMMI process was to document the processes. One of the features that was touted about CMMI is that ulike [that silly fad] ISO 9000, (you hear the chuckles from the crowd and presenter), these processes are actually used. There would be ample documentation about how to do every aspect of our jobs. Just like the military, we'd have Standard Operating Procedures, SOPs, for every facet of our duties. Instead of miring in paralysis by analysis we'd already have a prescriptive guide for how to do our jobs. Awesome.

Being the simp that I am. I believed that the words that that company's managers had had meanings and I tried to follow the procedures that were documented. I read the Software Engineering Process documentation that was written by our lone project manager. I read the standard operating procedures whenever I was uncertain about what I should do in a situation. I quickly realized that all of the documentation had been written by the same project manager.

This is the project manager who was best known for asking developers how much time could they save if they reduced the quality of the product. From many of my peers and my vantage point, she didn't know the first thing about developing software. But now we came to find that she literally wrote the rule book for how to do it.

For the time that I was there I had a manager who thrived on conflict. He would love to find these processes that don't work and make a call to the person responsible. I don't know if he was more interested in pointing out someone's failures to them or if he just wanted to make sure that things that were broken didn't stay that way. Regardless, with the CMMI work, he was able to make lots of calls.

What came of this experience? Well, the company became something like CMMI Level 3 or 4 certified, but the documentation and 'the process' was mostly ignored. Why wouldn't it be? It was all written by the one person who wasn't busy developing software and there was a disconnect between her values as a project manager and the collective values of the software developers. The net result is a tremendous amount of waste.

The story above is a prescriptive set of procedures that were written by someone who didn't 'get it'. Hussman 'gets it' when it comes to documenting process.

Another point that I've heard him make a few times now is his challenge of the construction paradigm that we follow when we partake in software development projects. The construction paradigm is essentially what we follow by doing a waterfall project with clear roles for architects, engineers, project managers, the customer, and builders. It seems to make sense. The metaphor, conceptually works. The architect provides the vision, the engineers make sure that the vision will work, the builders make it, the project manager tracks it, and the customer decides how correct it is and pays for it. We, as people, have done projects like this for years.

I had a laugh this morning at Caribou when I was talking to my coterie of early risers. One is the head of facilities for a local university and the other is a retire electrician. I asked them the same question that David Hussman asked about the construction paradigm. How often are projects delivered that are complete, on time, and under budget. The answer is almost never under normal circumstances. Between these two guys is close to 70 years of collective building experience.

Granted, the current golden child of project management in the twin cities, the 35W bridge is going to be built well ahead of the 'due date'. The reason that it will is because building it is a priority, and an early completion date is accommodatable through a generous budget and massive incentives.

If we want to use that model for our other projects, be prepared to grow the budget significantly to firm up the schedule.

The last point that I took from the presentation was Hussman's message that a project isn't just the developers and it isn't just the developers and the architects. The project involves a community of stakeholders. One exercise that he showed is a Venn diagram showing the people who build, the people who name value, and the people who track the project. A successful project isn't just a dialogue between a project manager and a developer. It isn't a dialogue between an architect and a developer.

To be successful to all parties with an interest, a project must be an open conversation for the people involved.