Jeff De Luca follows my recent post on HR Myths #3 with his own version of what's wrong with the process of ranking I.T. staff. Actually the method he describes is not identical to the methods I have seen in two large American companies but it is similar enough for you to get the picture.

H.R. applying the bell curves and normalizing within levels is not just sub-optimal it is often plain unfair. It assumes a related normalization of staff numbers and skills and performances by level across the organization. You can't just say we'll promote 3 associate programmers this year and 2 programmers. What if the associates mostly performed poorly (can easily happen if the hiring was not good). 3 associates get promoted no matter what. What if there is a much higher percentage of outstanding programmers then there is outstanding associate programmers this year? (again, can easily happen). They are penalized as only 2 will get promoted no matter what.

As Johnnie C. commented on my HR Myths #3 post...

Wow. Is this a common scheme in larger companies? You make very good points. Setting up a scheme like this is silly. Just another reason that I'll try to avoid working for larger corporations.

I've been doing a lot of reading about Control Charts and Statistical Process Control recently - of which more to come later this year. One aspect of managing using control charts which was first articulated by Walter Shewhart, the father of the method, is a phenomenum known as "tampering". Tampering is management by reaction without recognition to the natural variance which occurs in a process. Tampering is amplification of common cause variance to the point where an otherwise controlled system can become chaotic.

It is a fault of inexperienced and untrained managers to react to common cause variance - often in a heavy handed fashion. Their actions, regardless of what, result in tampering with the system and consequent amplification of variance turning it into an assigned cause problem. It so happens that the assigned cause is the management intervention.

This paper by Gemba Research advises Lean practitioners to beware of tampering because they might just make things worse rather than better.

