Agile Employment Contracts (part 1)

A lot has been said said about agile development and agile principles like content delivery over contract negotiation, flexibility of contracts and no upfront specification. We've been loving and doing that for some years now. One thing I was not able to wrap my head around for the longest time, though, was how to manage (traditional) employees in this kind of a non-traditional arrangement. Most of the agile books spend only very limited time on this topic pretty much always retorting to anecdotal evidence of "self motivated teams rising to the occasion and living happily ever after"

When dealing with clients, both parties are bound by the contract (however agile and flexible) and there are clear and simple business rules to be followed. In our case it comes down to if client doesn't like what they're getting they don't pay. The payment happens after every iteration so both parties have a tangible motivation/interest to get things done. Both parties enter the contract without previous baggage and maintain pretty much equal status.

Not at all as simple with (traditional) employees. They usually start with limited knowledge and require extensive training. In our company it takes several months and even after they've mastered the technical skills they still need months and months of experience to grasp various aspects of different domains and business processes we deal with every day. We use commission from closed iterations and collected payments as a motivation. Main portion of the money, however, still comes in the form of monthly salary. Given high level of stress, steep learning curve of ever changing technology, demanding customers, even more demanding bosses it's only matter of time when the initial motivation wears out and everyday routine kicks in. In many of my ex-employees, this was accompanied with a feeling that they've learned more than they'd ever thought they would and their price on the market has soared indefinitely. Sarcasm aside, after reaching this level, people start to be more relaxed and try to find motivation/amusement in experimentation with latest gadgets, obscure technologies or start working on they're own version of Rails or other frameworks. What's worse, it slowly starts to affect the delivery of project(s).

Now let's switch to our shoes. We spent the money on training and non-productive period of the employee. We see that the results are diminishing and we see that the employee is even starting to abuse others requiring help and claiming that he is a slow programmer and that it's not his domain knowledge, etc. Problems in delivery cause delayed payments and smaller and less frequent commission for the employee. No matter how little employee produces (and this can quickly become negative value when the quality reaches throw away and rework levels) his salary is still guaranteed to him by employment act.  If we let him go we lost all our investment in training and we will incur extra costs replacing him mid-project. During all this time there is absolutely nothing we can do to protect our side. Yes, we can motivate, but if that doesn't work we've got nothing.

Agile development contracts seem to be calling for agile employment contracts.