Agile: Where's the evidence?

A few weeks ago I was presenting at the BCS SIGIST conference - another outing for my popular Objective Agility presentation. Someone in the audience asked: “Where is the evidence that Agile works?”

My response was in two parts. First although it sounds like a reasonable question I’ve come to believe that this is a question that is asked by those who don’t believe in Agile, those who want to stall thing. It is rarely a question aimed at a rational decision.

Second I said: lets turn the question around, Where is the evidence for Waterfall? - as far as I know there is none, although there are plenty of cases of failed projects.

Now this was a pretty flippant answer, I was in show mode and as someone later asked: “Do you really recommend we ridicule people who ask for evidence?”, to which the answer is certainly No.

So let me try and answer the question more seriously.

Lets start with “Agile.” How do we define Agile? Scrum? XP? Where does Agile start and Lean begin, or vice-versa? Or, as I believe, Agile is a form of Lean?

We have a definition problem. Agile is poorly defined. I e-mailed a friend of mine who is undertaking a PhD in Architecture and Agile and asked him: Can you please point me at a literature review?

(Notice, if I was a serious researcher I would closet myself in the library for days or weeks and do the literature review myself. I’m not and I need to earn money so I I didn’t.)

His answer: “that's an interesting question because a lot of research simply assumes that agile (as a whole) is better, without any evidence for it.”

Michael also pointed out there is a context issue here. Embedded systems? Web development? Finance? Health care?

And how do you define better? Better architecture? Better requirements? Better code quality?

And Better compared to what? Chaos? Good waterfall? Bad waterfall? CMMI level 1? 2? 3? 4? 5?

You see, context.

Despite this one study claimed Scrum resulted in productivity improvements of as much as 600% - Benefield, “Rolling Out Agile in a Large Enterprise”. I’ve even heard Jeff Sutherland verbally claim Scrum can deliver 1000% improvement. To be honest I don’t believe this figures. If they are possible then I think it says something about chaotic state the organisations started in. In these cases my guess is following any process or practice would be an improvement. Standing on one leg every morning would probably have generated a 50% improvement alone.

There is a trap for Agile here. Much traditional work has defined better as: On schedule/time, on budget/cost with the desired features/functionality. But Agile doesn’t accept that as better, Agile negotiates over features/functionality and aims for business value. A report from Cranfield University a few years ago suggested than much traditional IT work failed to truly capture business value because people focused on: time, budget, features.

Then there is a question of bugs. Traditional development has been very accepting of bugs, Agile isn’t.

Maybe asking for evidence about Agile is aiming for too much. Maybe we should look at the practices instead. Here there is some evidence.

Over the years there have been various studies on pair programming which have been contradictory. Since most of these studies have been conducted on students you might well question the reliability.

Test Driven Development is clearer. As I blogged two years ago there is a study from Microsoft Research and North Carolina University which is pretty conclusive on this, TDD leads to vastly fewer bugs.

Keith Braithwaite has also done some great work looking at Cyclomatic Complexity of code and there seems to be a correlation between test coverage and better (i.e. lower) cyclomatic complexity. Keith is very careful point out that correlation does not imply cause although one might hypothesis that test driven development leads to “better” design.

TDD and source code are relatively easy to measure. I’m not really sure how you would determine whether Planning Meetings or User Stories worked. Maybe you might get somewhere with retrospectives. Measure how long a team spends in retrospectives, see if the following iteration delivers more or less as a result.

For their book Organizational Patterns of Agile Software Development Coplien and Harrison spent over 10 years assessing teams. This lead to a set of patterns which describe much of Agile software development. This is qualitative, or grounded, research rather than qualitative but is just as value.

At this point I probably should seclude myself in the British Library for a week to research each practice. Maybe I should, or maybe you want to call me an charlatan. Next year, maybe.

If we switch from hard core research to anecdotal evidence and case studies things become easier. As many readers know I’ve been working with teams in Cornwall for over 18 months. On my last visit we held a workshop with the leaders of the companies and software teams. Without naming names some comments stood out here:

