allan kelly

“Gentlemen, you are getting married. You go to the best tailor in town, and you say: ‘I’m getting married, my bride is beautiful, make me look one million dollars, I don’t care what it costs.’

The tailor measures you very carefully then he stands back. He rubs his chin, he is clearly troubled by something. ‘Tell me’ you say, ‘Please tell me.’

‘Sir’, he replies, ‘I don’t think it is my place to say’

‘Tell me’ you beg, ‘I must looks fantastic for my girl’

‘Well Sir, …’ he talks slowly and cautiously, ‘. if you really want to look $1,000,000 can I suggest you lose 5kg?’

What do you say?”

This is the dilemma many a consultant find themselves in. More importantly it is the dilemma that I find again and again in corporate IT:

• Is IT a service department which is expected to build what is requested without answering back?

Or

• Is are the IT departments the experts in maximising benefit and value out IT investment?

Is the tailor a master of clothes who just makes beautiful clothes? Or are they, because of their long experience making people look beautiful in clothes, an image consultant who can help you look beautiful?

Is your IT department a tailor who is expected to produce something brilliant no matter what the request is? Or are they people who, because they work with information technology every day, have experience and knowledge to help their (internal) customers maximise their benefit? (Even if that means the original request should be reconsidered.)

I distinctly remember a senior IT manager at an American bank telling me that his department was most definitely a service department, it wasn’t his job to answer back to business requests, his job was to build what was asked for. The implication being that even if his people knew the (internal) client was approaching the issue from the wrong point, and even asking for the wrong system, then his people should not correct them. They should just build what was asked for.

Perhaps this dilemma is most accurately felt by Business Analysts who are sometimes expected to write down the orders that someone else wants to give to IT even if they know better. Fortunately some Business Analysts can go further and advise their “customers” on what the bigger questions.

The original metaphor come from Benjamin Mitchell. As I recall it was part of a very deep conversation we had in Cornwall back in 2011 and which also led to the “Abandon hope all ye who enter Agile” blog post. I’ve embellished and elaborated the story over the years.

I reminded Benjamin of this story in January – he’d forgotten about it, thats how brilliant he is, he has so many great ideas he can’t keep track of them all. Once I’d reminded him he immediately made it better.

“How would you know?” he asked, meaning, “How can you determine what is expected of you?”

For me the story is about missed opportunities, about frustration and about what you might do to change the position. For Benjamin it is about asking “Do we all expect the same thing? – If you think they consider you a service group how can you confirm this?”

Either way the core problem is about a mismatch of expectations. Your IT department might be a service department, that approach could work, its how many big corporations operate (I my experience).

Or the IT department could be the experts in technology, how to apply technology, how to frame problems so technology can help and how to maximise the return from technology.

Both are valid options.

But the real problem is when someone in the department thinks the department is should be doing more than the rest of the company does; or when the rest of the company expects more from the department but the department sees itself as a service group.

Finally, go back to my series on the economics of software development, the supply and demand curve, and apply this story. If the IT department is seen as a tailor who shouldn’t answer back they will find it very difficult, if not impossible, to change the demand curve. Such a tailor can only work on the supply side.

In my last post (Inconvenient Truths of Project Status Reporting) I used an expression which I think deserves highlighting and explaining:

        False Projects

False projects occur when we use the word “project” for work which is not really a project. For example:

• There is no end date to the work, it goes on and on, rightly or wrongly.
• The team is not broken up, it goes on and on, rightly or wrongly, i.e. the team is not a temporary structure.
• The output of the work is not defined in advance, or might not even be defined.

