TDD, Objective setting and doing the obvious

I’ve been doing a round of objective setting for my client recently.  When it was first announced the company wanted to go down this path I groaned.  “Arhh” I thought, “I hate objectives, I hate people setting them, I hate all the baggage that comes along with them.”  Neither was I impressed by the way my client’s HR department presented the idea or the proposal for implementation.

I’m a past master at criticising management by objective, it is quite easy really, just look at the side effects and read Goodhart’s Law.  Anyway, its not turning out like that at all, little bit of imaginative thinking and things are looking good.  Sure we are only in the objective setting phase so far so it is too early to say, much could happen but….

First I have rigorously applied the SMART approach – objectives need to be Specific, Measurable, Achievable, Realistic and Time boxed.  Second I added an extra criteria “V” – call it the SMART+V formula.  “V” stands for Value-add.  (Only I now realise it should be V+SMART, if you can’t show value don’t continue.)

Next was the realisation that the development team all did pretty much the same job.  Therefore one could expect them to have pretty similar objectives.  And if they all had similar objectives it would aid team work.

Finally, I think I realised how to use this to my advantage.  The team have not been doing code reviews or Test Driven Development (automated unit testing if you prefer) but everyone is willing to do both.  So, its now turning out that most of the team have objectives around these area.  Not everyone, and individual goals might have a slightly different take but they all build.

Half way through and this approach seems obvious.  If a manager wants his team to do TDD then why not just set it as an objective?  Surely this is the way it is meant to work: manager decides, manager aligns team, team does what manager wants.

If it is this obvious why bother with all the TDD evangelising, training, coaching and calls to do it.  Why both with fancy change ideas.  Just set it as a target and do it.  Could it be so easy? 

Of course it isn’t going to be that easy.  For a start just because it is set as an objective doesn’t mean it is going to be met.  Just because people want to do something doesn’t give them the knowledge to do it; at the start people don’t know how to do it.  Then there are the usual problems like time pressures and people who will think “it won’t work here.”

Having set it as an objective I’m still going to have to work hard at giving people as much support, training, coaching and other assistance as I can.

One real danger to this approach is that the managers who set these kind of objectives might just believe that setting an objective is all that is required.  As I just said: setting it as an objective doesn’t mean it will happen.  Objectives are a two way street and managers need to help people meet theirs.  Thats why I’m thinking of setting my own objective as: “Team reaches 80% of objectives.”

If this approach is so obvious why haven’t I done it before?  Well apart from the problems I just outlined this particular tool has not been available to me in the past.  Sometimes management wasn’t bought in to TDD, sometimes objectives weren’t in use and sometimes I wasn’t in a position to set the objectives.

At the moment it feels good and I think its going to work.  I’ll report back…