• “The main benefit [of Agile] was time to market... I don’t know how we would have done it without Agile”
• “Agile has changed the way we run the company”
• “It is hard to imagine a world without Agile”

That last company is now finding their source code base is shrinking. As they have added more and more automated tests the design has changed and they don’t see the need for vast swaths of code. Is that success? Each line of code is now far more expensive and they have less. (Heaven only knows what it does to function point analysis.)

If you want something a little more grounded there was a recent Forrester report (sorry, I can’t afford the full report) which said: “Agile enables early detection of issues and mid-course corrections because it delivers artefacts much sooner and more often. Finally, Agile improves IT alignment with business goals and customer satisfaction.”

Before this there was a Gartner report in which said: “It's a fact that agile efforts differ substantially from waterfall projects. It's also a fact that agile methods provide substantial benefits for appropriate business processes.” (Agile Development: Fact or Fiction, 2006).

But I’m back to that nebulous thing “Agile.”

All in all I can’t present you any clear cut evidence that “Agile works”. I think there is enough evidence to believe that Agile might be a good thing and deserves a look.

What I haven’t done is look for, let alone present, any evidence that Waterfall works.

Frankly I don’t believe Waterfall ever worked. Full stop. Winston Royce who defined “the waterfall” didn’t so why should I? (You have to read to the end of the paper.)

OK, sometimes, to save myself form a boring conversation or to cut to the chase I’m prepared to concede that: Waterfall worked in 1972 on developments using Cobol on OS/360 with an IMS database. But this isn’t 1972, you aren’t working on OS/360 and very few of you are using Cobol with IMS.

(I have seen inside an Z-OS Cobol IMS team more recently and something not unlike waterfall kind of worked, but the company concerned found it expensive, slow and troublesome and wanted them to be “Agile.”)

Even if I could present you with some research that showed Agile, or Waterfall, did work then it is unlikely that the context for that research would meet you context.

(Thus, if you do want to stall the Agile people in your company, first ask “Where is the evidence Agile works?”. When they produce it ask “How does this relate to our company? This is not our technology/market/country/etc. etc.”)

I think it might come down to one question: Is software development a defined process activity or an empirical process activity?

If you believe you can follow a defined process and write down a process to follow and the requirements of the thing you wish to build then waterfall is probably for you. On the other hand, if you believe the requirements, process, technology and a lot else defies definition then Agile is for you.

Finally, the evidence must be in the results. You organisation, your challenges, your context, are unique to you. So my suggestion is: make your own evidence.

Set up two similar teams. Tell one work Waterfall and one to Agile and let them get on with it. Come back every six months and see how they are doing.

Anyone want to give it a try?

And if anyone knows of any research please please please let me know!

(Many thanks to Michael Waterman for a very thoughtful e-mail which filled in some of the missing pieces for this blog.)

Technical debt - developer moans

A few days ago I pushed out a couple of Tweets which got quite a reaction:

“I am fed up hearing developers complain of Technical Debt as if it has nothing to do with them. Who writes this stuff?”

and

“Devs say 'look technical debt' like 'look its snowing'. As if it has nothing to do with them”

It was that second one that got a hail of re-tweets.

So I thought I should add a few words of explanation here.

First it is important to say that the these tweets were not aimed at, or about, anyone in particular. I’ve visited a bunch of companies and delivered a lot of training in the last few months and the topic of technical debt comes up a lot. If I had anyone in mind about these comments in particular it was a developer I worked with four or five years ago but his sentiments are common.

Second, I’m not sounding off about developers. I love developers, I used to be one. I’ve had the same feelings myself at times, speak to people who managed me way back when and I probably moaned about the same things. (Over 10 years ago I wrote High Church C++ where I agonised about the right way to write code.)

What I am taking aim at is an attitude which says: “There is this thing called Technical Debt, we have it, it makes our lives hard, we want it to go away, but we have nothing to do with creating the problem and we need a special solution.”