Some might think I’m playing word games here but I think its important, I think we need to be clear about our terms. Please, hear me out. (This is really important when we talk about #NoProjects and #BeyondProjects. If this is a new idea to you see my Why Projects Don’t Make Sense post.)

PRINCE 2 (the UK project management standard) offers the following definition of “a project”

“A temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources.”

This is the definition which is most commonly violated. PRINCE 2 helpfully offers a second definition of a project:

“A management environment that is created for the purpose of delivering one or more business products according to a specified business case.”

This seems like a pretty open ended definition, none of the terminating conditions of the first, thats part of the problem. Potentially they are very different. Under this definition a false project would be a piece of work which is called “a project” but for which there is no specified business case or defined products.

Lest I be too UK centric, the American Project Management Institute offers this definition (I have highlighted the parts which concern me most):

“More specifically, what is a project?

It’s a temporary group activity designed to produce a unique product, service or result.

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.

And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.”

As with the first PRINCE 2 definition the emphasis is on an activity that ends. In this definition the team “don’t usually work together”, there comes a point when working together becomes normal.

An awful lot of software development work just doesn’t correspond to any of these definitions but we call it a project. And a lot of work – whether we call it a project or not – is managed by a Project Manager which kind of implies someone, somewhere, thinks of it as a project.

I call such work a False Project.

The problem is: when we use the language of projects – when some people assume the work conforms to one of the above definitions, specifically when they think there is an end, or a temporary arrangement – then we create a conflict. We create confusion. We create a cognitive dissonance.

When we manage a piece of work as “a project” when it isn’t then at the very least we use the wrong language and tools. Worse still we create expectations that can’t be met. Part of the #NoProjects / #BeyondProjects logic is about fixing this conflict, closing this gap.

Personally I have a little hypothesis but I don’t know how to prove it – or disprove it. If someone has employment statistics on managers, middle managers and project managers for the last 30 years we might be able to find some supporting evidence.

My hypothesis is: starting in the 1980’s middle managers became unfashionable, many of them got laid off in mass downsizings. But that doesn’t mean all the management work went away, sure some did but some remained. I suspect the growth in projects and project management stems from this time. I suspect that much of what gets called project management is in fact good old fashioned junior or middle management dressed up so it might be added back into organizations which have previously rejected middle management or want “flat hierarchies” (and other such oxymorons).

Long time readers of this blog may recall that I subscribe to the high-brow MIT Sloan Management Review. They may also remember that I’m never quite sure it is worth the rather high subscription fee. But once in a while an article comes along which is worth a year’s subscription. The “Pitfalls of Project Status Reporting” is this year’s article.

As the title suggests the article looks at why project status reporting, specifically for IT projects, so often fails to alert companies of the problems in project work. (Clearly the authors are unfamiliar with #BeyondProjects/#NoProjects but I suspect most of the same problems can be found in the false-projects so beloved of IT organizations.)

If you want the full story you will need to buy your own copy of the article (Amazon have it for £2.50) but for the rest of you here are the highlights, the 5 points the authors called “Inconvenient Truths” plus some of the text and a couple comments from from myself. The comments are all my own but the quotes – and the headlines in bold – are from the article which is research not conjecture, something we could do we more of!

1. Executives can’t rely on project staff and other employees to accurately report project status information and to speak up when they see problems.

“[software project managers] write biased reports 60% if the time and that their bias is more than twice as likely to be optimistic.”

Basically people don’t like reporting bad news and worry that reporting it will reflect badly on themselves.

2. A variety of reasons can cause people to misreport about project status; individual personality traits, work climate and cultural norms can all play a role.

“employees who work in climates that support self-interested behaviour are more likely to misreport than employees who work in climates based on ‘rules and code’.” Why do I think of banks and bonuses when I read this?

3. An aggressive audit team can’t counter the effects of project status misreporting and withholding of information by project staff.

“Once auditors are added to the mix… a dysfunctional cycle that results in even less openness regarding status information.”

“Diminished trust in the senior executive who controlled their project was associated with an increase in misreporting.”

More reporting will make things worse, if auditors arrive then people don’t feel they are trusted and guess what? They might not show the auditors the dirty washing and might tend to paint things as good.

4. Putting a senior executive in charge of a project may increase misreporting.

“research suggests that the stronger the power of the sponsor or the project leader, the less inclined subordinates are to report accurately.”

I find this suggestion very worrying because some people in the Scrum community insist that the Product Owner must be an executive (“the real product owner”) who has real power to secure the resources and changes a make the project a success. This research suggests that having a strong, senior, Product Owner could make things worse.

5. Executives often ignore bad news if they receive it.

I am reminded of one client where my own attempts to raise a red flag have gone no-where. On my final visit to the client I spoke with the senior architect to again voice both my concerns over the work and the failure of anyone to listen. Unfortunately he had the same problem. He saw the same problems but couldn’t find anyone willing to listen.

My initial thought on all of this is that this is all the more reason to base reporting on deliverables, i.e. what has actually been delivered that is working and in use, that is rather than reporting on proxy “status” criteria, report actual progress, actual deliverables.

A few weeks ago I did a presentation entitled “Conway’s Law and Continuous Delivery” – although it was also at some point entitled “Conway’s Law and Organisational Change” or possibly “Conway’s Law and Change for Continuous Delivery” – to the Pipeline Conference in London.

The presentation was very well received at the time and I spent most of the next hour talking with people who wanted to talk about the presentation. One tester came to be later and said “Thank you, I understand what I’m doing now, I’m testing the organisation.”

Since then the presentation has had a lot of interest on Twitter and on SlideShare – at one time it made the front page of SlideShare (my 15 minutes of fame I guess).

I should say I took a slight liberty with the “organisational change” bit. I didn’t so much describe how to bring about organisational change as describe how the organization might (even should) change to align itself with Conway’s Law. Sorry about that, I don’t have a potted “how to change your organisation” recipe (although if you want to call I’m available for hire!)

Actually the Pipeline conference was the second time I’d made this presentation. The first outing was for the London Continuous Delivery group and hosted at the Financial Times. If you missed these two outings the good news is that the FT delivery was recorded and is available on Vimeo. This presentation is also on SlideShare but isn’t significantly different from the Pipeline version.

(Personally I feel that was the better of the two presentations but others have told me the second was the better, perhaps what the second lacked in raw freshness was more than made up for in being a little more polished and debugged.)

I’m really grateful to Matthew Skelton, Steve Smith and Chris O’Dell who are the people behind both London Continuous Delivery and Pipeline. Although I’ve known about the idea of continuous delivery for a while I know much more and I’m really excited by it.

They have also furnished me an opportunity to revisit Conway’s Law. Nearly 10 years ago I ran a workshop exploring Conway’s Law at EuroPLoP 2005. Both my co-organizer and I learned a lot, in fact the fuss about our write up rambled on for a couple of years – I’m not going to reopen that here and now. (The full report “What do we think of Conway’s Law now?” is available for download from allankelly.net.)

Ever since then one of my mental models has been the organisation structure is the software architecture, I may no longer change code but by changing organizations I am practicing software architecture.

Right now my head is buzzing with thoughts on Continuous Delivery, Conway’s Law, Team Structure, Scaling Agile and how this all fits with the Beyond Projects / No Projects agenda. I feel that if I can just make sense of all this I’m on the verge of some great breakthrough!

‘‘Knowledge work is not easily defined in quantitative terms, . . . To make knowledge work productive will be the great management task of this century, just as to make manual work productive was the great management task of the last century.’’ Peter Drucker (1969)

In recent months I have repeatedly been reminded of an argument, or perhaps a hypothesis, I advanced in my 2008 book Changing Software Development. In the introduction chapter I suggested that software developers might be regarded as the prototype of future knowledge workers. I’ve republished “Prototype of Future Knowledge Workers” as a blog post yesterday.

I’ve been reminded of this in a number of casual conversations recently, like the one I had with Laurie Young (@wildfalcon), again when rereading some Peter Drucker and because of media pieces like one in the Financial Times (“Do it like a software developer” by Lisa Pollack) suggesting that companies with successful software development teams might have something to teach other companies, and also by the topics submitted to the Agile on the Beach conference.

Let me explain, firstly let me explain why I make this argument, then let me explain the significance – and with reference to Agile – and finally, for completeness let me quote from the book…

Software Developers – programmers, testers, and everyone else – are what academics would call knowledge workers. We work with our brains rather than our brawn. We generate value because of what we know and what that knowledge allows us to do.

There are lots of other knowledge workers, teachers, lawyers, doctors, and during the twentieth century the number of knowledge work professions and number of knowledge workers grew.

In many ways software developers are no different, but in one very important ways they are very different. Software developers are able to create new tools for machines which allow them to change the way they do knowledge work.

Think about some of the tools your common knowledge worker uses during the typical day:

• E-mail: invented by Ray Tomlinson, a programmer
• Spreadsheets: invented by programmers Dan Bricklin and Bob Frankston
• The Web: invented by programmer Tim Berners-Lee
• Wiki sites: invented by programmer Ward Cunningham

Even if Twitter, FaceBook, Video conferencing, Voice over IP and countless other knowledge sharing and collaboration technologies were not invented by programmers I will bet good money on one common factor: software developers, programmers, had early, if not first access to these technologies. That is very very significant.

Lets be clear:

• Unlike other knowledge workers software developers have the ability to create new tools which can change their work.
• Software developers have early, if not first, access to tools which benefit knowledge work.

One might also add that people working with technology welcome and embrace new tools and technologies (on the whole) so the barriers for technology change are lower.

This means those working in software technology – and particularly those developing software – have more experience and most history of using these tools, and consequently are the likely to be the most adapted to working with these tools.

Thus if you want to see how new technologies, new tools, will change knowledge work look at those who create the tools and those closest to them. This shouldn’t be a surprise, after all knowledge work is about managing and using information, and these technologists create the tools we use to store, retrieve, manage, manipulate, combine, and share information.

(And there is a difference between knowledge and information but I’m not going into that here, its in the book.)

By itself this argument is interesting and perhaps good for developer self-esteem. We could leave it there but…. it also begs a question:

If software developers are the prototype of future knowledge workers what does it suggest will happen next? Specifically, how can this insight help answer the challenge posed by Peter Drucker above?

As a step towards answering those two questions let us rephrase the question:

• What are software developers doing today which might benefit other workers?
• Or to put it in Drucker’s language: what can managers of non-software staff learn from software teams which will make their teams more productive?

One way would be to look at the tools software developers are using today which might benefit other groups.

Version control springs to mind but version control has existed for at least 30 years and hasn’t caught on with the masses. We could continue to examine the toolset, one of my favourites is Markdown. Or we could look at the way software developers are managed. This was the thrust of the FT piece which looked at personnel management (I refuse to say HR) practices.

But there is something else… Agile itself.

One of the reasons I believe Agile came about was that the tools we use changes. Cobol gave way to Java which gave way to Ruby. OS/360 gave way to VMS which gave way to Windows (or was it Unix?) which gave way to Unix derivatives. One might say paper gave way to the web and wiki’s, telephones gave way to VOIP, telegraphs gave way to Twitter.

Our tools changed which allowed – even forced? – our processes to change. As knowledge workers outside of IT embrace these these tools its possible that their working practices will change in a similar way. My favourite example is a presentation given by Kate Sullivan at Agile on the Beach two years ago in which she described how the legal department at Lonely Planet adopted Agile.

There are several Agile practices which area are easier to imagine outside of software than others. For example:

• Visual boards: lots of places!
• Standup meetings: example abound and usually predate Agile, e.g. bar staff, Japanese office workers, NATO commanders (in Bosnia and probably elsewhere)
• Test driven working: consider many of the business examples from Lean Start-Up
• Pair programming: airline pilots and surgeons have been doing this for a long time but Kate added Pair Lawyering
• Iterations: although I’ve yet to get a concrete example most news organizations clearly operate in daily iterations

During the second half of last year I was involved with a client whose project was to write documentation. Specifications to be precision but not specifications for software – there was an element of that but that was not the aim. We used iterations, visual board and other techniques. We even used a walking skeleton. It worked. We delivered to schedule.

We in software have developed something good. Something that is spreading beyond software. Now I wonder, whats next?

The following is an except from my 2008 book “Changing Software Development: Learning to be Agile”. I’ve been thinking about this suggestion a lot recently and have a blog post in the works. Hence I thought now would be a good time to share this, it also means I can reference this post in the one that comes next… and who know, I might even rustle up a few sales for the book!

The Prototype of Future Knowledge Workers

Highlighting IT workers as knowledge workers allows us to learn from the existing body of knowledge on the subject. IT workers are not alone; they are knowledge workers and there’s much to learn from other knowledge workers, and from research and literature about knowledge work in general. There’s no need for IT managers (and writers) to re-invent the wheel.

Yet, in another way, the existing literature, research and experience can’t help IT workers and their managers. This is because IT workers, and software developers in particular, are at the cutting edge of knowledge work. In many ways, they’re the prototype of the future knowledge worker; they’re pushing the boundaries of twenty-first century knowledge work.

This occurs because, to paraphrase Karl Marx, software developers control the means of production. Modern knowledge work is enabled by and dependent on information technology: e-mail for communication, web sites for distribution, databases for storage, word processors for writing reports, spreadsheets for analysis – the list is endless! These technologies are created by software developers and used by legions of knowledge workers worldwide. The key difference between software knowledge workers and the others is that other knowledge workers can only use the tools that exist. If a tool doesn’t exist, they can’t use it. Conversely, software developers have the means to create any tool they can imagine.

Consequently, it was a programmer, Ward Cunningham, who invented the Wiki. Programmers Dan Bricklin and Bob Frankston invented the electronic spreadsheet. Even earlier, it was another programmer, Ray Tomlinson, who invented inter-machine e-mail. This doesn’t mean that non-programmers can’t invent electronic tools. Others can invent tools, but for programmers the barriers between imagining a tool and creating the tool are far lower.

Lower barriers mean that programmers create many more tools than other types of worker. Some tools fail, while others are very specific to a specific problem, organization or task in hand, but when tools do work it is programmers who get to use them first. In addition, because IT people have had Internet access for far longer than any other group, the propensity to use it to find tools and share new tools is far greater. So tools such as Cunningham’s Wiki were in common use by software developers years before they were used by other knowledge workers.

Early Internet access has had other effects too: IT workers were early adopters of remote working, either as individual home workers or as members of remote development teams; IT people are far more likely to turn to the Web for assistance with problems and more likely to find it, because IT information has been stored on the Web since the very beginning.

The net effect of these factors and others means that software developers are often the first to adopt new tools and techniques in their knowledge work. They’re also the first to find problems with such tools and techniques. Consequently, these workers are at the cutting edge of twenty-first century knowledge work; they are the prototype for other knowledge workers. Other knowledge workers, and their managers, can learn from the way in which IT people work today, provided that we recognize these workers as knowledge workers.

From “Changing Software Development: Learning to be Agile” by Allan Kelly, 2008.

The dissertation/thesis writing season is approaching so I expect the recent set of questions from a student is the first of many. Actually they occur all year round but March to September is the busy period. So, to pre-empt any students bearing questions about Agile – and so I can just repeat my stock answers – here are some ideas you might want to consider first.

Lets start with the request itself.

I and many other people who are silly enough to write and blog about Agile software development get plenty of e-mail from students doing research on Agile. Fair enough, I like to help but if you don’t ask nicely I’m unlikely to respond.

• I won’t be answering stock surveys that are sent from a mail program.
• I’m much more likely to answer a personal request which indicates you actually know my name and even read some of what I have written.

I’m skeptical of most quantitive research (e.g. surveys) research on Agile simply because the question that I normally see are rubbish. Qualitative research is probably better but

1. It is not as satisfying as quantitive, you can’t conclude “58% of teams use Agile” you come up with some wishy-washy case studies
2. You actually have to go and talk to people, you can’t just compile a mailing list and feed it into Survey Monkey. That means getting out and finding people to talk to

If you must go down the quantitative route please do your homework, do some qualitative before you begin so you can ask good questions.

Now the number one mistake made by students who approach me is: Assuming there is such a thing as Agile.

That is to say assuming:

• one is either Agile or not Agile,
• secondly: one knows that one is, or is not Agile and
• thirdly: one is prepared to openly and honestly state it.

Agile is not binary. Nor for that matter is Waterfall. While we are about it Agile and Waterfall are not necessarily binary alternatives. Have a look at my Agile Spectrum article: the thing that is called “Agile”, and the thing that is called “Waterfall” are simply points on a spectrum – probably the two extremes – and most teams are somewhere in-between.

Nor is there anyway (at the moment) to objectively determine where a team is on the spectrum. Well actually there are plenty of people who will do an assessment of one sort or another but you have to look at what criteria they are using. My suggestion is get away from Agile as a whole and look at Agile practices.

Likewise get away from the methods – Scrum, XP, Kanban, etc. If you must look at different methods look at them in the context of practices. Agile methods are sets of practices, sometimes with values and principles thrown in.

Practices are the easiest of these things to observe and measure. They are objective, the other bits are subjective.

If you really want to dig deep – and make work for yourselves – you might want to investigate team values – do teams actually value the things Agile claims to value? This is going to take some doing. You probably want to look at what actually happens, shadow a manager for a week and see if their decisions accord with the values.

You might do it quantitatively by composing one of those surveys that asks people to choose between answers, e.g. “Under pressure to ship more often which are you most likely to do: a) make your stories smaller, b) offer financial incentives to the team, c) reduce unit testing, d) increase unit testing”.

