Wednesday, April 27, 2005

No More Quality Initiatives

About 6 month’s back we [Microsoft Visual Studio Team System] hosted a meeting of our customer advisory council. This is a hand picked group of people who help to steer our product. They all know who they are, so I don’t need to name names. Many of them read this column regularly. Back then I was soliciting input for our “formal” methodology. During this session, one of our advisors urged me to avoid giving “us yet another quality initiative. We’ve tried them all and people are tired!”

And so, I’m sure he’ll be delighted to hear me say, “Quality initiatives! Just say no!”

The problem with quality initiatives, and their champions, and their change agents, and their sponsors, and their improvement projects and their quality teams and process experts and black belts and green belts and funny handshakes and secret rituals and coded handbooks and group hugs and therapy sessions is quite simply that the improvements don’t last. When the black belt goes home, and everyone breathes out, the regular work force go back to their same old behavior.

QUALITY IS EVERYONE’S BUSINESS!
CONTINUOUS IMPROVEMENT IS EVERYONE’S BUSINESS!

Plain and simple - quality and continuous improvement are everyone’s business. It’s an everyday thing for every employee. Everyone should understand variation and specifically understand how to measure and interpret the variation in their inputs, their rate of input, their working method, their lead time and their rate of output. Eliminating special cause variation should be everyone’s business, every day. Reducing common cause variation should be everyone’s business every day. Suggestions for improvement could come from anyone, any time and be implemented by a local consensus on the shop floor. No need for a central process improvement group or sanction from an ivory tower full of process priestesses.

That’s why in MSF for CMMI(R) Process Improvement, I’ve included daily standup meetings to surface issues and monitor and manage risks, eliminate special cause variation and make it everyone’s business to do so. That’s why we’re dropping conformance to plan and conformance to specification in favor of conformance to process and focus on variation reduction. That’s why we’re encouraging a bottom up, empowered team, consensus model. That allows decentralized decisions to be made quickly. The way to institutionalize continuous improvement across an organization is to make it everyone’s business, every day! The way to deliver an agile process which meets both the original spirit of the software CMM and the letter of the CMMI(R) appraisal model, is to distribute the quality responsibility at grass roots level across the whole organization. Everybody, every day allows quality and agility to walk hand in hand.

Tuesday, April 26, 2005

Microscots! Huh?

The hot topic on the internal British ex-patriot mailing list at Microsoft this week has been this article [subscription required] by Rupert Steiner (a guid Scots name, Ed.) which appeared in the most recent edition of the Scotland on Sunday newspaper. Why the commotion in the belly of the beast? Well to quote one colleague (and you have to read this in your best Dundonian accent) “It’s tripe!” A partake of a good plate of tripe without the cognitive friction of completing the registration and remembering yet another password, here is a convenient link to a PDF of same article courtesy of Media Report.

According to the The Economist and Business Week [who mysteriously coordinate their editorial efforts once again this week], we bloggers leach off the old media. I, therefore, bring you this in the interests of balanced and accurate journalism or is it just my inner leach coming out?

Mr. Steiner visited the campus in February covering another story. His editor asked him to “cover the trip” by getting a second one, so he interviewed a few Scottish emigrants who ply their trade in Redmond. [I can’t help feeling this is a cost accounting nonsense surfacing - a cost per story metric measuring efficiency of story gathering, whilst a high brow paper such as the broadsheet SoS might be better to focus on quality and effectiveness]. Microscots! Huh? We’d never heard of the term until this Sunday. Trips to Vancouver, BC, to buy vegetarian Haggis - we believe that Mr. Steiner made this up as no one will admit to telling him this. And Irn-Bru isn’t banned. The manufacturer A.G. Barr now exports a modified version which meets American regulations. I’ll need to be careful driving over that wriggling SR-520 pontoon bridge on my way to work. I guess the straight due East-West design was getting boring. And then there is “Lake Bill”. Huh? I guess that is where the ducks like the stock options my colleagues contemplate are indeed underwater. And I could go on and on… The whole article is full of errors. Poor Paul Booth who was misquoted in the article had to be taken for pint of ale to mist over his misery.

It seems that Rupert Steiner wanted to write a story about rich kids with yachts, sea-planes and trophy wives but discovered that life at Microsoft is pretty mundane for most of us. We all have mortgages, kids to put through college and pension plans. There was a story in there waiting to get out. The story of why the Scots who work over here wouldn’t be keen to go back. It’s not a new story. It’s a 200 year old story with a new digital twist - Scottish talent leaving home and making good in lands overseas. However, Mr. Steiner didn’t want to search for the real story, instead he wanted to corroborate the story on which he’d set his mind. In the end, he just made it up. Cheap column inches!

