Traditional techniques and motivating staff (2010)

traditional techniques & motivating staffTesting Planet 2020This article appeared in the February 2010 edition of Software Testing Club Magazine, now the Testing Planet. The STC has evolved into the wonderful Ministry of Testing, one of the most exciting developments in software testing over the last 20 years.

That might seem a low bar; testing isn’t meant to be a thrill a minute. But the Ministry of Testing has been a gale of fresh air sweeping through the industry, mixing great content and conferences with an approach to testing that has managed to be both entertaining and deeply serious. It has been a consistent voice of sanity and decency in an industry that has had too much cynicism and short sightedness.ministry of testing logo

I’m moving this article onto my blog fromy my website, which will shortly be decommissioned. Looking back I was interested to see that I didn’t post this article on the website immediately. I had some reservations about the article. I wondered if I had taken a rather extreme stance. I do believe that rigid standards and processes can be damaging, and I certainly believe that enforcing strict compliance, at the expense of initiative and professional judgement, undermines morale.

However, I thought I had perhaps gone too far and might have been thought to be dismissing the idea of any formality, and that I might be seen to be advocating software development as an entirely improvised activity with everyone winging it. That’s not the case. We need to have some structure, some shape and formality to our work. It’s just that prescriptive standards and processes aren’t sensitive to context and become a straitjacket. This was written in January 2010 and it was a theme I spent a good deal of time on when the ISO 29119 standard was released a few years later and the Stop 29119 campaign swung into action.

So I still largely stand by this article, though I think it is lacking in nuance in some respects. In particular the bald statement “development isn’t engineering”, while true does require greater nuance, unpacking and explanation. Development isn’t engineering in the sense that engineering is usually understood, and it’s certainly not akin to civil engineering. But it should aspire to be more “engineering like”, while remaining realistic about the reality of software development. I was particularly interested to see that I described reality as being chaotic in 2010, a couple of years before I started to learn about Cynefin.

The article

Do we follow the standards or use our initiative?

Recently I’ve been thinking and writing about the effects of testing standards. The more I thought, the more convinced I became that standards, or any rigid processes, can damage the morale, and even the professionalism, of IT professionals if they are not applied wisely.

The problem is that calling them “standards” implies that they are mandatory and should be applied in all cases. The word should be reserved for situations where compliance is essential, eg security, good housekeeping or safety critical applications.

I once worked for a large insurance company as an IT auditor in Group Audit. I was approached by Information Services. Would I consider moving to lead a team developing new management information (MI) applications? It sounded interesting, so I said yes.

On my first day in the new role I asked my new manager what I had to do. He stunned me when he said. “You tell me. I’ll give you the contact details for your users. Go and see them. They’re next in line to get an MI application. See what they need, then work out how you’re going to deliver it. Speak to other people to see how they’ve done it, but it’s up to you”.

The company did have standards and processes, but they weren’t rigid and they weren’t very useful in the esoteric world of insurance MI, so we were able to pick and choose how we developed applications.

My users were desperate for a better understanding of their portfolio; what was profitable, and what was unprofitable. I had no trouble getting a manager and a senior statistician to set aside two days to brief me and my assistant. There was just us, a flip chart, and gallons of coffee as they talked us through the market they were competing in, the problems they faced and their need for better information from the underwriting and claims applications with which they did business.

I realised that it was going to be a pig of a job to give them what they needed. It would take several months. However, I could give them about a quarter of what they needed in short order. So we knocked up a quick disposable application in a couple of weeks that delighted them, and then got to work on the really tricky stuff.

The source systems proved to be riddled with errors and poor quality data, so it took longer than expected. However, we’d got the users on our side by giving them something quickly, so they were patient.

It took so long to get phase 1 of the application working to acceptable tolerances that I decided to scrap phase 2, which was nearly fully coded, and rejig the design of the first part so that it could do the full job on its own. That option had been ruled out at the start because there seemed to be insurmountable performance problems.

