Wednesday, March 31, 2004

Ranking I.T. Staff

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.

Tuesday, March 30, 2004

Tampering

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.

Monday, March 29, 2004

Bob Lewis on Standups

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

<!—StartFragment—>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…

Friday, March 26, 2004

What’s wrong with conformance to specification?

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.

Thursday, March 25, 2004

Lawyers, Unit Tests and Performance Reviews

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.