My feedback to the editor of SoS - two words - “Fact Checker”!

[Anyohyews fur a wee bit oh tartan trim oan this here website when ah redesign mae banner? G’on geez’a comment…]

Sunday, April 24, 2005

Attitudinals

Part 2 of my reply to Dan Vacanti: following yesterday’s post about gardeners, today I discuss those who simply won’t do the job, those with a posture or attitude that makes them dysfunctional on the team.

It’s easy to argue that the attitudinal is responsible for his own performance. He can choose to change his attitude and start to perform. Were this to happen his performance may well come up to or exceed that of the average team member. As a team, we’d certainly be able to factor his performance into our estimates. We could take him off the bench.

Team members with an attitude problem are usually not difficult to spot. They simply don’t behave according to established team norms. For example, their attendance at the morning meeting is sporadic and when they do attend, they don’t act like a functional team member. The body language (and sometimes the spoken language is all wrong). [Now it is true that there can be the fifth columnist who hides their dysfunction and let it manifest itself as poor quality code or very slow code production. This is harder to spot and requires intelligence from the grapevine - best gathered through the managing by taking coffee or managing by having lunch approach].

So, once again its the managers responsibility. The manager has to talk to the individual with the attitude. Make it plain to them why they need to change and that the manager will not tolerate it or bend the rules. There can be no exceptions. It’s like parenting.

I’ve seen all sorts of attitudes. The most common perhaps is the “I’m God’s gift to software engineering” often coupled to the complaint that “the team doesn’t give me any of the cool stuff to work on”. The advice: try doing the mundane stuff and doing a good job of it and earning the trust and respect of your peers. If you do the mundane stuff well and they learn to trust you then they will realize that you can help them to be successful and you will be given the harder, sexier tasks.

The second job is once again to take the attitudinal out of the estimate. Don’t have the rest of the team carrying the burden. Treat them as bench slack or give them individual tasks to perform that are off the critical path of the deliverable. This has a side-effect. The attitudinal is isolated from the team and can never be integrated.

By maintaining a firm stance on expected norms, the attitudinal will either (a) change his attitude, earn the trust and respect of other team members and re-integrate as a functional team player, or (b) self-select out of the organization.

So, to Dan’s point, I believe that the individual is responsible for their professionalism and their discipline, for their attitude towards their job, the business and their fellow team members. They can choose to work functionally with the team or they can strike a pose and behave like a spoiled toddler. But when it comes to writing code, they aren’t responsible for their performance. That will always vary according to the techniques employed. Improving the techniques, reducing the variation and increasing the mid-point (or mean) productivity is the responsibility of the whole team and the manager. The team member simply has to agree to be a part of the learning organization. To strive to be professional and to show a willingness to learn.

I’m separating out productivity from dysfunction. When as managers, we couple the two together, we expect miracles. We expect that somehow magic will happen and the team will learn to use new techniques and become more productive with lower variation in productivity. But this can never happen on its own. The team will never take a risk to change because of the J-curve effect and general fear of change and feeling of insecurity whilst adopting new techniques. It needs the manager to give permission to change. To provide coaching and encouragement. To create a space and to provide air cover whilst the team works through the J-curve. By learning to treat dysfunction as a separate management problem, we free ourselves to focus on better productivity.

Saturday, April 23, 2005

Gardeners

So Dan has challenged me, following Friday’s post, to explain what to do about underperformers. [I had to edit Dan’s comment because it got a little close to a real HR issue from a few years ago. I purposefully didn’t reply to it directly either.]

I think there are two types of under performers - those who simply can’t do the job, and those who won’t do the job. I’d like to deal with the first type in this post.

“There are a lot of gardeners in IT”

Jeff De Luca uses this expression a lot. It dates from his years with IBM and a time during the grim dark years under John Akers, whilst the World economy was reeling from the 1987 stock market bust and the later property bubble, and IBM was laying off people left, right and center. Jeff in discussions with his boss at the time, had been reassured that “there was always work for good people” and that “there are a lot of gardeners in IT” and that they might soon be “mowing lawns around Melbourne” once again.

Dan will recall the time we interviewed a tree doctor for an $80 per hour contingent staffing position. His previous IT experience amounted to less than 3 years at a large wireless company as a contractor doing Java development, and several years in the Cascade mountains heeling sick trees. Following the interview, where he couldn’t describe the difference between the == operator and the .equals() method, I advised his agent to advise him to go back to his true profession. In general, I try to avoid the gardener problem by not hiring them in the first place.

