What are you rewarding?

9 comments:

We don't pay bonuses

It is nearing the end of the year and we at LeanDog are wrapping up our fiscal year. We're looking at the potential tax benefits of spending some of our reserve and we're mulling over other ideas related to the spend of money. We are not, however, discussing our bonus objectives. We aren't discussing them because we don't have them. I, for one, am happy that we don't.

Plenty of companies have bonus objectives. Many of those companies are spending a great deal of time (and money) trying to make sure that those objectives are met (or at least appear to be met). To some, this sounds like a good idea. To me, it sounds like rampant dysfunction.

Bonus programs often fail

I recall working with a customer who was very keen on ensuring maximum utilization of their "resources". Each manager had utilization targets with associated fiscal incentives. Meet the target, get a bonus. Fail and get none. Simple enough.

But this entire system proved to be counter productive and misguided.

The metric becomes more important

Managers were spending a great deal of time monitoring the time-sheets of their employees. Managers would download the data and run it against various formulas to make sure they were within limits. If an employee's ratio was off, the manager needed to figure out how to allocate the time to get the ratios correct, discuss it with the employee, and validate the changes once they were made. In many cases, the time was tracked under the wrong category because the task that was clearly most applicable was not categorized in accord with the allocations. The time was instead allotted to some other task in order to get it into the right category. Much work was done to make sure the allocations were met. The accuracy of the system degraded over time. People's hours were no longer tracked to the actual task, but instead tracked to areas that kept the ratios favorable.

Good work is sometimes punished

Among the development teams, there was one that delivered to the delight of the customer every time. Their bug count was extremely low. Their customer was actively engaged in setting priority and was aware of the status at any given time. The team worked together, communicating, collaborating, and making things happen. They delivered more frequently with higher quality than any other team in the department. But their ratios were off. For a utilization target of 90%, they were consistently floating at 85%. They were tracking their time honestly. Their manager refused to doctor the time while all other managers were complicit in time doctoring. Directors were given incentives for the percentage across all their teams. So unless the other teams fudged enough to beat the target by a few percent, the director wasn't going to make the bonus mark.

Ultimately, the manager who delivered and was honest failed to meet the bonus objective and was both paid less and reprimanded for failure to meet the company standard. Other teams failed to deliver anything in a year, but showed the proper allocations and were given a bonus.

A raise is a bonus that lasts forever

My advice to managers, directors, and executives who want to pay bonuses? Don't. If you must do so, then break it down based on each employee's income. If you have a top performer, don't give them a bigger bonus, give them a raise. Think of a raise as a bonus that lasts forever.

Lost in Translation - An Agile Game

7 comments:
Timing:
One hour, but this can be extended or contracted as needed.

Materials:
Pencils, paper, timer, and a collection of pictures (royalty free).

Instructions:
One person is the facilitator. The facilitator keeps time, makes sure the rules are being followed, and facilitates the retrospectives.

The rest of the people are broken up into teams of three; a product owner, an analyst, and a developer. The product owner is provided a picture chosen at random from a collection.

The product owner is not allowed to show the picture to anyone else.

The team needs to create a hand-drawn depiction of the picture.

Round One:
Requirements (10 minutes)
  • The developer leaves the room.
  • The product owner describes the picture to the analyst.
  • The analyst captures the requirements.
  • The analyst may ask as many questions as needed in the time allowed.

Delivery (10 minutes)
  • The developer returns and the product owner leaves.
  • The product owner needs to remain nearby for questions, but not in the room
  • The analyst provides the written specification to the developer.
  • The analyst may provide answers to any of the developer's questions.
  • The analyst may ask the product owner as many questions as necessary, but must leave the room to do so.
  • The developer draws the picture.

Retrospective (10 minutes)
What went well? What did not go well? What would have made it better?

Round Two:
The product owner is provided another random picture.

Delivery (15 minutes)
  • Everyone stays in the room.
  • The analyst and developer work together to create the picture.
  • The analyst and developer may ask the product owner as many questions as necessary.

Retrospective (15 minutes)
What went well this time? What did not go well? What would have made this better?

How does round one compare with round two?

Learning Points:
  • Working face to face is easier and more rewarding
  • Working together in real time produces a better product
  • Documentation is less valuable than communication
  • Roles are not so important when it comes to getting the work done

The Three "R"s of Clean Code

4 comments:

Establishing Code Quality Standards

Mandate via Manual

A client of LeanDog was looking for a way to introduce code quality standards to their development teams. There had been a few meetings prior to LeanDog's involvement. The prevalent line of thinking was to draft a standards manual for dissemination to the teams. This would consist of a comprehensive set of rules and clear specifications to which all teams need comply.

There was a good deal of discussion around people's historic failure to read and follow this type of documentation. Such failure to comply mandated policing. There were a number of possible solutions; training, financial incentives, managerial targets, code reviews, code audits, and code compliance tools.
Ummm, yeah. Don't do that. Ok?
Keep it as simple as possible. Assume the people you work with are competent, capable, and want to do their jobs well. Developers tend to take personal pride in their work, as do most people. I've yet to meet anyone in the field who proudly (and seriously) proclaims, "I do my job poorly."

This kind of governance should not be necessary. If it is necessary, then remember that your people are competent, capable, and want to do their jobs well. Failure to meet a standard says more about the standard than the people.

It is likely the problem is the manner of communication and enforcement.

Voice via Vignette

Rather than a tome of requirements or a blanket statement such as, "Follow the standards in Clean Code.", give the team simple guidelines that they can agree to and internalize. Short, simple reminders of what quality is to the team. With these simple reminders, they have a catalyst that fires the synapse that brings back all the other "rules".

Enter the Three "R"s of Clean Code

For this particular client, LeanDog helped to establish a set of three simple reminders; Readable, Reliable, and Responsible. These may not be the right reminders for your team. Work together to find what resonates with you.

We restricted ourselves to a single sheet of 8.5"x11" paper and documented the standards we felt were most important. Once the page was filled, we reduced it by eliminating duplicates and highly similar items. We then sorted it in priority order and cut it to half of a page. We then studied the list and came up with groupings. We moved items into the groups and discussed how it all "felt". It took only a couple of iterations to finalize the list.

The team now has four signs that hang in their work space. The three Rs and The Boy Scout Rule Each of the R signs has a short list that further describes what the team means by the "rule".

Readable

Descriptive Function Names
Small Functions
Few Comments
Few Arguments

Reliable

Tested
Descriptive Function Names
Necessary Code

Responsible

Single Responsibility Principle
Necessary Code
Tested

Less is More

We did not cover many things. We don't talk about specific conventions for naming. We don't cover formatting items such as indentation or where the curly-brackets belong. We focused on a select few things that the team felt would guide them toward better overall code. These signs hang up around the work space as regular, simple reminders. And the entire team not only knows what these mean, they follow them without any governance beyond integrity and a commitment to the team.

What would be on your list?

As I said, the list was developed by the team for the team. Maybe there is something you think is very important that was overlooked. Think on this for a while and then let us know what your personal (or team) list would look like.