Wednesday, March 24, 2004

HR Myths #3 - Performance Buckets

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.

Tuesday, March 23, 2004

Getting to Linear

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.

User Stories Applied

Mike Cohn was a great supporter of my book during and after its development. Mike’s latest book has just been published. So now I get a chance to reciprocate. User Stories Applied for Agile Software Development is an attempt to bring repeatability and tranferability to the development of requirements in eXtreme Programming. Mike’s goal is ultimately to make estimating and planning more accurate. The book pulls on Mike’s experience with Scrum and there is plenty of advice on how to report progress using Burndown Charts. I haven’t had a chance to read much of the book yet and I will report back once I have.
Meanwhile, you can purchase User Stories Applied through my affiliate link with InformIT for a stunning 30% discount. Buy it now!

Friday, March 19, 2004

Lasse Koskela Review at Java Ranch

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…

USC Annual Research Review

Here are the slides I presented at the Barry Boehm’s Annual Research Review for the USC Center for Software Engineering in Los Angeles, CA this week. I participated in a panel session on agile experiences but chose to focus my slides as a position statement for the workshop the following day. Hence, these slides focus mainly on what has been on my mind recently - since I wrote the book. There is one slide at the beginning which created a context for me to talk briefly about Feature Driven Development.

Critical Factors for Success [PDF 146K]