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

|

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

|

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.

|

I talk a lot these days about statistical process control and the concepts of common cause and special cause. Sometimes the statistics scare people off. However, you really don't need to be an expert in statistics to recognize special cause variation. Take today for example...

I got up with a plan to bike to work. I got ready, packed my rucksack with my towel (no towel service in the Microsoft locker rooms any more) and my clothes (no permanent lockers available in my building) and I actually left the garage on the bike. Ptup, ptup, ptup, ptup, ptup, ptup. Arrrgghh! A flat! How did that happen? Slow puncture! I found a staple stuck in the tire and assumed that was the cause. I quickly reopened the house and the garage and changed the inner tube. Setting off again, now much later than I wanted to be, I did eventually get in to work 1 hour 10 minutes later around 8.45am. The last two miles were accompanied with a ptump, ptump, ptump sound. Strange, I thought I don't ever recall anything which would have flat spotted the rim. Perhaps it's a bulge in the tire?

Hurrying to shower and change, I didn't investigate further. I then worked late because I didn't get logged on until 9am. I went down to the locker room about 5.45pm, got changed and walked out to unlock my bike. Aaarrrggghhh! Another flat!

Lightening doesn't strike twice - as the saying goes. In seven years of owning that bike, I have never had a puncture riding around the city. It's a mountain bike. It's tough and has big thick tires. Riding in the Malaysian jungle - yes, I've had flats - but never in the city, in seven years! So what is the sigma calculation on that? Who cares? What is blatantly obvious that something that hasn't happened in seven years, suddenly happened twice in one day. That's clearly a special cause variation. So Shewhart would tell us to go look for the assignable root cause.

Closer inspection of the tire revealed the problem. The tire wall had worn through on about a 2" stretch. It wasn't protecting the inner tube and clearly, the tube had snagged against the rim. Closer forensic inspection showed that the hole in the tire lined up with the frayed lining. I repaired the puncture and crossed my fingers. Returning home relieved that there were no further incidents but much later than I wanted at 7.15pm, I inspected the other inner tube from the morning. Yep, there it was - a pin sized whole exactly in the same place as the more recent one this afternoon. The root cause had been identified. Time for a new tire - and a couple of new tubes!

|

I'm just back from the Borland Developer Conference in San Jose. This year it seems everybody loves Borland. Both Microsoft and Sun were main sponsors despite the fact that both companies have competing products. Rivals like Borland because developers like Borland. So many of us grew up on Borland tools over the last 21 years. Both Sun and Microsoft rely on Borland to bring developers to their platforms - and platforms are much more important than tools. Hence, everybody loves Borland!

Of much more interest to the readers here, will be the new Borland strategy - Software Delivery Optimization (SDO). Described by Dale Fuller, CEO, as "like ERP for software development." It seems to me that Borland really gets it. They have realized that the new agile movement is all about quality assurance and right first time engineering and that agile project management is a paradigm shifting opportunity to displace the Gantt chart driven project centric management methods of traditional software engineering.

It was two years ago that I first described FDD project management as "more like MRP for software engineering than Gantt chart scheduling." What was even more amazing about Boz Elloy's keynote last Monday were the key bullets in his message

• Quality Assurance (as opposed to Quality Control)
• Transparency
• End-to-end Traceability
• Productivity
• Governance (and optimal resource allocation)

It was amazing to me to hear a senior executive at a major tools company echoing the message I've been preaching at conferences this past year. However, at least half of the Borland vision is just that - a vision. It's not real product in 2005. However, Borland are the first of the big tools vendors to be actively talking about end-to-end traceability and good governance and they are the loudest and most articulate on quality assurance and transparency.

|

In Feature Driven Development, we use code reviews as a method of quality assurance and team learning. Feature Teams form under a Chief Programmer to develop a batch of Features in a Chief Programmer Work Package. The purpose of batching is to absorb the overhead - what Paul Szego termed "administrivia" - in a Feature. This would include the domain walkthrough which requires resources to be scheduled, as well as project tracking meetings and the design and code reviews. Doing this on a Feature by Feature basis would be cumbersome and inefficient. CPWP's enable efficiency in the development tasks.

The code review is intended to be executed by the Feature Team and allows each of the team to learn from other members how their code works. It propagates the best knowledge of the entire project in terms of architecture, design patterns and coding guidelines and the result is both quality assurance (reduced defects and high internal quality) and learning. The code review process helps to raise all the developers on a team to the standard of the best.