Our experience with testing had shown that we could make the application run much faster than we’d thought possible, but that the fine tuning of the code to produce accurate MI was a nightmare. It therefore made sense to clone jobs and programs wholesale to extend the first phase and forget about trying to hack the phase 2 code into shape.

The important point is that I was allowed to take a decision that meant binning several hundred hours of coding effort and utterly transforming a design that had been signed off.

I took the decision during a trip to the dentist, discussed it with my assistant on my return, sold the idea to the users and only then did I present my management with a fait accompli. They had no problems with it. They trusted my judgement, and I was taking the users along with me.

The world changed and an outsourcing deal meant I was working for a big supplier, with development being driven by formal processes, rigid standards and contracts. This wasn’t all bad. It did give developers some protection from the sort of unreasonable pressure that could be brought to bear when relationships were less formal. However, it did mean that I never again had the same freedom to use my own initiative and judgement.

The bottom line was that it could be better to do the wrong thing for the corporately correct reason, than to do the right thing the “wrong” way. By “better” I mean better for our careers, and not better for the customers.

Ultimately that is soul destroying. What really gets teams fired up is when developers, testers and users all see themselves as being on the same side, determined to produce a great product.

Development isn’t engineering

Reality is chaotic. Processes are perfectly repeatable only if one pretends that reality is neat, orderly and predictable. The result is strain, tension and developers ordered to do the wrong things for the “right” reasons, to follow the processes mandated by standards and by the contract.

Instead of making developers more “professional” it has exactly the opposite effect. It reduces them to the level of, well, second hand car salesmen, knocking out old cars with no warranty. It’s hardly a crime, but it doesn’t get me excited.

Development and testing become drudgery. Handling the users isn’t a matter of building lasting relationships with fellow professionals. It’s a matter of “managing the stakeholders”, being diplomatic with them rather than candid, and if all else fails telling them “to read the ******* contract”.

This isn’t a rant about contractual development. Contracts don’t have to be written so that the development team is in a strait-jacket. It’s just that traditional techniques fit much more neatly with contracts than agile, or any iterative approach.

Procurement is much simpler if you pretend that traditional, linear techniques are best practice; if you pretend that software development is like civil engineering, and that developing an application is like building a bridge.

Development and testing are really not like that all. The actual words used should be a good clue. Development is not the same as construction. Construction is what you do when you’ve developed an idea to the point where it can be manufactured, or built.

Traditional techniques were based on that fundamental flaw; the belief that development was engineering, and that repeatable success required greater formality, more tightly defined processes and standards, and less freedom for developers.

Development is exploring

Good development is a matter of investigation, experimentation and exploration. It’s about looking at the possibilities, and evaluating successive versions. It’s not about plodding through a process document.

Different customers, different users and different problems will require different approaches. These various approaches are not radically different from each other, but they are more varied than is allowed for by rigid and formal processes.

Any organisation that requires development teams to adhere to these processes, rather than make their own judgements based on their experience and their users’ needs, frequently requires the developers to do the wrong things.

This is demoralising, and developers working under these constraints have the initiative, enthusiasm and intellectual energy squeezed out of them. As they build their careers in such an atmosphere they become corporate bureaucrats.

They rise to become not development managers, but managers of the development process; not test managers, but managers of the test process. Their productivity is measured in meetings and reports. Sometimes the end product seems a by-product of the real business; doing the process.

If people are to realise their potential they need managers who will do as mine did; who will say, “here is your problem, tell me how you’re going to solve it”.

We need guidance from processes and standards in the same way as we need guidance from more experienced practitioners, but they should be suggestions of possible approaches so that teams don’t flounder around in confused ignorance, don’t try to re-invent the wheel, and don’t blunder into swamps that have consumed previous projects.

If development is exploration it is thrilling and brings out the best in us. People rise to the challenge, learn and grow. They want to do it again and get better at it. If development means plodding through a process document it is a grind.

I know which way has inspired me, which way has given users applications I’ve been proud of. It wasn’t the formal way. It wasn’t the traditional way. Set the developers free!

A more optimistic conclusion?

This is the final post in a series about how and why so many corporations became embroiled in a bureaucratic mess in which social and political skills are more important than competence.

