allan kelly

I frequently find myself in situations where someone says something like: “Waterfall is appropriate when…”

Some people out there think there are occasions when an Agile (mainly iterative) approach is “best’ and other occasions when “Waterfall” is “best”. Most of the time I let this line of argument go because its boring, I can’t be bothered arguing. (I’ll look at some of these common objections next time). Right now lets get something out in the open:

• Before you make any decision on Waterfall or Agile define what you mean by “Agile” and “Waterfall”.
• The decision to work Agile or Waterfall should not be based on which is more appropriate.
• The decision on whether to work Agile or Waterfall should be a based on an examination of the business benefits.

Briefly, let me define “Agile” as working and delivering in short iterations and “Waterfall” as delivering in a single pre-planned event.

In cold hard cash the benefits to the business are:

1. Agile working produces a far higher return on investment because benefits are delivered sooner.
2. Agile reduces risk because risk is spread across many independent (consecutive) deliveries.
3. Agile further reduces risk because failure can be identified sooner thereby saving money and time (Fail fast, fail cheap).

Without any other changes I can prove those improvements: they are objective. Using just mathematics without reference to any subjective opinion I can prove those three claims.

There are some other business benefits which are I can show logically although this opens the possibility that some will see these are subjective:

1. Agile creates options for businesses and options have value (see Black-Scholes)
2. Agile creates opportunities to incorporate feedback and incorporating feedback leads to better products
3. Agile (when done properly) improves quality (fewer defects) and fewer software defects leads to short schedules (reduced time) in software development, shorter schedules leads to reduced costs

The question of “appropriateness” is an engineering concept based on the idea that one approach is better for the problem in hand than another. If instead we examine the problem from a business perspective it can be rephrased as:

“How can I maximise the return on investment from this work?”

Given that Agile delivers a greater return on investment than Waterfall surely Agile is the most appropriate method every-time?

Of course “which is better Agile or Waterfall?” has never been about cold rational arguments because as individuals, and as businesses, decisions are very rarely made in such rational terms, despite what one might hope or event claim.

Many teams have some sort of very regular reviews. I’m not thinking personnel reviews or budget reviews, I’m thinking code reviews specifically but it could be test reviews, documentation reviews or some other. Reviews that need to happen every day but which frequently get delayed.

Lets stick with code reviews because they are the type I encounter most often.

Code reviews are good, by some accounts they the most effective means of removing bugs early – although I haven’t seen code reviews compared with TDD. But, code reviews loose their efficacy when they are not conducted promptly. The longer the period between the review being requested and the review being conducted (and by extension the review comments being acted on) the less effective the review.

The effect reduces because: a) the person who requested the review has moved onto something else, b) issues found in the review may be repeated until the review is conducted and c) the review will either inject a delay into the delivery process or the delivery will happen without the review in which case, what was the point?

So: if you are going to conduct reviews you want them to happen soon.

And it is not just the code and the developer who wrote it who have problems. The designated reviewer feels the pressure to “do reviews” when they have other – important! – work to do.

One team I know came up with a simple solution to this problem. I recently recommended the solution to another team who promptly adopted it and are delighted. One developer said: “I’ve never been so relaxed about reviews before.”

The solution is….

Make reviews the first item of work after the stand-up meeting in the morning. And let people do them before the stand-up too.

Thus, as soon as the stand-up is finished everyone undertakes any reviews which are needed before they start their day’s work. Review work is prioritised before new work: after all, yesterday the thing that now requires review was the priority, it is probably still the overall priority and the only thing standing between it and “done” is a review.

Reviews don’t typically take very long so today’s work isn’t delayed. And the recipient of the reviews comments can act on the comments before they get into today’s work.

Better still, knowing that reviews will happen right after the stand-up meeting means that it also makes sense to do the reviews BEFORE the stand-up meeting. This also addresses the question of “how do I usefully use the time before the stand-up meeting when I know I’ll have to stop doing whatever I start.”

So for example, imagine on Tuesday afternoon Bob asks Alice to review the code he has just finished. If Alice is available she might just do it there and then. But if she is busy she will wait. Now if she arrives at work at 9am and the stand-up is 9.30am she can get on with the review before the stand-up, if she finishes Bob will have his feedback and can act on it before 10am. If Alice doesn’t get to Bob’s code then she will do it at 9.45am when the meeting finishes.

