The Quality Responsibility

A few weeks ago I was facilitating a session with a group of people responsible for delivering a software platform to support a number of very large institutions in complex markets.  The session was centred around how you could create more collaboration, predictability, communication and feedback into their delivery cycle and how the different groups and roles might better interact with each other to deliver higher quality, valuable software and solutions to their customers.  They have had problems meeting their commitments to-date and when they have delivered it hasn’t really met their customers’ requirements.  A common problem that we’ve all heard about many times now.

Their normal approach is full of hand-offs, long lead times between specifying something and seeing it in reality to provide real feedback, and very document rich to support people’s ailing memories across these long lead times.  During this session there was a real feeling of parochialism.  The Development Manager was arguing the QA needed to step up to do such and such.  The QA Manager was saying the Dev were always delivering sub-standard work.  Everyone was pointing at the requirements still being worked on.  And the designers and architects had such grand plans that weren’t achievable.  It was the classic example of the silo organisation.  The interesting thing is that all of their backs are against the wall because they have deliveries to hit.  My point to them was:  QA fails, you ALL fail.  Dev fails, you ALL fail.  Design fails, you ALL fail.  There was silence in the room and then the penny dropped.  They realised that they should be a team.

I read two blog posts yesterday that made me think about this situation.  The first was the TradableQualityHypothesis by Martin Fowler.  The second was Mike Gaultieri’s ‘Want Better Quality? Fire Your QA Team‘.  Both posts were ultimately about the ownership, accountability and responsibility of quality.  For some organisations they believe that quality is improved by spending more time on getting the requirements right.  For others it is about getting the design right.  For a lot it is about spending all the time on QA.  Not many firms actually believe (in my experience) that the developers are really the ones who can help because it has become for large enterprises a commodity – which is completely wrong.  However, for the teams and organisations who actually produce high quality work they understand it is about everyone systemically collaborating and working together to develop solutions.  Everyone is responsible for quality.  Interestingly, in Mike’s article, the extreme position of firing the ‘Quality’ team had the amazing effect of everyone else taking accountability and responsibility for the quality of the output.  It would be interesting to understand what actually happened and if it supported the hypothesis of Tradable Quality too.  My guess is that the Internal Quality was increased significantly as a result.

I’m not necessarily espousing that all teams need to fire their QA departments, but I am very much of the mind that all of the roles and responsibilities need to be blended into a one-team mentality whereby everyone succeeds or fails on each others’ quality and performance.  The key thing for me is that Managers and Directors need to understand that they will damage their future business unless they really understand this.  As I said in my last post, Demand Technical Excellence, or you will all have a case of high dynamic complexity and lots of finger waving when the IT platforms grind to a halt.