It sometimes seems to me that having labeled the phenomenon developers are too keen to use the label. Steve Freeman and Chris Matts have tried to recast the debate in terms of real options “Bad code isn’t Technical Debt, it’s an unhedged Call Option”. Intellectually I agree with them but I find that the explanation required to explain an “Unhedged Call Option” is greater than the explanation to explain the original problem so I’m not sure what the metaphor adds to the debate.

The other problem with switching to an “unhedged call option” metaphor is that it perpetuates the Quick and Dirty Myth - the idea that doing a bodge-job now will pay back in shorter delivery time. In reality the reverse is just the case, I gave some statistics on this in my blogs last year about Capers Jones book Applied Software Measurement.

Common reasons given for the existence of technical debt are:

• It was the developers who where here before us
• We don’t have the time to fix it
• The managers made us do it, or The business demands this
• Its the Architects

(Notice the current developers are never to blame - and as much as I don’t want blame thrown around thats the debate is too often framed.)

Anyway, none of these reasons really stand up to analysis, except perhaps the last one.

Regardless of what the developers who were here before did the current developers should be addressing the issues. It is the current developers who need to live in this code, if they don’t like it they should do something about it.

Sure there may not be time to stop the world and fix everything but you don’t need to. You just need to fix a little bit every time. As Uncle Bob Martin says in Clean Code, follow the Boy Scouts Rule “Leave the code slightly better than you found it.” Then let the Power Law work its magic.

Secondly, there is more time if you do it right. Building quality, bug free, systems is faster than the alternative. Forget the Quick and Dirty Myth, its Slow and Dirty or Quick and Right.

(Sometimes I meet developers who want to “stop the world” and re-write the system. I’ve also on occasion met managers who have bought into this argument and stopped the world. This is a seriously bad idea, its why Netscape no longer exists: developers were allowed to re-write Navigator, as they were doing so Microsoft attacked.

I keep meaning to blog about “version 2” now I must, just watch this space.

Twice I’ve come across Managers who told the team they could re-write. In the first case the managers were lying. The developers, well one specifically, held a gun to their head and said “I’m resigning on 14 February if you don’t let me rewrite”. In that situation you should let them resign, these managers were scared of the developer. As far as I can tell things didn’t work out, the developer left the company not long after and the company was sold.

In the second case the Managers were either stupid or desperate. In either case within days of starting the “Technical Improvement Programme” (TIP) they found it wasn’t that easy and things started to revert to usual.)

Getting back on topic...

Unless Project Managers and Business Analysts sneak into the building at night and change code when developers aren’t looking then managers do not write code. Nor does the nebulous unit called “the business”. It is developers hands on the keyboard, “I was only following orders” is not an acceptable defence.

There is a professionalism issue here. Software Engineers need to take their work seriously and create code they are proud of. This is not to say they should start gold plating things but being an professional engineer means you don’t do shoddy work.

Architects may be the only defence I might accept: however this defence is only applicable when the organisation and architects are committing an even bigger sin, namely Architects who Don’t code, or Architects who don’t understand the system - usually these two go hand in hand.

If the architect(s) code then they are part of the development team, they see the same problem, they have the same complaints. Now it is just possible that the architect does code and they aren’t very good. Or rather, the Architects understanding is different to that of the developers, which might point to issues of recruitment, the architects style or bad team dynamics.

The reason I might accept this reason is that it points to an even bigger problem for the organisation and it does imply engineers are pull in opposite directions.

Interestingly Ron Jeffries replied on Twitter, and said “Ward [Cunningham] originally defined tech debt as reflecting later learning, not available at the time of construction.”

I think its time we returned to this definition. Its not about other developer, the business, architects or others creating technical debt for poor developers. Its about developers improving their own understanding. Its about the need for refactoring. And it most definitely is the developers own responsibility and professionalism.

Heresy: My warped, crazy, wrong version of Agile