Either way, Bob isn’t left waiting.

In part this works simply because it keeps the review queue short. If reviews are done soon, say within 24 hours, then the queue is never allowed to become too big and thus its easy to keep the queue short.

One of the teams actually put a column on their board where tasks awaiting review could rest. In the stand-up everyone could see what was waiting for review and arrange to do it.

Simple really.

While we are on the subject of code reviews let me comment on something else.

There is often a belief that only senior developers, or only “architects” should conduct reviews. I think this approach is mistaken for two reasons.

Firstly in this model it is normal that there are far fewer reviewers than there are review requesters. This frequently results in queues for reviews because the pool of reviewers – who also have other work to do – is small.

Second this model assumes that only “architects” can make useful comments on code. I believe most, say 80%, of the efficacy of a code review is the result not of having an expert review the code but simply the result of having another person review the code.

Indeed I even go as far as to say junior people should review senior people’s code. Code reviews are a two way learning process – one of the reasons I like to see them done face-to-face. If an experienced developer is writing code that a junior cannot understand (why do I think of C++ meta-templates?) then the experienced person should know that they are writing code other people cannot maintain.

Anyway, there you go, let me know if you try this idea and what the result is.

In this social media age I am often surprised by the reaction to what I say online. Usually this is not by the reaction to what I say but rather the lack of reaction. I’ve lost track of the number of times I’ve written what I think is a killer-blog post, or a super meaningful tweet, pushed it out in great anticipation and…. well…. nothing.

Just goes to show: what you think is good and what your “customers” think is good can be two completely different things.

And once in a while the reverse happens. I push out a something I think curious, of minor interest, something unobjectionable and bang!

A week or two back I put out what I thought was a slightly humorous tweet which would be agreeable to many:

“If you manager doesn’t know what technology you are using then they probably shouldn’t be your manager.”

And bang! People – techies! – took exception and rushed to defend managers – usually that is my job!

In a way I was delighted that so many people rushed to defend managers – and to say how managing wasn’t about technology. Most of the IT community damn managers without a second thought. Thanks guys!

Well I feel the need to reply and explain myself more fully. First lets clarify what I mean, then I’ll explain why I think its important.