Now some suggestions for some research, Agile research questions:

• Validate my spectrum: its a hypothesis, come up with some criteria and do a survey to see if you can determine the spread
• Practices: what are the practices that teams actually use? Specifically, what are the practices they say they use and which ones do they actually use?
• Which practices are the most popular?
• What difference do the practices make?
• How does Agile differ between product development companies and corporate IT? Add “solution providers” (e.g. Accenture, EDS, CapGemini and thousands of smaller companies) for extra marks.
• Correlation of practices to approach: do teams which call themselves Agile actually use practices associated with Agile? And likewise for Waterfall. A couple of years ago a student at Loughborough University, Adam Williams, rose to my challenge. He tried this, his survey was small, 20-odd companies, and he found little correlation at all. In fact he found some teams who described themselves as Waterfall but used several Agile practices. I would love to see this study expanded.
• What do Scrum Masters really do and how are they different from Project Managers?
• What are the recruitment practices of Agile teams and companies?
• Forget Agile, look at Waterfall, find teams who actively claim to do Waterfall and find out what happens, how do the unsuccessful ones differ from the successful? Are there any successful waterfall teams?
• Examine some of the more controversial practices: TDD, pair programming, refactoring. Do a meta-analysis of the studies to date or do your own studies.
• Extend Keith Briathwaite’s work the correlation between TDD and cyclomatic complexity.
• TDD, benefits and the power law – I should blog about this but for now just take my word for it.