In my first post “Sick bureaucracies and mere technicians” I talked about Edward Giblin’s analysis back in the early 1980s of the way senior managers had become detached from the real work of many corporations. Not only did this problem persist, but it become far worse.

In my second post, “Digital Taylorism & the drive for standardisation“, I explained how globalisation and technical advances gave impetus to digital Taylorism and the mass standardisation of knowledge work. It was widely recognised that Taylorism damaged creativity, a particularly serious concern with knowledge work. However, that concern was largely ignored, swamped by the trends I discussed in my third post, “Permission to think“.

In this post I will try to offer a more constructive conclusion after three essays of unremitting bleakness!

Deskilling – a chilling future for testing?

When it comes to standardisation of testing the “talented managers” (see “Permission to think“) will tell themselves that they are looking at a bigger picture than the awkward squad (ok, I mean context driven testers here) who complain that this is disastrous for software testing.

Many large corporations are hooked into a paradigm that requires them to simultaneously improve quality and reduce costs, and to do so by de-skilling jobs below the elite level. Of course other tactics are deployed, but deskilling is what concerns me here. The underlying assumption is that standardisation and detailed processes will not only improve quality, but also reduce costs, either directly by outsourcing, or indirectly by permitting benchmarking against outsourcing suppliers.

In the case of testing that doesn’t work. You can do it, but at the expense of the quality of testing. Testing is either a thinking, reflective activity, or it is done badly. However, testing is a mere pawn; it’s very difficult for corporate bureaucrats to make an exception for testing. If they were to do that it would undermine the whole paradigm. If testing is exempt then how could decision makers hold the line when faced with special pleading on behalf of other roles they don’t understand? No, if the quality of testing has to be sacrificed then so be it.

The drive for higher quality at reduced cost is so powerful that its underlying assumption is unchallengeable. Standardisation produces simplicity which allows higher quality and lower costs. That is corporate dogma, and anyone who wants to take a more nuanced approach is in danger of being branded a heretic and denied a hearing. It is easier to fudge the issue and ignore evidence that applying this strategy to testing increases costs and reduces quality.

Small is beautiful

Perhaps my whole story has been unnecessarily bleak. I have been talking about corporations and organisations. I really mean large bodies. The gloomy, even chilling, picture that I’ve been painting doesn’t apply to smaller, more nimble firms. Start-ups, technology focused firms, and specialist testing services providers (or the good ones at least) have a clearer idea of what the company is trying to do. They’re far less likely to sink into a bureaucratic swamp. For one thing it would kill them quickly. Also, to hark back to my first post in this series, “Sick bureaucracies and mere technicians“, such firms are more likely to be task dependent, i.e. the more senior people will probably have a deep understanding of the core business. It is their job to apply that knowledge in the interests of the company, rather than merely to run the corporate bureaucracy.

My advice to testers who want to do good work would be to head for the smaller outfits, the task dependent companies. As a heuristic I’d want to work for a company that was small enough for me to speak to anyone, at any time, who had the power to change things. Then, I’d know that if I saw possible improvements I’d have the chance to sell my ideas to someone who could make a difference. One of the most dispiriting things I ever heard was a senior manager in the global corporation where I worked saying “you’re quite right – but you’d be appalled at how high you could go and find people who’d agree with you, but say that they couldn’t change anything”.

What’s to be done?

Nevertheless, many good testers are working for big corporations, and struggling to make things better. They’re not all going to walk out the door, and they shouldn’t just give up in despair. What can they do? Well, plain speaking will have a limited impact – except on their careers. Senior managers don’t like being told “we’re doing rubbish work and you’re acting like an idiot if you refuse to admit that”.

Corporate managers are under pressure to make the bureaucracy more efficient by standardising working practices and processes. In order to do so they have to redefine what constitutes simple, routine work. Testers have to understand that pressure and respond by lobbying to be allowed to carry out that redefinition themselves. Testing has to be defined by those who understand and respect it so that the thoughtful, reflective, non-routine elements are recognised. Testing must be defined in such a way that it can handle complex problems, and not just simple, ordered problems (see Cynefin).

