Thursday, September 30, 2004

ASQ Seattle - Oct 14th

I’m going to be speaking to the Seattle chapter of the American Society for Quality on October 14th. Full details. I’ll be talking about my theories of variation for software engineering development, architecture and project management and introducing the concept of a theory of profound knowledge for software engineering as a management and continuous improvement tool. This pulls together a bunch of other things I’ve published this year - Cutter Journal, Motorola S3S, Managing With Cumulative Flow from Borcon and some things from my book such as Critical Chain with FDD plus my insights on variation across layers in the architecture, and condenses it into a single hour for an audience that will be familiar with quality assurance and continuous improvement methods based in statistical analysis.

As usual the slides will be available after the fact.

Tuesday, September 28, 2004

How to Destroy Morale #1

“Soooo Bob, how’s it going?” said Morris. If he only wore suspenders then it could have been a scene straight from Office Space.

“I know you and the team have been working hard this year. You’ve got a great architecture, development is running smoothly and you’ve made the date for all three iterations. The customer is happy too. The early releases have been passing all the tests and our customer has really learned to trust us. There is just one thing…”

“I’m going to need you to”, pausing and slowing his speech, “forget about quality and for the rest of this year, and just hack it out. Forget quality, we need speed!”

Silence!

Bob reaches down and picks his chin up with his right hand, physically lifting it to close his mouth again. After a short pause, he mumbles “Errrr, OK. We’ll see what we can do.” The irony is that Morris had earlier that year stood in front of the executives and said “The bottom line is that quality makes us go faster!” Everyone had smiled and applauded his efforts with agile software development.

So what is wrong with this? Well Morris is a rotten manager but that’s not really what I’m getting at. Morris has destroyed his staff’s morale in just two sentences. But there is more. What’s wrong in Morris’ organization is that they are measuring the wrong thing. At the executive level, they are measuring “code complete.” It is the code complete date which gets reported on the wider program level. Meanwhile, the marketing guys are asking for too much and failing to recognize thorough analysis and objective velocity data. You can’t put quart into a pint pot. So what to do? “Hey, just hack it and as long as we’re only measured on code complete then we’re home free”, thinks Morris.

Well yes and no. Morris may be a natural talent at management misdirection. He successfully sets the developers up for failure. If they miss the date - they fail and he can claim they were “too academic” and “perfectionists”. If they ignore quality and by magic hit the date but they spend months fixing bugs then they fail and they take the blame for the lousy quality. After all, the manager can’t possibly be to blame for unprofessional conduct. Perhaps we can’t blame Morris. He’s just a survivor in a bad organization. He isn’t measured on deployed working code and his senior management are unresponsive to objective data. They always believe that developers can be squeezed to produce more - knowledge work is a soft target, brains are spongy, aren’t they?!

Trading off quality for reduced lead time is a false economy. It will bite you. Trading off quality in exchange for fast hacking is setting a development team up for failure. It’s classic management misdirection. Magical misdirection isn’t up-management, it’s employee abuse. If your manager is an accomplished magician then it might be time to sharpen up your resume.

Monday, September 27, 2004

Management Misdirection

Is your manager a magician? Someone who through slight of hand can misdirect attention away from what is really going on? Can he or she always avoid blame and slip through his/her career unhindered by a failure to deliver? It seems this is all too common. I’m recognizing a number of attributes which contribute to the survival ability of bad managers. I will probably post a series of blogs on this topic but today I want to focus on just one - individual measurement as misdirection.

I’m on record here before stating why I believe that individual measurement is bad. However, I want to put a new slant on it. Bad managers ask for individual measurements because they want to know who to blame, how to identify a scapegoat and separate out a weakest link. Bad managers do not see it as their own failing that they don’t develop their people. They expect the individual to “learn on their own time”, or to “take responsibility for their own career.” Naturally, there is a need for individual knowledge workers to care about their own knowledge - it is after all the tool of their trade. However, managers do have a responsibility too. Better individual performance adds to better team performance.

Developers are right to be wary of managers who ask and require individual measurement. It is primarily a misdirection tactic that the manager can use to avoid blame. This assumes that the manager in turn works for an equally weak manager who will accept excuses, finger pointing and the sacrificing of weakest by measurements gathered. All the same, this seems to be all too common in our industry.

More management misdirection techniques another time…

Thursday, September 23, 2004

Vertical Transparency

One of the interesting things about working at Microsoft is the new openness which manifests itself in many ways. One of these is the encouragement of blogging and the easy to use internal blog facility on MSDN. Blog rolling provides a good way of keeping up to date with what is going on. Here’s my reporting chain to VP level : Keith Rowe, Rick La Plante and Somasegar. As I seldom see any of these people, I keep up by reading their blogs.

Wednesday, September 22, 2004

SeaJUG : The Coad Method and FDD

I planned to re-run my ChAD and Agile Scotland slides about The Coad Method’s Contribution to Agile at the Seattle Java Users Group. However, the talk went so well and there were so many questions that I added an additional set of slides on Feature Driven Development and its Knowledge Management System and reporting mechanisms.

These slides really represent the state of the art in The Coad Method and FDD as it is practiced in North America in 2004. Domain modeling in color is an essential part of the process, earned value reporting is replaced with cumulative flow diagrams and daily standup meetings are a part of the regular routine and replace the weekly secretarial meeting in the original FDD documentation.

[Download the slides in PDF]