Some who believe they are running FDD projects let code reviews degenerate into Chief Programmer code re-writes. In this form of review, the CP simply takes the code off each Feature Team member and re-writes it with them in a pair programming fashion. This may deliver the desired quality assurance in terms of reduced defects and improved internal quality. However, it will not deliver the desired learning and it will not raise the standard of the team to that of the best. Rather the effect will be to freeze learning and stem further improvement. Furthermore, the process of code re-writing is demoralizing. The long term effect will be to undermine trust and respect in the team. Developers will lose the sense of pride in their work and the result will be greater defects produced at a slower velocity. Resentment against the chief programmers may develop and the team will over time become dysfunctional.

Code re-writing may seem like a good idea. It is simpler to schedule and uses fewer resources. It may also seem efficient and psychologically pleasing to the geekier of chief programmers. But ultimately it is soul destroying. It eats at the core of a project team and destroys its ability to create value. Peer reviews may be hard to do properly but code re-writes are not the answer. If you can't get peer reviews right for whatever reason then go the whole way to the other extreme and pair program. It has the same effect - improves external and internal quality and enables learning. It also encourages developers to take pride in their work. Pair programming does not carry with it the demoralizing side effect of the code re-write by the super uber-being of the arrogant chief programmer. Chief programmers have a responsibility to lead and leadership in knowledge work means in part teaching. A chief programmer who does not teach is not a chief programmer just a team lead directing others.

|

I'd didn't get through my posts on the work of Peter Drucker in August. I simply ran out of energy and fell off the blogcycle. So Drucker month runs over into September. Hey, we're adaptive at agilemanagement.net ;-)

Peter Drucker doesn't like planning much. Here is what he had to say in 1996 writing in "The Effective Executive,"

"Most discussions of the knowledge worker's task start with the advice to plan one's work. This sounds eminently plausible. The only thing wrong with it is that it rarely works. The plans always remain on paper, always remain good intentions. They seldom turn into achievement."

Drucker also had something to say about adaptive process versus plan-driven processes back in 1985 when he wrote "Innovation and Entrepreneurship." He completely predicted the shift to agile software development methods and adaptive just-in-time planning.

"'Planning' as the term is commonly understood is actually incompatible with an entrepreneurial society and economy....innovation, almost by definition, has to be decentralized, ad hoc, autonomous, specific and microeconomic."

Drucker's argument is based in the idea that in a knowledge worker economy, a competitive edge, a differentiator, is achieved by bringing new ideas to market faster. This is similar to Patterson's concept that product design is a process of information discovery - in other words knowledge creation - and Reinertsen's later observation that design in process is perishable. Drucker was basically arguing this in 1985. He had worked out that innovation was a product of knowledge creation from knowledge workers and that such knowledge had a half-life. Because of this the nature of the economy was changing and the paradigms, we had used to manage the old economy of mass production, were obsolete.

|

Quality is defined by the value a customer derives from a product or service. It is not defined by conformance to specification. Last night I learned this lesson as I rejected my new car - for which I have waited 60 days - and left it lying in the dealer lot. The problem wasn't a clunky gearbox, or an ill fitting door. In fact I never even sat in the car. I didn't even have the keys in my hand. I could tell from 50 paces away that the car lying in the lot, wasn't the car that I ordered. Sure it was the right color and the right model but a key factory fitted option - the roof rack bars - was missing. Without these the car wouldn't serve one of the two purposes for which I was buying it: purpose 1 - commuting; purpose two family vacations and weekend trips in comfort. With a child (or two), a dog, camping gear and several bikes, a roof rack is essential equipment. So the salesman was left to scratch his head and wonder where it went wrong. The sales manager lost an end of month sale to close out his figures for August. And, I was left spending 2 hours of my evening family time, sitting in a dealership, tired and hungry while we tried to sort the mess out and agree what would happen next. Disappointment all round.

What will happen to the car I ordered? Well it will be sold before the week is out. 2 weeks ago the dealers inventory manager told me that he could have sold it five times over. It's in an unusual but in-demand color and while it showed on their inventory, several other dealerships had asked to swap it as they had customers who wanted one. Meanwhile, I'll still be commuting by bike and bus across the 520 to Redmond.

|