The employee who can’t do the job is the responsibility of the manager. It is the manager’s failing. The employee is still trying to do her best - even when it isn’t nearly good enough.

As Dan rightly points out, a gardener on the team, can destroy morale. When you inherit a gardener from a previous manager, it creates a problem. You identify gardeners primarily from a “managing by walking about” strategy. For me this includes the sub-classes of “managing by having lunch”, “managing by drinking coffee” and “managing by playing ping-pong or foosball”. Many of my former staff will recognize these techniques. Step 2 in dealing with a gardener is to stop estimating based on their productivity. If the team has effectively benched the gardener then as a manager you can’t count them as part of the productive team when estimating projects. By eliminating them from the estimate, you stop the team from carrying the burden through extra heroic effort. That just leaves the morale problem. The gardener has to be managed out. As anyone working in the USA’s Fortune 500 knows, this is a tricky problem and it takes time - sometimes up to 18 months.

I’ve mentioned before that I like to measure individuals on secondary contributions. For example, “become the language lawyer on unit testing and test-driven development and transfer your new knowledge to the other team members. Build their respect as the authority on TDD and make yourself the go to point for advice on TDD and unit tests.” Now that is something I can measure. A gardener will never be able to accomplish this task. Managing the gardener out is the responsibility of the manager. Coaching the team quietly and privately to be patient and to understand the difficulty of achieving this is how to deal with the morale problem.

In summary, the “can’t do the job” employee is not responsible for their performance. The manager is responsible. The manager should never have hired them in the first place.

Friday, April 22, 2005

Flipping Metrics

No I’m not swearing!

This is a serious post about the difference between management by objectives (or conformance to plan commitments) versus management of process variation. The management scientists will recognize this as the Peter Drucker versus Edwards Deming debate [Drucker and Deming actually roomed together at one point in the early 50’s where this argument started. Drucker is said by Deming to have capitulated eventually.] Yet others may see this as a Crosby versus Deming debate. And in many ways the Crosby idea of measuring quality by conformance to spec, isn’t so far removed from the Drucker idea of set a target, get a commitment from an accountable person and then hold their feet to the fire until they deliver.

Back in 2001, Mac Felsing and Ken Ritchie [both of Process Exchange] were working with me at Sprintpcs.com. Whilst I was managing a dev team amongst other duties, they were working for the newly appointed Senior Director of Engineering in his process improvement group. They were tasked with building adoption for FDD across the business unit. One day they set up a meeting with me, and when they arrived, they were filled with frustration. The boss had asked them to start measuring individual performance on feature commitments and report conformance against commitment.

[A brief sidebar. I’ve written before about my dislike for the “planned date” in the feature milestones in FDD. It’s a topic about which Jeff De Luca and I disagree. I see it as management by inch pebble objectives and I don’t like it. I prefer to measure feature completion velocity. At most I only ever ask for chief programmer work package completion milestones and then its a feature team commitment against a batch of work.]

I’m on record as being very anti individual measurement. The likelihood, that measuring individual feature milestone commitments and using them in performance reviews would blow an FDD team apart and destroy productivity and morale, is very high. It’s a fundamental tenet of FDD that you never, ever, measure individuals. Heck, FDD doesn’t even monitor individual tasks - only features constructed by a team. I had to save the senior director from his own ineptitude. So I suggested that they flip this metric on its head and take it back to him as a report on our ability to estimate and a measure of the variation between planned and actual. Over time, we should as a team and an organization be able to show that we are learning and that this learning manifests itself as reduced variation. Under no circumstances should we use this data to evaluate individuals performance.

[I also promised myself that I had to get out from under this new boss. Five months later I quit Sprint altogether.]

The executive request was for management by objectives (MBO) and conformance to plan or individuals would pay the consequences. [Management knew that layoffs were coming the following year and they wanted to identify the weaker players with objective data.] The alternative to MBO is management of process variation.

Lesson Learned. In MSF for CMMI(R) Process Improvement, I am taking a management by reducing variation approach. Commitments are based on ranges derived from measured variation. The standard metrics and reports show the process variation in productivity, velocity and quality. It is through these mechanism that we undo the heavyweight, document centric, trustless, fear driven process designs out of CMMI.

[To close out this post, Deming firmly believed that individuals were almost never responsible for their own performance but rather victims of the variation in the tasks that they had to perform. Only if the organization could learn to understand and reduce its variation would performance improve. Now there is a radical idea - programmers are not individually responsible for their own performance!]