I increasingly feel that the way I interpret Agile, the practices and the processes, if different to the rest of the world. Perhaps this is just self doubt, perhaps because I started doing Agile-like-things before reading about XP or Scrum, perhaps this is because my version has always been more informed by Lean, perhaps this is because I have never achieved Certified Scrum anything status, perhaps because I’ve never worked for ThoughtWorks, perhaps because I hold and MBA (and thus have an over inflated opinion of myself) or perhaps I’m just wrong.

Yet clients of mine report some success (I even have a couple of case studies). Perhaps this was despite me rather than because of me. In the past I’ve described two of my own Agile systems - Blue-White-Red and Xanpan, these are my attempts to describe how I see the development working without being constrained by other systems (sometimes I think of own-brand-cola methods.)

Here is where I feel I differ from the Agile mainstream, or perhaps, just Scrum:

• I don’t it is wrong to carry work from one sprint/iteration to the next
• I don’t believe in Scrum Masters; where Scrum Masters exists I think they are a kind-of Project Manager; and I believe Scrum Master Certification is a con (but I would, wouldn’t I?) that is potentially damaging the industry and Agile
• I don’t believe team Commitment works, its too open to gaming
• I don’t think Agile has cracked the requirements side of the business, we’re working on it, things are getting better
• I don’t believe Agile has cracked relational database management system; but I think much of the problem lies with the DBMS vendors
• I don’t believe Agile Coaching is different enough from Agile Consulting to justify the name
• I don’t really believe in offshore-outsourcing; OK, it can work but the companies that use it seem to be those who shouldn’t and those who are equipped to use it don’t need to
• I don’t believe you can tell how long a piece of work will take (or how much it will cost) until you start doing it. And I believe it is wrong to pretend you can.
• I don’t believe Scrum (specifically) really understands the requirements side; and I believe the Scrum Product Owner is a pale shadow of Product Manager role which is (often) needed
• I don’t believe in One Product Owner to Rule them all; on a large development effort the Product Owner role needs to be refactored (damn, I need to blog more about that)
• I don’t believe all companies can, or will, make the transition to Agile; but that many of these companies will stagger on for years while more Agile competitors take their market
• I don’t believe Agile will ever work in Cobol teams, or not Agile-as-we-know it; anyway, Cobol teams which still exists are highly adapted to their environment.
• I believe Agile is a dirty word in some circles and has been used and abused; but I don’t believe there is an alternative (at least not right now)
• I don’t believe the Dreyfus model of learning is the right model for Agile, I think it makes work for consultants and creates Learned Dependency, I prefer the Constructivism model

Its not all bad, there are some things I believe:

• I believe Agile means “Better”
• I believe the Agile Manifesto is a historic document like the US Constitution, and like the constitution we can read all sorts of meaning into it, depending on who you are you read different things. But there is no Supreme Court to arbitrate on whats-what. So Agile is “what I say it is” - or maybe, like “art is what artists do”, “Agile is what Agile advocates say it is”
• I believe Agile is, and always has been about flow, some people might not get it, and the some in the Kanban crowd might have come to it late but its always been there
• I believe in breaking User Stories down - I mean, I’d love it if teams didn’t have to break them down and I aim to take them there one day, but its a long journey
• I believe the Product Owner role is far more important than the Scrum Master
• I believe “Project” is an accountancy term that has wrongly become attached to development work
• I believe in the Planning Fallacy
• I believe Developers are the centre of the process, ‘Work Flows Inward’ as the Pattern says
• I still believe in Story Points, or rather, the things I call Abstract Points
• And I believe Abstract Points should be assigned to task; I don’t believe in using different currencies for tasks and stories (i.e. don’t use hours for tasks and story points for stories)
• I believe planning meetings, work break down and assigning points is as much about design as it is about work scheduling
• I believe engineering quality is essential to achieving Agility
• I believe in Software Craftsmanship and don’t think Agile will ever work if quality isn’t fixed
• I believe every organisation has to define its own version of “Agile” - you can’t take Scrum (or any other method) off the shelf
• I believe too much advice and consultancy can stifle an organisation, I believe in light-touch consulting to help companies find their own path
• I believe that in many companies - corporate IT departments specifically - the right approach is to “do things right, then do the right thing”
• I believe when you apply Agile thinking outside of IT it is Lean
• I believe speaking out against Scrum is bad for the reputation and the Scrum Mafia will come after you in a dark alley