Deming (originally Deming's teacher Shewhart) said "tampering" is the changing of a process in reaction to just one instance of its output. Tampering is depending on intuition and common sense. Deming demonstrated through many examples that this can often make things worse, not better.

Bob Lewis was asked if integration testing was the right time to start daily standup meetings on a project. Here is his reply...

In general, I prefer weekly status meetings for projects as they let the daily ebb and flow of work average out without letting issues age too long. I think of daily standups more for operations, where it makes sense to review how the previous day's production went so any problems can be wrapped into the schedule.

Read the full article...

I found this wonderful quote in Wheeler and Chambers, Understanding Statistical Process Control. It's from the teachings of Edwards Deming and it sums up what I've been preaching about probabilistic versus deterministic approaches to software engineering. I feel it also very succinctly sums up the difference in philosophy between traditional rigorous software methodology and modern agile methodology [even though this book was written about manufacturing].

The engineering concept of variation has the concept of meeting specifications.
...
Management has been trying the [engineering concept] since the beginning of the industrial revolution. After almost 200 years, the goal has not been met. The legacy of focusing solely upon conformance to specifications has been a lack of progress. There is no reason to believe it will be different in future.
...
Thus we come to the paradox. As long as management has the conformance to specification as its goal, it will be unable to reach that goal. If the actions of management signal that meeting specifications is satisfactory, the product will invariably fall short.

Wheeler, Donald J., and David S. Chambers, Understanding Statistical Process Conrol, 2nd Edition, SPC Press, Knoxville, Tennessee, 1992, pages 11-12.

What do language lawyers, unit tests and performance goals have in common?

Answer: They might be the ideal combination to help differentiate staff for next year's performance review!

Fred Brooks' introduced the idea of a Language Lawyer on page 34 of The Mythical Man Month as one role within a surgical (or Chief Programmer) team. Feature Driven Development adopted the lessons this not only with the well known Chief Programmer role but also with the Language Lawyer as a supporting role. Stephen Palmer describes this on page 30 of A Practical Guide to Feature Driven Development.

Typical language lawyer roles in an FDD team include a Java language lawyer, a design patterns lawyer, a persistence layer lawyer and a domain modeling (in color) lawyer. However, more recent developments in agile techniques have created the need for another language lawyer role - the Unit Test Lawyer. Unit testing has come along way since the introduction of JUnit and CruiseControl. Now a unit testing expert is required to understand best practices in design-for-testing, use of Mock Objects, and patterns for using them.

Generally, language lawyers are not dedicated members of staff on an FDD team but developers or chief programmers who also carry a specific specialist role as an expert in one area. By giving specific team members a specialist role as a lawyer for a specific technical area, the manager creates the opportunity with which to differentiate for the purposes of performance reviews. The team will have specific goals and every member is expected to pull their weight as a functional member to achieve those team goals - delivery dates, production rate, quality goals. However, a specialist role such as Unit Test Lawyer gives an individual a chance to shine, build respect and trust from colleagues and show off their ability to their boss.

Individual team members can be set specific goals and behavior objectives which may include: attending specialist training, attaining certification in the specialist area, keeping up with industry trends and new developments in the technology, knowledge transfer, maintenance of a standards document used at design and code inspections, and coaching of fellow team members. By making the language lawyer responsible for sharing and communicating, the whole team can benefit from the individual contribution. The adoption of the techniques across the team and the code can be measured. The team members who work harder to learn, communicate better and articulate their thoughts best, will generate the most shared knowledge and the greatest team benefit.

For the manager it's a win-win-win. The individual gets to develop and show off worthwhile new skills. The team gets to learn and use new and better techniques which help to maintain or improve production rate, quality and lead time. The manager gets a method for measuring individual performance which is aligned with the best interest of the team, the customers and the stock holders. It may even be possible to survey team members for their opinion on whose individual contribution made the biggest difference. This allows the manager to place the rewards in line with popular opinion.

Around this time of year, staff are being paid annual bonuses and receiving merit increases in basic pay. These will have been based on the results of a performance review which took place in the first quarter. The performance of the individual will have been assessed against some goals and a rating - usually on a scale of 1 through 5 - will have been allocated. For many managers this process is one of the hardest things they will ever do. Why? Quite simply, the rules in most big companies are not aligned with the best interests of the employees, the customers or the stock holders.

The first fallacy is the concept of an equal distribution of performance across a team - someone has to get a 1 and someone has to get a 5. The idea is based on the statistical bell curve normal distribution. However, when your statistical sample is (for example) less than 20 then any statistician will tell you - you do not have a basis for a normal distribution.

The second fallacy is that all teams perform equally and that someone from every team deserves a 1 and that equally someone from every team deserves 5.

The double combination of these "buckets" for performance rating is that ultimately a manager has to have that chat with some poor unfortunate employee. "Well Joe, as you know, we both reviewed your performance and agreed that you had given everything asked of you and more to our team performance this past year. As you know, our team delivered on its promises. In fact our agile techniques mean that we are the highest producing team in the company both in productivity and efficiency/costs. Your contribution was key to this success. However, as you know, this is a strong team and all of your colleagues contributed strongly too. You know how the performance rating system works, and unfortunately after discussions with other managers in the business unit, I regrettably have to give you a 4 rating. I managed to argue that no one on our team deserved a 5. Consequently, and I am ashamed to have to report this, you will not be receiving a pay rise this year and your bonus check is a little light. I want you to understand that this does not reflect how I feel about your performance and I will try to make this up to you in other ways. However, the company rules force me to make decisions - some that I am not comfortable with. In a team of fast runners, you are being rated as the slowest this year. Hopefully next year it will be different."

What is the effect of this? In the worst case, the individual goes out and polishes up their resume and leaves the company soon afterward. In the best case, they begin to become defensive. They don't share so readily with the team. They are keen to be given individual credit for their contribution. After a few years, the whole team is doing it and they are no longer a team but a group of fearful and defensive individuals.

Existing HR policies discourage team work, discourage knowledge sharing (death in a knowledge industry), and encourage sub-optimal even divisive, political behavior. If you don't want to get that bottom rating, better keep in with the boss, better get noticed, better not give selflessly to the team (or the customer, or the business, or the stock holders). Better still why not make it difficult for your colleagues to run as fast as you? Why not spend your energy trying to hinder the other runners in the field?

In sports, when a team wins a championship, everyone on the team gets the medal and the bonus payments. It's time we started to remember that when we reward our knowledge workers.

Last week at the USC CSE Annual Research Review, I used this Cumulative Flow Diagram to illustrate how I track progress on agile projects and how I use it to make informed management decisions.

Philippe Kruchten made an observation that the chart showed an almost linear progress. In fact it truly isn't the usual S-curve that I wrote about in the book. What is shown here is 1 week of modeling (Feb 10 through Feb 17) then 5 weeks of coding. The coding achieved a steady progress of around 45 Features per week. [Note: the project is now code complete]

Kruchten's observation was that there must be something enabling this linearity. His suggestion was that the modeling technique and the use of the domain model, as a planning and communication tool throughout the project, was probably the enabler of the linear progress. In other words, the development team were able to use the model such that they could choose work which would not interfere with other on-going work avoiding dependencies between programming tasks. I think that there is a lot of merit in this view. The Domain Neutral Component [PDF] techniques of Peter Coad and Stephen Palmer are very powerful and allow clear progress to be made without rework or refactoring.

However, there is another reason why the chart shows linear progress and it is much simpler to explain. On the project shown, the team were very good at surfacing issues and running them down before they hit the critical path and slowed down development. This was achieved through the daily standup meeting or the Morning Roll Call of Features which I detailed in The Coad Letter #101. Keeping a visible issue log, cross referenced to all the Features affected by the issues, updated ever day at the standup, really focuses the minds of project and program managers. Getting issues resolved early produces tangible results which can be measured by the absense of the S-curve effect and the consequent higher productivity.

Some reviews of the book are beginning to appear on sites other than Amazon. This one is from Lasse Koskela who co-authored a paper, "The Underlying Theory of Project Management is Obsolete", which I heavily referenced in Chapter 6 Agile Project Management.

All in all, I find Agile Management for Software Engineering to be a book with a solid message: how to better manage a software business. Considering the state of practice in the industry, I'd say this is a must buy for any manager or executive.

Read the whole review...

This weekend sees Lou Dobb's Money Line at odds with The Economist. Well there is a surprise! Lou Dobbs' has positioned his 2004 editorial firmly in the anti-offshoring category in an attempt to get the incumbent president re-elected. What sets these two articles apart is that Professor Terry, Answers on Outsourcing, is arguing for what he sees as a local temporal optimum for America and Americans whilst The Economist, Smile, These are The Good Times, Truly!, argues for a global optima which is in the long term best interests of the planet and its population.

Sadly, I fear that neither article is particularly strong. Terry's view...

Consider the number of new non-native Ph.D.s that leave our universities each year; consider our low rank in the education of mathematics and the sciences; and consider the large number of international students enrolled in our most difficult technical degree programs at our most prestigious universities.

 ...is particularly weak when you consider that the American government has a deliberate brain-drain policy intended to attract top foreign students and academics whom it hopes will stay in America making its economy stronger to the detriment of the individuals home country. [Viz, your author and publisher of this site]

Terry also argues that America does not hold an advantage in ideas, innovation or entrepreneurship. This has been widely refuted elsewhere and writing as someone who gave two startups a "good go" in Scotland in the 1990's I have to say that the climate in the US is much more pro-innovation and entrepreneurial activity.

The argument that we will create new jobs in highly paying fields simply is not true. We have no comparative advantage or superiority in innovation. To assume that we are inherently more creative than our foreign competitors is both arrogant and naive. We are currently empowering our competition with the resources to innovate equally as well as we.

Meanwhile, the piece in The Economist points out that the American economy has been in recovery for 3 years and that the jobs problem is merely cyclical...

As The Economist has recently argued - though in the face of many angry readers - the jobs lost are mainly a cyclical affair, not a structural one. They must also be set against the 24m new jobs created during the 1990's. Certainly, the slow pace of job-creation today is without precedent, but so were the conditions that conspired to slow a booming economy at the beginning of the decade. A stockmarket bubble burst, and rampant business investment slumped. Then, when the economy was down, terrorist attacks were followed by a spate of scandals that undermined public trust in the way companies were run. These acted as powerful headwinds and, in the face of them, the last recession was remarkably mild. By the same token, the recovery is mild, too. Still, in the next year or so, today's high productivity growth will start to translate into more jobs. Whether that is in time for Mr Bush is another matter.

 ...hmmm! Does anyone else believe that this may be naive?

In the first of my ad hoc series on goal congruence and alignment with shareholders interests, I would like to introduce you to the prairie chicken. This is not my work but that of Bob Lewis who writes the Survival Guide column for InfoWorld. Bob's 1999 book, IS Survival Guide is one of the best books on management - not just for software development but for any manager in an internal IT department. The following is an extract from page 15 which I quote in full...

Prairie Chickens and Old-School Executives

"Modern American business executives are expected to visualize, promote, and lead change. This is profoundly different than the experience of American business even twenty years ago, when executives had a lot in common with the male prairie chicken. Let me explain.

Prairie Chickens are less elaborate cousins of the peacock, living in places like the plains of western Minnesota and the Dakotas. Every spring in the hour or so around dawn, male prairie chickens congregate in areas about the size of an average lawn called "leks," claim personal territories, and do the prairie chicken dance. It's an amazing sight.

The central territory is the smallest - about three feet across. Further from the center territories get bigger but less desirable, as least as defined by female prairie chickens, which wander through the lek choosing which males will be allowed to fertilize their eggs. Proof: The central male gets about 90% of the matings.

For as many years as biologists were aware of the prairie chicken dance, they assumed the central male was the toughest, nastiest bird for miles around. At least, they did until a graduate buddy of mine named Henry MacDermott looked into the matter. Henry discovered something completely unexpected. Male prairie chickens don't fight hard to carve out their territories, defending them against all comers. As the years pass, males sort of drift to the middle. There's some competition, but for the most part the males who survive long enough - those that don't die of disease or being eaten by foxes - end up near the middle.

When I left graduate school to enter the world of business in 1980, I often found myself wondering how some of the executives I encountered managed to get to their positions of influence and authority. Most of them treated important decisions the way you and I would treat a rabid ferret: something to be watched carefully and avoided while someone else foolish enough to stick his or her neck out deals with it.

One day I figured it out. In the early 1980's, American business was suffering from thirty years of complacency, succeeding more from momentum built up in the 50's and 60's than from current quality. Japan Inc., was kicking American business in the shorts, but our executives had acquired their positions the previous decade or two.

Executives who took risks that failed were punished for their failures, and businesses succeeded nicely without taking any risks at all. Because failure was punished and success could be achieved by sitting back and watching the money pour in, the executives who made it to the top were those who avoided mistakes, not those who made bold moves.

American executives in other words, were prairie chickens!" [Lewis, Bob, IS Survival Guide - Changing CIO form 'Career is Over' to 'Change is Outstanding', Sams Publishing, 1999]

I personally feel that this is not an old problem. There are plenty of executives who were inflated in the bubble in both high technology and telecommunications who qualify as fully fledged prairie chickens. How many do you know? Perhaps you work for one?

It looks like I've been asleep at the wheel for almost two weeks and haven't posted anything. Actually, the constraint has been the family PC which hosts my CityDesk weblog application. My wife has been using it to do the family taxes. By the time she finished each night, I was too tired to post. So it has taken me a week to post this news about a new private members plan for House of Representatives Bill which will penalize US companies for moving jobs offshore.

The proposed Defending American Jobs Act was written by Rep. Bernard Sanders, Independent of Vermont, and will be co-sponsored by about 50 other representatives, including Republicans Ron Paul of Texas and Virgil Goode of Virginia.