That takes us back to the segmentation of knowledge workers described by Brown, Lauder and Ashton in The Global Auction (see my previous post “Permission to think“). The workforce is increasingly segmented into developers (those responsible for corporate development, not software developers!), who are given “permission to think”, demonstrators who apply processes, and drones who basically follow a script without being required to engage their brains. If testers have to follow a prescriptive, documentation driven standard like ISO 29119 they are implicitly assigned to the status of drones.

Testers must argue their case so they are represented in the class of developers who are allowed to shape the way the corporation works. The arguments are essentially the same as those that have been deployed against ISO 29119, and can be summed up in the phrase I used at the top; testing is either a thinking, reflective activity, or it is done badly. Testing is an activity that provides crucial information to the corporate elite, the “developers”. As such testers must be given the responsiblity to think, or else senior management will be choking off the flow of vital information about applications and products.

That is a tough task, and I’m sceptical about the chances of testers persuading their corporations to buck a powerful trend. I doubt if many will be successful, but perhaps some brave, persuasive and persistent souls will succeed. They deserve respect and support from the rest of the testing profession.

If large corporations won’t admit their approach is damaging to testing then ultimately I fear that their in-house test teams are doomed. They will be sucked into a vicious circle of commoditised testing that will lead to the work being outsourced to cheaper suppliers. If you’re not doing anything worthwhile there is always someone who can do it cheaper. Iain McCowatt wrote a great blog about this.

Where might hope lie?

Perhaps outsourcing might offer some hope for testing after all. A major motive for adopting standards is to facilitate outsourcing. The service that is being outsourced is standard, neatly defined, and open to benchmarking. Suppliers who can demonstrate they comply with standards have a competitive advantage. That is one of the reasons ISO 29119 is so pernicious. Good testing suppliers will have to ignore that market and make it clear that they are not competing to provide cheaper drones, but highly capable, thinking consultants who can provide valuable insights about products and applications.

The more imaginative, context-driven (and smaller?) suppliers can certainly compete effectively in this fashion. After all they are following an approach that is is both more efficient and more effective. Their focus is on testing rather than documentation and compliance with an irrelevant standard. However, I suspect that is exactly why many large corporations are suspicious of such an approach. The corporate bureaucrat is reassured by visible documents and compliance with an ISO standard.

A new framework?

Perhaps there is room for an alternative approach. I don’t mean an alternative standard, but a framework that shows how good context driven testing is responsible testing that can keep regulators happy. It could tie together the requirements of regulators, auditors and governance professionals with context driven techniques, perhaps a particular context driven approach. The framework could demonstrate links between governance needs and specific context driven techniques. This has been lurking at the back of my mind for a couple of years, but I haven’t yet committed serious effort to the idea. My reading and thinking around the subject of corporate bureaucracy for this series of blog posts has helped shape my understanding of why such an alternative framework might be needed, and why it might work.

An alternative framework in the form of a set of specific, practical, actionable guidelines would ironically be more consistent with ISO’s definition of a standard than ISO 29119 itself is.

A standard is a document that provides requirements, specifications, guidelines or characteristics that can be used consistently to ensure that materials, products, processes and services are fit for their purpose.

Taking the relevant parts of the definition, the framework would provide guidelines that can be used consistently to ensure that testing services are fit for their purpose.

Could this give corporations the quality of testing they require without having to abandon their worldview? Internal testers might still be defined as drones (with a few, senior testers allowed to be demonstrators). External testers can be treated as consultants and allowed to think.

When discussing ISO 29119, and the approach to testing that it embodies, we should always bear in mind that the standard does not exist to provide better testing. It was developed because it fits a corporate mindset that wants to see as many activities as possible defined as simple and routine. Testers who have a vision of better testing, and a better future for testing, have to understand that mindset and deal with it, rather than just kicking ISO 29119 for being a useless piece of verbiage. The standard really is useless, but perhaps we need a more sophisticated approach than just calling it like it is.