Gee, this starts to sound like Allan’s manifesto! Anyone want to sign? :)
- OK, the last point was a bit of a joke :)

I’ve linked to some blogs and such where I have previously discussed these items, and I might expand on some in future. Many of the issues raised here are complex and I really don’t have the time to explain them right now, so next time you see me ask me to discuss.

Now out: Business Patterns

Business Patterns for Software Developers is now out!
Early too!

See for yourself:


Some frequently asked questions:
Q: How long did it take to write?
A: Eight years end to end, although the first patterns aren’t in the book, in fact I didn’t realise I was writing a book until about 2008. Years 6 and 8 were the busy ones.

Q: What is a business patterns?
A: Its like a software pattern, or an architecture pattern, but concerns itself with business and business strategy.

Q: Is it available on Kindle?
A: Not immediately but it will be in a few weeks

Q: Where can I read more about the book?
A: Early versions of most of the pattern are available for free on my website - follow links for business strategy design patterns

Q: What are the buildings on the cover?
A: The Three Graces on Liverpool pier head, a UNESCO World Heritage site. I prefer the daylight pictures but the evening picture on the cover works well in the design.

The Meter: Tom Giib's greatest invention

If you’ve ever found the time to read Tom Gilb’s work - and I’m thinking specifically of Competitive Engineering here - you’ll know that his work is packed full of good ideas. So many god ideas in fact that it can be hard to read his book - something I think he admits himself in the opening pages of Competitive Engineering.

One of his ideas is that of a Meter. This alway confuses me a little, still now...

You: A Metre you say?
Me: No, not a metric unit of distance, a Meter, as in a Gas Meter
You: What, how can a Gas Meter help software teams?
Me: No, the idea of measuring things, scrum that, say a Ruler
You: A ruler? Centimeters and inches?
Me: No, A yard stick
You: Distance again?
Me: No, A unit of measurement and a tool for measuring
You: Measuring what?
Me: Yes, Measuring what, that’s Tom’s great invention, we need to define measuring systems

Tom’s great invention is: define a mechanism for measuring the thing which is important to you.

OK, Tom takes the idea further with Plangauge he says we should define the meter, the starting value and the desired value. But forget values, its the measurement unit itself which I think is too frequently overlooked and worth more attention.

The thing is, the unit of measurement, and the means of measuring it is implicit in a lot of work: its in Kaplan & Norton’s Balanced Scorecard, its in Beyond Budgeting, its in Lean Start-Up and elsewhere.

But, as far as I know, only Tom calls the Meter out as an idea in its own right. In fact, I suspect Tom might not have realised the significance of this.

Once you know what the right Meter is it becomes - relatively - easy to measure things. So you can measure the starting point, you can set a target, and you can measure how far you have got.

We are surrounded my measurement units and meters which already exist

• Currency: Pounds, Dollars, Euros, etc. etc. - and the associated profit, revenue, costs, etc. etc.
• Accounts: Profit, revenue, costs
• Website hits: visitors, unique hits, conversions, etc. etc.
• Time: second, minutes, days....
• Distance: inches, miles, centimetres, meters and kilometres
• Location: Latitude and Longitude
• Weight:.....

And we tend to use these measuring units again and their associated meters again and again.

New meters are not so common but they occur, e.g. Eric Ries in Lean Start-Up introduces a new meter: Cohort Analysis.

But - big but - if we use inappropriate measuring units and meters it gets hard, and it potentially gets wrong. (Another on of Eric’s points.)