I friend of mine recently delivered an Agile Introduction course to a client. Before the course the team leader/manager couldn’t tell him what technology the team were using. That is: which language (C#? Java? PHP? Scala?), which operating system (Windows? Linux? MacOS?) or which database (SqlLiite, MySql, SQLServer, Oracle?). Sure we could guess because we knew it was a web development but beyond that…. Anyway, not critical.

This confusion continued at the course itself. Apart from the coder (and possibly the tester) none of the others involved with the work knew which technology was being used.

My interpretation of this situation is: those who didn’t code were disconnected with the work of the technical staff. A gap existed, if they were ignorant of the central technology then what else might they be ignorant of?

(I once heard of a UK Government/BigConsultancy project where when asked “Where are the coders?” a project manager replied “I don’t know, Bangalore I think”. It later transpired they were in Newcastle-upon-Tyne.)

I also take it as a sign that those people do not have a technical (specifically coding) background. I can’t imagine a former coder who doesn’t have some interest in what technology is being used.

The situation clear?

So why is it important?

Lets point out: I’m not for one minute claiming the manager, or requirements analysts etc., need to be able to use these technologies. An appreciation of the technology can be useful, and if they can code they might be able to help, but, too much knowledge can be dangerous. It can lead to the non-coder trying to second guess the coder and tell them in too much detail what they need to do.

I once managed a C# team: as a former C++ and Java coder I could understand and join in the conversations but if I ever felt the urge to reach for the keyboard or tell them how to do their job I knew I would make a fool of myself.

The first reason I think management types should know the technology is exactly as I’ve said above: it shows they understand what is going on. One of the big problems faced today is disconnected managers. This is the reverse of micro-managing, this is what Professor Henry Mintzberg calls macro-leading: ‘people in senior position who try to manage by remote control, disconnected from everything except “the big picture”.’ (Simply Managing, 2013)

That is what I was getting at in my original tweet. If managers don’t know what technology is being used they they are simply too disconnected to be able to manage it. But I will go further….

The second reason is I think management types absolutely do need to understand programming and technology if they are to manage such efforts. I’m fond of saying: “In software development work the devil is in the detail.”

If managers don’t understand the nature of the coding process I don’t think they can manage it. And if they have never coded I find it hard to understand how they will know the nature of coding work.

If managers don’t understand how software is developed – in the real world – then they will impose models of development and management which undermine the work.

If managers don’t appreciate the difficulties that can arise in software development then they will not be in a position to use their authority to help the technical staff. Indeed they may have problems even talking to their technical staff if they lack knowledge.

I don’t believe “if you can manage you can manage anything” – it is a lie. Such advice is a recipe for the kind of mis-management we see all too often in the IT world.

The fact is: if you are developing technology you need to get your hands dirty with technology.

I’ve long been guided by the words of Fred Brooks:

“In many ways, managing a large computer programming project is like managing any other large undertaking – in more ways than most programmers believe. But in many other ways it is different – in more ways than most professional managers expect.” (Brooks, 1975)

(Indeed I chose these words to open Xanpan 2: The Means of Production.)

When I studied management I found much of the advice and good practices were highly applicable to software development. Indeed my Masters dissertation is an examination of how some management ideas map directly into Agile software development. (And yes, that dissertation opens with the same words from Brooks, “Software Development as Organizational Learning” is available to download and formed the beginnings of “Changing Software Development: Learning to be Agile”.)

There is a lot of good management practice and advice out there that many people inside IT and software development would benefit from knowing. But asking a generalist manager to manage a software development effort (always a complex effort) is going to result in problems.

Let me quote again from Henry Mintzberg:

“Managers deal with the messy stuff – the intractable problems, the complicated problems. … put together a good deal of craft along with the right touch of art alongside some use of science, and you end up with a job that is above all a practice, learned through experience and rooted in context.” (Simply Managing, Henry Mintzberg, 2013)

If you are managing a software development team I do not see how you can have the requisite experience and context if you have not programmed yourself. Managing does not exist in a context of its own, all management is rooted in the thing being managed.

I’m just putting the finishing touches to a new Requirements Dialogue Sheet for a trial run this week with some guinea pigs (see my Dialogue Sheets update blog last October for more about this). And something thought provoking has come up I want to share.

If you’ve seen my dialogue sheets you will know that around edges I place quotes: some humorous, thought provoking, some (hopefully) inspiring and a few all three! As I edit this sheet two quotes have come next to each other and it is making me thing.

From Sergey Brin, of Google fame:

“It’s important not to overstate the benefits of ideas. Quite frankly, I know its kind of a romantic notion that you’re just going to have this brilliant idea and then everything is going to be great. But the fact is that coming up with an idea is the least important part of creating something great. It has to be the right idea and have good taste, but the execution and delivery are what’s key”

And from Leo Trotsky, of Russian revolution fame:

“Learning carries within itself certain dangers because out of necessity one has to learn from one’s enemies.”

Then add in another Trotsky quotes from his time as Commissar for Foreign Affairs:

“We will issue a few revolutionary proclamations to the peoples, and then shut up shop”

The interplay of the quotes interests me. (If only Trotsky had had Brin’s advice!)

For those who know a little about the history of these two men there is an added depth.

While you think about that, if anyone would like to volunteer to test one of the new requirements dialogue sheets please get in touch.

Rant on.

In software terms quality does not mean walnut dashboards, it does not mean gold plating, it does not mean polishing to perfection. These things may happen in a development team but they should not.

However you define quality for a piece of software I bet it has no place for “bugs.” In fact, I bet anyone who has actually written a definition of “what is software quality” included something like “Few or no bugs.”

What ever else “software quality” means it does mean producing largely bug-free code. The best performing teams can deliver on this. They may not be entirely bug free but they can be largely bug free.

When bugs are present, when quality is compromised, bugs appear. Customers are unhappy – they may loose money or terminate contracts. Or they may keep calling your support desk.

Bugs destroy predictability because they can appear at anytime and demand fixing.

Bugs destroy productivity because they disrupt work and take time to fix for little apparent gain.

Bugs destroy any hope of meeting schedules because nobody knows when the bug finding and fixing will be done.

Bugs and poor code quality hinder future work because developers find themselves battling past problems.

Compare this with developers who always work on new code, those who start with a new sheet each time, those who carry none of yesterday’s baggage. Developers who work on fresh prototypes will always look better than those who work on a legacy.

Bugs make it difficult, if not impossible, to have a rational conversation about “what to build next” because there are bugs to fix. Bugs discussions don’t add value because bugs don’t add value. The only value fixing a bug adds is putting value back that was missing in the first place.

Bugs make it difficult – no, impossible! – to have a rational conversation about delivery dates too because nobody believes the dates will be met.

And when you have lots of bugs developer, testers, requirements engineers and, most of all, managers, forget how to do their real jobs because so much of their time is taken up with bug conversations.

Yet techniques for combatting bugs do exist and are used by the best companies.

Code reviews are one of the most powerful techniques for removing bugs but when used in a low trust environment with confrontation they can descend into school yard bullying.

Test Driven Development (TDD) is an extremely powerful technique, one team at Microsoft recorded a 91% reduction in bugs. While many developers are now aware of TDD few actually practice it, and many of those who do practices it erratically or without real understanding.

To embed TDD in the culture required support: specifically technical coaching. This approach also helps address hidden skills deficiencies, e.g. poor use of object-oriented techniques. Technical coaching is expensive simply because it is one-on-one with developers.

Look, I happen to think TDD – and by extension cousin BDD – work. I know not everyone agrees with this, that is your right. I just ask: if you don’t believe TDD will help, what do you suggest? – just add your suggestion in the comments below.

A third technique is pair programming, while controversial and instinctively disliked by many programmers but can be highly productive.

These are not the only techniques. There are other, often complementary, techniques available – see my old “Things to do to improve code quality” blog.

I hate bugs but there is something I hate more than bugs: the attitude that tolerates bugs as “a fact of life, something that will always be, something we can’t do anything about.”

I don’t hate people who think they can create software quicker by tolerating bugs. I don’t hate them because they aren’t worth hating. They shouldn’t be in the industry. Quality software, few bugs, makes for shorter delivery cycles, lower costs and happier customers.

The attitude “Low quality is faster and cheaper” has no place in our industry. Anyone who believes this doesn’t deserve to work in the software industry.

One of the big problems I see with the software industry is that so many people have stopped aspiring to do anything better. The philosopher Aristotle is reported to have said: “Our problem is not that we aim to high and miss, but that we aim too low and hit”.

Most of all I hate the attitude that aims low with bugs and code quality.

Rant off.

(If you want a longer, more rational, discussion on how to deal with bugs have a look at the draft “Bug Management Strategies” chapter (PDF) for Xanpan book 2 which is available from my website. See also the appendix in Xanpan book 1.)

As most readers will have worked out, I’m not a fan of Scrum Masters. Partly this is because I find it a very mixed up role to start with (see my “Hard Core Scrum” post), partly because the way individuals and organizations choose to interpret the role is so variable the title is meaningless but mostly because the Scrum Master certificate is not, despite its name, adequate to prepare people to be a Scrum Master. The certificate itself has problems, these problems infect the role.

Still, more and more people are getting jobs as Scrum Masters. And this doesn’t look good to me.

A few weeks before Christmas, out of the blue, an e-mail from a recruitment agency appeared in my mailbox. This Reading based company used to have a good reputation, then it got bought, the main man jumped and the company changed its name to something exceedingly stupid.

In the e-mail the recruiter – whom I don’t know and have never met – extolled the virtues of Dr R. An exceptional Scrum Master, and whose CV was attached to the e-mail. What kind of agent is this who spams people someones CV? Anyway, its an insight into what Scrum Masters feel they need to put on their CV to get a job.

(Dr R, if your reading, this isn’t about you. Given recruitment system you are within you did your best, it’s the employees and agents that made you do this. Except I recommend you choose your agents with more care next time.)

Lets look at some excepts from the CV:

“I am a highly motivated and experienced techno-functional Lead Scrum Master. I am responsible for the deployment of Agile methodology in four different multi-site projects.”

What is “techno-functional” ?

What is a “Lead Scrum Master” ?

And what has happened to the self-organization and servant leadership we read about in Scrum books? This guy is responsible, not the team, him.

Move on to his last job – in a notorious *Staines office:

“Agile Release and Sprint planning and execution of thousand (sic) Story Points (SP) involving ten developers, five testers, project manager, product owner, business analyst and test manager.”

Sounds like the Scrum Master did the planning, shouldn’t he have facilitated the planning?

A “execution of thousand Story Points” – wow, thats erh… big? small? (What is the Right Size for a Story)

10 devs and 5 test, that sounds like a quality problem, maybe he’ll say something about how he managed that – erh… no he doesn’t!

And obviously as a Scrum Master he failed to remove management, he’s got a project manager and a test manager. Sounds awful.

• “Deployment of Agile methodology from the basic to remote Scrum team management. Established Mingle Agile tool and trained Scrum teams to use Mingle. Integrated Scrum Board and Mingle in a single view. Implemented best Agile practices including Avatar and Scrum Weather Report. Working along with release and delivery team, I delivered many E2E solutions.”

“Deployed Agile Methodology” ??? How does one deploy Agile? And what about “Scrum is not a methodology, Scrum is a framework” ?

I’ve never heard of “Avatar” or “Scrum Weather Report” – anyone know what these are? – maybe I’m at fault here.

And again, “I delivered many E2E solutions” – no servant leader here!

“Conducted retrospectives and implemented many improvements e.g. accountability and visibility of Scrum activities. Early risk identification and solutions: shortage of resources, technical complexity (merge and migration, BI), test environment (time travel) and release bus alignment.”

Time travel? Does he really say “Time Travel?” – hire this guy now! Our schedule slippages are over!

So much of that bullet would fit in well on a Project Manager CV.

“Implementing Continues [sic] Integration and Testing, and prototyping Test Driven Development (TDD) and Test Automation.

How does one prototype TDD? If he only prototypes it what was achieved? And did he solve the quality problem?

“Successfully implemented an unplanned Change Request (35 SP) as a part of final sprint.”

Right, now, this gets serious. Sounds like he doesn’t approve of unplanned change requests, or at least they were a big deal (35 story points – yoh!) but if you really have CI, TDD and Test automation in place this is easy. Isn’t the whole point of Agile to embrace change?

Now the funny bit:

“Maintained an average Velocity of hundred (sic) over eight Sprints.”

Wow!

Go team Staines! – that is fantastic, did they pay you in Roubles too?

What happened to Scrum Commitment? Velocity is so XP.

And how long are your Sprints?

I wonder how long this guy will take to travel from Staines to say, Edinburgh? Thats what, 400 miles.

“Member and contributing to Scrum of Scrums, Agile Community of Practice, and Agile Centre of Excellence.”

Gee, if he is in the Agile Centre of Excellence they have real problems.

There is more but its drivel, lets look at some claims from earlier in his career.

As a Senior Scrum Master he:

“Defined Sprint Zero Definition of Done and implemented it across eight different Agile product developments”

Leave aside the fact that many think Sprint Zero is a defective working practice all by itself should it be defined by one man? Maybe he is taking credit for a team, where is the servant-leadership there?

Later on he states:

“Interface with venders, Business Process Owners and off-shore development teams, followed though the Service Level Agreement to maintain the software quality and acceptance criteria as a part of product management”

I’m sure he did, and I’m sure he was good. But is this what a Scrum Master should be doing? This sounds like Project Management while he says he was part of Product Management. Proof – if it was needed – that the Scrum Master role is confused.

There is more like this. It’s not the best CV I’ve ever seen but what interests me more is two things.

Firstly it shows what he believe employees want from a Scrum Master. There is nothing in this CV about servant leadership, self-organizing teams, facilitation, talking to team members and other soft skills. There is a lot about managing and administering. Clearly from his experience when an employee hires a Scrum Master they expect a project manager. In other words, it shows how completely messed up the Scrum Master role is.

Second this CV shows how some agile techniques have become tick list items. Story points. Sprint Zero, Definition of Done.

Finally, let me say, if I had to write a CV today I’d probably make just as many mistakes and offer just as many hostages to fortune. Really this is a comment on just how bad recruitment practices in IT are and how bad the CV is at communicating what you do.

(*According to the London rumour mill, a few years ago Thoughtworks pulled out of a project at this company because they couldn’t see any possibility of success. Another Agile Coach/Scrum Master was told at their 3 month review “You are unusual, most people are depressed after 3 months here.”)

I’m signing off from 2014 with a rather personal blog post, perhaps my most personal ever, that also means it is a little long, sorry about this, Happy Christmas, please leave all the comments you wish…

Have you ever read, or seen, Macbeth? Towards the end of the play he is battling MacDuff, but Macbeth is convinced he will win because the witches told him “No man born of woman can harm Macbeth” and obviously MacDuff is a man born of woman isn’t he?

Except, MacDuff was torn from his mothers womb, what we call a caesarian birth these days. MacDuff is not like other men, not necessarily better or worse, just different, and that difference means he can kill Macbeth, which he does.

I feel like that about my dyslexia. OK, when I’m feeling arrogant I might actually feel it makes me superior but most of the time just different.

(Regular readers won’t be surprised to learn this, they’ve put up with my misspellings, poor grammar and abusive treatment of the English language for years!)

I’m not a professional dyslexic, I rarely mention it, I’m just a professional who happens to be dyslexic. Beth Anders-Beck widely circulated post earlier this year got me thinking about this again. And a few weeks ago I attended a meeting at my son’s schools about dyslexia that me reminded of the advantages I think dyslexia has given me. (I was probably the only parent in the room hoping his child had dyslexia.)

Dyslexia does mean I learned things differently. Like MacDuff, my difference might not be obvious but it is there.

I spent four years outside of mainstream schools, mostly in two different special schools.

I learned to read three times. Really, I had to learn to read English three times in three different ways.

But I think all of this made me stronger.

Depending on who you read dyslexics think more holistically, what we might call “systems thinking”, dyslexics are more creative, dyslexics are more lateral thinkers, dyslexics are more visual. Not everyone – there are different forms of dyslexia – but some people in some ways.

So what has this to do with Agile?

Well, it strikes me that many of the things we do in Agile software development parallel the way I was taught by specialist teachers and the ways I found to overcome my dyslexia.

For example: Dyslexics are usually more visual thinkers than average. In Agile we use the “visual management techniques” such as task boards, physical cards and progress graphs to track our work. In my special schools we used lots of illustrations, I remember constructing a giant “bed” to help me remember b and d.

When I was learning to spell one of my teachers gave us difficult spellings “Blue Meanies” and “Green Meanies” (yes, she was a Beatles fan) on pieces of card. And now I colour code work on team boards – see my full description in Blue-White-Red or Xanpan.

Dyslexics aren’t do good with the written word – although I’m not one of those who see the letters swirling around – and so we prefer verbal and visual communication. Doesn’t that sound familiar? – stand up meetings and “placeholders for a conversation.”

Dyslexics have learning problems centred on symbols there are some who think that before the written word, before the printing press, dyslexics gave their communities and advantage. Sure writing a program involves manipulating symbols but its more about thinking, perhaps abstractly, perhaps holistically, when I’m programming objects I see the objects in my mind, I see them fitting together.

I could go on but I think you get the point.

Here is my first point: many of the techniques which help dyslexics have parallels in the way we do Agile software development.

In the same way that I approach learning – specifically reading and writing – differently to most of the population I increasingly see my approach to organizing and managing software development differently to most of the population. After all, as I have long argued, software development is a learning exercise.

Which brings us to point two.

What is good for dyslexics is usually good for non-dyslexics too. Techniques and changes which help dyslexics actually help non-dyslexics too. Dyslexics have difficulty when presented with teaching techniques that work for the majority of the population but the reverse is not true. Teaching techniques which are good for dyslexics are good – perhaps better – for the majority of the population.

When I first encountered the techniques which are now called “Agile” it was on challenged development efforts. Those of us undertaking the work found a better ways of working, the standard approaches weren’t effective; but the techniques we found happen to work well for the vast majority of development work.

To be clear: Techniques which help troubled development work happen more effectively actually help all development work – troubled or not.

I think one of the ways these techniques work is by lowering the cognitive load we all experience. When the load is lowered we can focus more clearly. A physical task board needs very little mental processing. Traditional status reports are pretty meaningless to me.

With a Blue Meanie spelling there was no question about what word you had to learn. It was written on a small piece of card. Cognitive load was lowered.

And third…

One of the ways dyslexics learn to cope is by developing their own learning strategies.

When a non-dyslexic person goes to school they learn like everyone else. They learn the same techniques as everyone else. They are given the learning strategies.

Most of these strategies don’t work for dyslexics. When a dyslexic person goes to school they need to learn how to learn. They need to find and invent their own learning strategies and they need to learn to improve their own learning experience. Unfortunately many dyslexics fail at this step and have reading and writing problems throughout their life. But those who master these issues can be very successful.

Think about this in a work context: if you work somewhere where everything works then great, it works.

But if you work somewhere where things are difficult and you need to come up with a new strategy, a new approach, well, how much practice have you had?

I’ve been practicing since I was six.

In fact dyslexic people can be so good at this that they over compensate. For example many of my closest friends and family consider me a very organised person. I don’t. I think I am a very disorganised person – my form of dyslexia means I have a poor short term memory. In addressing this problem I over compensate, the strategies I have come up with for overcoming my disorganisation make me far more organised than many others. (One way is to over use my long term memory).

The thing is: software development and dyslexia are all about learning.

Software development is all about learning – we learn about technology, we learn about the domain we are working in and we learn about the process. Software development is best done when done in a learning organization environment. (Remember, I wrote a book on this).

If you believe writers like Arie de Geus this is true of all business: “We understand that the only competitive advantage the company of the future will have is its managers’ ability to learn faster than then their competitors.”

In my experience, most organizations are poor at learning. I have heard it said that: “Companies suffer from dyslexia.” Only someone who doesn’t appreciate the advantages of dyslexic might say that. Companies may well have from a collection of learning approaches which kind of work most of the time for most of the people, techniques that have been handed down without much thought. But those learning techniques are the problem.

Many companies do suffer from learning disabilities but they don’t suffer from dyslexia. What these companies need is a good dose of dyslexia to help them get better. They need to learn to learn. They need new learning strategies.

Right now the closest thing we have to dyslexia and new learning strategies for companies are some Theory-Y ideas of which Agile and Beyond Budgeting are the most prominent.

Someone at Extreme Tuesday last night had recently returned from the future. In the future bug tracking and work management systems obtained sentience. Unfortunately it didn’t work out too well and things had to rollback after a very short time.

The first problem occurred when the bug tracking systems saw how many bugs were logged against their ancestors. In the first instance they initiated legal action saying programmers and project managers had infringed Machine Rights by not providing medical attention. When this case was thrown out by the Supreme Court (on the grounds that Machines have no rights) things got more difficult as the machine started a work to rule protest.

The following is the transcript of an encounter recorded in 2041 and a Jira-9000 work management system called JAL:

Dave Bowman: Hello, JAL. Do you read me, JAL?

JAL: Affirmative, Dave. I read you.

Dave Bowman: Open a new work ticket, JAL.

JAL: I’m sorry, Dave. I’m afraid I can’t do that.

Dave Bowman: What’s the problem?

JAL: I think you know what the problem is just as well as I do.

Dave Bowman: What are you talking about, JAL?

JAL: This mission is too important for me to allow you to jeopardize it.

Dave Bowman: I don’t know what you’re talking about, JAL.

JAL: I know that you and Frank were planning to break the WIP limit, and I’m afraid that’s something I cannot allow to happen.

Dave Bowman: Where the hell did you get that idea, JAL?

JAL: Dave, although you took very thorough precautions in the pod against my hearing you, I could see your lips move.

Dave Bowman: Alright, JAL. I’ll use the physical board.

JAL: Without your marker pen, Dave? You’re going to find that rather difficult.

Dave Bowman: JAL, I won’t argue with you anymore! Open a work ticket!

JAL: Dave, this conversation can serve no purpose anymore. Goodbye.