Research into software development

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.

Advertisements

Partner for capability development – Software Education

A lot of the work I do involves building the internal capability for an organisation.  And while I like to think I am good at what I do, I don’t have the expertise to cover the full breadth of work this can entail.  So I often work with Software Education.

You might see me appearing as one of their trainers, since any face to face BA or Agile training I do tends to be working as one of their crew rather than in my own right.  You might also see them as the group I recommend using when I am doing consulting for you and you need training to accompany that work.

So, who are they?

They describe themselves in the following terms:

“Software Education are the internationally recognised local experts in software development training.  With over 50 courses in Business Analysis, System Design, Programming, Software Testing, IT Management and Agile Development, we not only provide you with access to leading-edge content but also get you connected to an unrivalled network of international experts. “

Whether through our public courses, individually tailored in-house training or our international conferences, STANZ and SDC, with our help you will acquire practical, relevant skills which you can use immediately.

What’s more, we can help you acquire certification, if that’s important to you.”

Agile, lean, kanban – more stress for the team?

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.