Finally the big one.

Real Agility is not about methods, practices or names, it is the state of being Agile. (Something that was meant to be in the title of my first book but was messed up.)

• What is the state of Agile? – in theory and in reality
• What advantage does the state of Agile confer?

So if any student out there wants to raise to the challenge on these questions please get in contact, I’d love to help and to see the final research.

In the furious discussion over my “Programmers without TDD will be unemployable” last month a couple of people asked: “How will this come to pass?” And a few others said: “Managers will never let this happen.” Let me answer both these comments in one go:

Managers are the missing link between today’s largely TDD-free code development and the 2022 world where TDD will be essential to get a job.

I know not few managers are perfect. And I accept that there are managers out there who might not want their developers doing Test Driven Development. But in my experience you don’t need to be a perfect manager to understand the logic of TDD, a quick look at the Microsoft research study should address that.

And in my experience it is developers rather than managers are the biggest block to practising TDD effectively. I can usually persuade a manager that their developers should do TDD. I can even (sometimes) – putting on my salesman hat – persuade them to spend money on training and/or coaching for developers to learn TDD.

What I find a much greater challenge is persuading developers that TDD might be beneficial to them. That TDD might help them find bugs quicker, or that their legacy code would benefit, or that it will help them separate business and UI logic. Just persuading programmers to code in a different way is hard.

