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…

Normal service is being resume...

Believe it or not the book is finished – kind of.  Still some stuff to do so things can start to return to normal, and that means more blogging!

Seriously, I don’t want to get back to the multiple postings a week phase but I do want to blog more.  I’ve got a back log of things I want to talk about.

I’m off at EuroPLoP next week so there will probably be a lot of pattern posts in the next few weeks.  I’m currently reading the papers for my workshop, so far it looks like it will be a high quality year.  As usual I will come back physically exhausted and mentally renewed.

Finishing the book also means I can return to reading more books and reviewing them here.

Still I’m very busy with stuff to read, things to do on the house, boring book stuff, very busy client work and a back log of things to write.  I even intend to contribute something to ACCU Overload in the next few months!

Anyway, on with the show…

Off-shoring gets more expensive

Interesting piece in the FT today about the increasing cost of outsourcing to India – Offshore call centre benefits challenged.  Seems companies are finding that call centres in India are getting more expensive, wages are rising. 

I have long help that this would happen, and as it does off-shoring becomes less attractive.  Even in India the supply of suitable call-centre staff is limited and over time their wages will rise.  This is good for everyone: the individuals get paid more, India gets more money and more jobs get retained in the source countries.

And if increasing cost were not enough it also seem the same call centres are less effective at dealing with complicated enquiries and less successful at selling additional products.  (Neither does this article mention the high staff turnover rates that call centres and other off-shore operations experience in India.)

I expect to see this trend repeated in the off-shore software development sector too. 

As I’ve said before, I’m not against outsourcing or off-shoring.  In fact I see good reasons to support off-shoring.  Just I do not believe it is a cure for all problems, and I think it can cost a lot more than people think.

Neither do I think it is right for early stage companies.  I think it works best when you know your product, your processes and what you are trying to do.  When any, or all, of these things are in flux you are better off having the operations were you can see them, control them, and keep feedback loops tight.