I was given a new technological device for Christmas that I never knew I needed – a cup warming plate that plugs into my laptop.  Now I can type away while leaving my tea or coffee for ages without it going cold.

The device has set a new standard for decadent features that I previously did not conceive a need for.  And of course it comes with a warranty if I can be bothered to log in and register.

I am happy to have this new complexity in my life as the maintenance cost is minimal.  I can either keep it on my desk, pack it in my suitcase, or stick it in a cupboard “to use later”.

I am also happy to register for the warranty “just in case”.  But I will be very annoyed if I have to actually use the warranty, because I will be really frustrated if my shiny new toy (er – I mean productivity enhancement device) doesn’t work properly.

Interestingly, though I have been speaking to some IT crews recently who insist that all IT projects should have a warranty period.

Apparently offering a warranty shows the business customers that we care and want to do the job properly.

But my question is this – If I am annoyed at having to use a warranty for the products I buy, then why should my customers be happy at having to use the warranty I give them.  Shouldn’t they be like me, sticking the warranty in a file in case of need and then forgetting about it?

I recently added an article to another blog about testing, and I added a link to yet a further blog that talks about testing on agile projects.  They are slightly relevant here because they both talk around the idea that we should build quality into what we do rather than testing and fixing what we produce at the end.

You can follow the links here if you like: http://softwareeducation.wordpress.com/2009/12/27/some-holiday-reading-what-happens-to-testers-on-agile-projects/

More importantly though, the lesson I would like to take from the new coffee warmer I have is Not that we need more complexity, gadgets and features that nobody previously realised they needed.

It is that we need expect our systems to work. We should be surprised if they fail and therefore “warranty periods” should be an accommodation to the past practice of building too much complexity too quickly. If our clients want to purchase a warranty then fine – but we should use the chance to hang out with production support and fix old bugs, not start to unwind the damage done by our latest period.

Then the measure of a successful project can be that the clients start to see warranty as paperwork to stick in the draw.  And we can get on with building the next thing they want.

I often come across research into things such as Agile development, ITIL, pair programming and other areas.  But the research is often quoted by fans of whatever the topic is.

I am generally too lazy to confirm that the research is sound, so I generally ignore most of it.

But here is some unbiased looking research (which I have not verified) into some areas of software development:

http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx

The areas I found most interesting were:

- Test driven development provides better quality but is significantly slower then “code then test”.  I am in favour of quality over speed in deploying new code, but this is the first research I have seen on the impact of TDD to speed.  And if the number is consistently “30% slower” then I guess that should give some teams cause to stop and think.

- Organisational structure and measures seems to have a massive impact on software quality.  So rather than revolutionising the techniques used, maybe better quality comes from building and supporting the team with the right organisational drivers.

I had an interesting discussion in a workshop last week.  At the end of the second day someone asked me if “there have been any studies on stress levels for agile teams?”

I claimed that there should be less stress (which there should) but several of the group replied that there is in fact more stress than people experienced before going agile.

I wasn’t really satisfied with the conclusion of the discussion.  We left it with the shared agreement that

• There is no fundamental reason why teams need to become more stressed with changes such as agile, lean or kanban approaches;
• It is easy to say that there is additional stress involved in changing approaches and that this will go away when things settle down; but
• Many teams find that rather than being empowered and freed up from the shackles of the old world, these new techniques all embed stress into their normal working practices.

My view is that this is the fault of the dynamics in the team and that each person is creating an unreasonable expectation on the others.  I therefore think it can be cured by looking at the expectations we have of ourselves and each other.

These approaches also create greater visibility of what is in the team’s backlog and how fast particular items can be completed.  So if we don’t push back on unreasonable work then we will be opening up the opportunity to bring on completely unreasonable demand levels that will not even be satisfied if we work every weekend.

But I am going to do some research over the next couple of months to find a better answer than “read the manifesto and set better expectations and then be happy”.

In the meantime I guess the best advice I can give is to browse through the following site.

http://www.health.harvard.edu/topic/stress

Iif anything you are learning about lean, kanban, agile, ultraspeed development, iso20000 or any other practices contradicts the advice of this site then the practice is wrong.  Conquering stress leads to clear thinking, collaboration and the willingness to take accountability – and those things will make your team more agile than any new practice or methodology will.

If you have a better response for now then let me know.  Otherwise I will come back to report here when I find a better answer as to why stress is increasing when logic tells me it should be decreasing.

The innovative among us would love to run online forums in the areas that interest us.  But the old and jaded among us have seen many communities (online forums, communities of practice, centres of excellence) rise up, hover for a moment and then disappear from sight.

So I was interested to see the following link someone sent me, where someone is relaunching their online forums.

I particularly like the way they share their lessons with their clients by openly admitting where they stumbled.

http://culturedcode.com/things/blog/2009/08/introducing-forums-20.html