And it is even harder to persuade them that having some help, going on a course or having some coaching, is a faster route to proficiency than reading a book and watching some screencasts.

I know TDD is not a panacea but I do think it is the best we’ve got right now. I know it doesn’t cure all known ills. And I know that in some cases the wrong solution, I know that other techniques – code reviews and functional languages for example – can also reduce bugs but…

Firstly too many developers question TDD without properly trying it, and they propose alternative remedies which also fail to get tried.

Secondly, as I said: managers are not perfect. You don’t need to be a perfect manager (indeed few, if any, are).

I predict that once Development Managers get the TDD-bug they will over do it. TDD will be mandated even when it is not applicable, or when another solution might be better. For a while TDD will be a management fad.

That also mean that the style and quality of TDD will be massively variable. Like Agile before it will be a buzz-word for the developer CV (resume) and more importantly, for the Manager CV.

In the same way that Managers will not employ Programmers who don’t know how to TDD – and are not enthusiastic about it – Managers will not get employed if they don’t expect their programmers to do TDD.

Managers who think TDD is a waste of time will be unemployable before 2022.

Even managers have managers. Even managers need to get new jobs from time to time.

I often meet programmers who tell me “I would like to do TDD but our managers won’t let us” but I have never met a manager who has ever said: “My programmers want to do TDD but I have forbidden it.” Managers, particularly the better ones, are open to hearing better ways.