Again, as far as I know, Tom is the only authority who says: define your own unit and define your own way of measuring it.

Now, as far as I can tell Tom is a master of this, the rest of us... well most people don’t get it and try and use pre-defined measurements and Meters, even those of us who “get it” struggle with it.

So, we need to start inventing new units of measurement and new ways of measuring things. We need to get good at both inventing these things and sharing them. History shows many of these measuring units are useful to other people.

Second, as more of these units are recognised then we will have more mechanisms - and language - with which to implement both our own tools and the tools like Balanced Score Card and Lean Startup.

Corporate Psychopathy

The Oxford Dictionary of English on my Kindle defines:

Psychopathy n. mental illness or disorder.

Psychopathic is more interesting:

Psychopathic adj. suffering from or constituting a chronic mental disorder with abnormal or violent social behaviour

There is a reoccurring pattern of behaviour I have observed in corporate environments which I have taken to calling Corporate Psychopathy, maybe you’ll recognise it if I describe it.

• A company brings together a team to do some work. At some date they decide the work is “done” and disband the team. They often call this work “a project” - projects by their definition have a start date and an end date, and involve a temporary organisation unit; i.e. a team is brought together at the start, they do some work, then the team is disbanded.

I think this state of affairs is crazy. So crazy I believe it is abnormal social behaviour.

A team is a social unit. When was the last time you dumped all your friends and started to forma a new group?

Think of the high performing teams you know: sports teams or successful political parties. They may change players from time to time, even key players, but the winning team usually stays together from one victory to the next.

By contrast think of the teams who are less successful. How often to do they change personnel How often do they work together?

Anyone who has studies team dynamics will probably have come across Buckman’s “Storming, Forming, Norming and Performing” model. The idea is that when you bring a team together they pass through each phase as they learn to work effectively together.

If you have an effective team - one that has passed through storming, forming and norming and is now performing - why would you break them up? Let alone break up one team and create a new team which has to pass through three phases to get to the productive fourth?

It doesn’t make sense.

Just to make it worse when corporations break up teams many of the people leave for ever. Companies which use contract staff release the contractors who will go and work somewhere else. Even permanent staff may well find themselves release to a pool, or to previous roles and the same people are unlikely to work together again. Knowledge evaporates in the process.

If that isn’t enough think of the admin overhead in managing all this.

It also makes the start of a work incredibly difficult because you don’t know how effective a team will be or when they will break through into Performing. And if you are following a development method where you measure capacity (velocity) and benchmark against past performance you can’t use this method for the first few weeks.

Its psychopathic: anti-social, performance reducing, expensive, undermines forecasting and increases risk.

Put it another way: It is plain stupid.

My solution is keep the performing team together as much as possible and bring the work to the team. Have the team move from one piece of work to another together.

This parallels the way we timebox work. In timeboxing we fit the work to the time allowed - a two week sprint or a quarterly release. Similarly we should bring the work to the team.

Of course teams might not have very clear cut switch over dates. Perhaps they have to ramp-down one stream of work while ramping up another. More complex to manage.

Or perhaps a performing team splits into two - like cell division. One part continues working on the first piece of work while the second part starts something new. This way the team can carry the culture from one piece of work to another.

To do this is might be necessary to let the team grow organically, split the team, then grow both sides organically.

The point is: there are ways of managing this. You don’t have to split teams up and form them all anew.

Dialogue Sheets on show at Skills Matter - 13 February

Quick follow up to the last entry about Dialogue Sheets. I’ll be doing a evening session at Skills Matter on the sheets next month - 13 February, “Dialogue Sheets a New Tool for Retrospectives”. The event is free but registration is required.

Retrospective Dialogue Sheets in InfoQ

Happy new year! - my opening missive for the new year is elsewhere...

I’ve written more about Retrospective Dialogue Sheets for this weeks InfoQ - “Dialogue Sheets: A new tool for retrospectives.”

