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.