Look at the blog comments after the “Programmers without TDD” post – on my blog, on DZone, JavaCodeGeeks and the other sites where it was syndicated. There are several programmers saying “Managers won’t let it happen” or “It doesn’t work” but I don’t recall even one manager saying “I’ve stopped my developers from doing TDD.”

Whenever a programmer tells me “I would like to do TDD but my manager won’t let me” I ask: “Have you actually asked the manager concerned? Have you discussed it?” invariably the answer is “No.” Programmers assume their managers’ will not like it.

The quality movement wasn’t always popular, people questioned Philip Crosby’s Quality is Free logic, it took time for the chip industry to change (The Anderson Bombshell) and it took over 20 years for Ford, GM, etc. to match Japanese (Toyota) standards but today you would not get very far if you suggested the Austin Allegro was a good car.

There is another force at work here: companies which don’t take quality seriously, or can’t change fast enough, will lose out to those who do. In the early 1970s British Leyland, later Austin Rover was the third biggest car producer in the world. The bits of the company that embraced quality – Mini, Jaguar and Land Rover – still exist, the rest doesn’t.

The manager connection also explains another question that was posed following my first blog. Several people said: “I can see how software companies get this, but inside corporate IT they will never buy this.”

I understand where these people are coming from, software companies will be the first to mandate TDD, most corporate IT departments will be slow on the uptake but they will come round because:

• Corporate IT has long copied software firms but after a long delay. This pattern will play out with TDD too.
• While some people work their entire careers in corporate IT there are also a lot of people who worked in software companies earlier in their career (such businesses often pay less than corporate IT.) By 2022 the people arriving from software companies into corporate IT will expect to do TDD. And the managers arriving in corporate IT will expect their programmers to do it too.
• Consultancies like Accenture, IBM Global Services, Tata etc. who do outsourced work will pick up TDD from software companies (they see themselves as software companies). When people move from these companies to corporate IT groups they will take TDD with them, when software passes from the outsourcer to the client it will come with tests, and when corporate IT looks for best practice (O, how they love best practice!) they will find TDD.
• Graduates from the better colleges and universities will also arrive expecting to do TDD.

If you followed the comments and Tweets surrounding the original post you will have seen several people say their company already mandated TDD for new recruits. Each one of those companies, to the best of my knowledge, has high performing teams which deliver software which contributes directly to company success. Why wouldn’t a manager want that?

Developers, programmers, may have started the TDD ball rolling but it is managers who will finish the job.