This piece summarises many of the findings I discussed a few weeks ago in Dialogue Sheets feedback #1 and Dialogue Sheets feedback #2 blog entries.

A footnote to a footnote, I discussed dialog sheet print-on-demand a few weeks ago. After that I was able to reduce the price of printed sheets. As I suspected at the time the price reduction has made no difference to the number of people using the service. I therefore conclude that it is not the price of the sheets but rather the fact that there is a charge at all the creates the block.

News from the Cornish Software Mines

My work in Cornwall, helping companies adopt Agile approaches to software development, is set to continue into the new year - so more jokey tweets about the Cornish Software Mines. I hope to write more about this work - the benefits and what we’re learning in future.

Right now there are two pieces of news I’d like to share:

• At the start of December the author of PHPUnit, Sebastian Bergmann, joined in me in Cornwall to provide training and coaching to teams using PHP. Oxford Innovation (who run the Grow Cornwall programme) have put out a press release about this.
• Oxford Innovation have also produced a Video Case Study of our work with Research Instruments in Falmouth. RI are a great success story and the case study is worth the two and a half minutes it takes to watch.

I first met the team at RI in October 2010 when I provided Agile foundations training to development team. Since then I’ve been in many times to provide follow up coaching.

About six month after the Agile foundations course Jon Jagger delivered a Test Driven Development (TDD) in C# course for the team and has also been visiting to provide follow up coaching. All in all a great success, as the video shows.

Xanpan, ToC, Guilt, plagiarism and sorry

When I was doing my Masters degree I had it hammered into me: credit your sources, don’t plagiarise. To this day I take pride in trying to credit the source of my thoughts, back-up my ideas with research and apportion credit. I won’t always succeed but I think I do a reasonable job. Heck, I’ll go further, I think I do a better job than most.

So image how I felt after my last blog post, about Xanpan, when Benjamin Mitchell tweeted:

“@allankellynet I'm unclear why you don't mention Theory of Constraints 5 Focussing Steps. What's your thinking on this?”

I was mortified because, well, he was right. My blog post discussing how to improve throughput on a Xanpan board was pretty much a Theory of Constraints description.

I had plagiarised. I had failed to credit. And I had written something that other people have written before - probably better than me.

I apologise, I give due credit: these ideas are inspired by the Theory of Constraints - or ToC for short.

So how did I come to make this mistake?

Well, I think the answer is in two parts:

First, I have ToC thinking to heart and it now seems so obvious I’d forgotten it needed crediting

Second, the blog entry was written a day after I’d had a similar conversation with a client. ToC hadn’t been mentioned in that conversation so it wasn’t mentioned here.

So maybe the plagiarism occurred in my conversation with the client. Well yes, but.... my first point still applied and second I tend to avoid crediting with clients. Now I’d better explain that second point some more.

In conversation with clients I tend to avoid saying things like “This comes from....” or “I suggest you go and read....”. Yes I do say those things but every time I say it I believe there are two ways for a client to take it: they may take it as “good, Allan is giving me the original source” or they may take it as “Hmmm, this consultant is name dropping, doesn’t have ideas himself and is very academic.” (Plus, they are paying for my time so perhaps I should just explain things to them.)

In short I don’t think it always helps.

I also remember all those Professors at Business School who uttered “Smith Smith & Smith, 1904” (or whatever) at the end of every sentence. And those turgid academic journal articles where every paragraph was credited and thus become very very boring to read.

I could go on but you get the message.

Now, one more thing, this blog entry is really really defensive. I feel a little attacked by Benjamin - I’m sure he didn’t mean to attack me, its just in 140 characters people come to the point. Maybe he feels attacked by this, don’t know we could get deeper and deeper.

For anyone still reading, I’m sorry for droning on. However I think this does raise an interesting point: in trying to explain things, in writing and in conversation making things accessible and easy to understand is - in my humble opinion - at odds with academic integrity and full disclosure.

As someone who makes a living doing this I need to be more aware of it than most.