The Developers are delaying the release again...apparently!!

I’ll never forget the look on the face of one of the Directors of a former Employer. Picture the scenario – the project was way behind its promised delivery date, clients were threatening mutiny, pressure was high, requirements were being de-scoped, and quality was heading south as mistake after mistake was occurring. It was in this context when we were called into a team wide meeting with Management and the Directors to discuss the matter. Whilst this was done in an open and transparent format (which was how we always worked), the aim was to get assurances of a high quality release to specification and in timely fashion.

I patiently waited (like the typical, introverted, well behaved, passionate Tester that I am ;)) until it was my turn to speak. To everyone’s surprise I only had one comment: “We need to slow down Development”.

 

It was at this point I got the glare from hell from one of my Directors. You see, he didn’t quite understand how I was proposing that we work at an even slower rate. He probably couldn’t accept my disregard to the position of Management, and I suspect he also loathed the likelihood that I was putting thoughts into the minds of my team mate Developers to relax and slow down. He was spot on because this is exactly how I was feeling (more on that later).

 

Moments took years to pass when I eventually glanced around the room. I noticed my Development Manager was not frowning or shocked like everyone else. I sensed he understood my point. I gathered he had enough on his plate and so perhaps from his perspective my comment was a show of support and a reflection for how others were really feeling.

 

The scenario we had was: Partially delivered functionality which was not working; Defect fixes which were failing re-test at a rate of 2 in 3; Delivery of high level business requirements which were being analysed at the time of Development and Testing and which required a lot of rework; and Minimal validation on the impact of changes being integrated into the overall system (in other words Regression testing was nowhere near on track). To make matters more interesting, the same team was servicing multiple production support issues, working on other projects, managing their own Development and Testing platforms, dealing with company ownership changes, and dealing with other work matters in general.

 

If that wasn’t enough of a challenge, the project was conceived on the basis of unqualified, high level client needs. That is, with insufficient input to determine if it was possible to transform those needs into a real deliverable specification on time and to acceptable quality. It was the typical scenario whereby our Sales people were pushing boundaries and this meant doing whatever it took to secure contracts (and fair enough as this was fundamental in ensuring our future).

 

So why did I say slow down? I said this because I had seen the same level of errors and fail rates consistently in the past. I had seen the conflicting priorities, the unqualified solution, and the tight schedule. All of this was part of our day to day working environment and was systematic behaviour. It was therefore measurable, and this is exactly what I had done over the years! Hence my metrics were telling me that this was how we rolled. So I wasn’t literally saying to code less or to skip tests. What I was essentially saying was that we all needed to relax because we were on track.

 

I can see the problem with this approach today, although at the time I stood my ground. With more clarity I can see that we were on a different track to our peers and that this did not give us the grounds alone to continue at the same rate and quality. We didn’t have the right to undermine existing agreements on the basis of a sarcastic outburst which at the time had not been qualified.

 

The approach I should have taken was to present a high level overview of the results we were achieving. I think I did this after the meeting however I cannot recall this with certainty and given that the meeting experience is what remains clear in my mind to this day, perhaps my comment and not my follow-up was the stronger message conveyed.

 

There was also an element of frustration in my comment. In my estimation documentation was a clear demonstration of behaviour which had been previously conveyed to Management in the past. However reoccurrence of the same problems convinced me that nothing was being done, and so I stopped presenting a detailed case. I also started to believe that it was out of everyone’s hands as power shifted to higher levels of management beyond our team. I was also well aware that my ongoing constructive feedback about the level of Development quality was already known and so all I managed to communicate was negativity. I can now accept that my message of showing that we were dealing with a high level of complexity did not get through.

 

When I read through this story and ask myself whether I believe that Development was the reason why those projects were constantly delayed, my genuine belief remains as a “no”. The line of business we were in was tougher than any prior industry I had worked in, and it simply was not possible to speed up at the flick of a finger. We had no competitors to measure against, we were in a mission critical space 24x7, and our financial position meant that we could not afford the luxury of setting up long term team plans where skills transfer could be done efficiently, and where other continuous improvements could be pioneered. We were good at trying to do this but on a tight budget and with a strong market, holding down good performers to achieve these goals was made all the more difficult. All is good now with my former team I’m sure!