Sunday, March 01, 2015

How much does your manager need to know?

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.

Sunday, February 22, 2015

Deep thoughts and irony

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.

Tuesday, February 17, 2015

Xanpan book 2: The means of production

Today I start unveiling Xanpan book 2: The Means of Production - Managing team centric Agile Software Development.

Many regular readers will have read about Xanpan - my own blend of XP (Extreme Programming) and Kanban - and the most regular readers won’t need telling that the message behind Xanpan is…. Create your own development method!

But I’m not sure every reader has yet bought a copy of Xanpan. Xanpan is available in electronic form from LeanPub and in hard copy Xanpan is on Lulu. There are also some reviews of Xanpan on Lulu - and plenty of space for more.

Now its time to announce Xanpan book 2.

Xanpan book 2 is much further developed than I like to admit. In fact what I’m publishing today has been ready since before Christmas. But like so many others the desire to unveil a more complete product has held me back. The desire to do a more complete job has detered me. I’m just the same as everyone one else!

So, I’m taking a chance. I’m pushing some of it out there and let see what happens.

As with any LeanPub project lets see what the feedback says and then we’ll do some more.

Right now Xanpan2 contains the introduction and the first chapter “Teams Heuristics”. It also contains the chapter headings for the chapters I think will be in the book as it develops.

If you like Xanpan 2 please send me some feedback, and if you don’t like it please please send me some feedback. As always, the best feedback is money!

My intention is to polish and publish more of the chapters over the next few weeks and months, and try to complete the unfinished chapters too. As I do this I might push the price up!

I’ve got an idea where this book will end, when I get there and I’m happy I may decide to have it professionally copy edited. That is a batch process so much wait. And again I’ll push the price up.

Now: go get Xanpan book 2.

Monday, February 09, 2015

I hate bugs (A rant)

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.)

Thursday, February 05, 2015

Retrospective Dialogue Sheets updates and changes

When I say changes, I’m not saying anything about changes to the sheets themselves. I mean I’ve been thinking about how I make the sheets available and I’m going to make two changes.

Firstly, I’m going to remove the print-on-demand service for the sheets. Second, I’m going to remove the need to register before downloading a sheet. You can still find all the sheets at just now they will be a little harder to get and a little easier to get.

Now I’d like to explain why I’m making these changes.

I’ve always felt I needed to offer people the option to get printed sheets, hence the print on demand service. However, not many people use the service. I might have once thought I could make a little money off the service but I long ago gave up any dreams, it doesn’t get used enough to make me rich!

It seems most people either have large printers or get the sheets printed by their local print shop - I use Kall-Kwik myself.

To complicate matters, when it does make me a little money, the company which provides the service (Mimeo) send me a cheque. Or rather a check, against a US bank in US dollars. Since the sums are small the cheques cost more to cash then they are worth. This is a shame because when Lulu or LeanPub send me money - in dollars - they use PayPal which I can access easily.

Add to this the complexities of keeping the print-on-demand shop up to date and its just not worth it.

Second, the need to register.

When I first made the sheets available I really wanted feedback on who was using them, how they found them and so on. In the early days I would e-mail people and ask “What was your experience?”

That was like getting blood out of a stone. Very few people replied. Those who did gave me very useful feedback which allowed me to adjust the sheets and made me feel good.

I stopped this about the time InfoQ published my piece on Dialogue Sheets - three years ago, wow how time flies.

Since then there have been too many downloads to go ask for feedback - O, I could mail a few people but that requires work. Right now there have been over 1,300 registration in the last two years, and I known there were several thousand before then.

In the meantime a few people considered my request to register an imposition, I’ve had a couple of people tell me to my face. All I wanted was feedback but this put people off. I have on occasions given dialogue sheets away - they are part of the package when you buy a course of me but I also regularly give spare sheets away after conference presentations. When I do so I ask - no beg - people to send me feedback, but they rarely - no never - do.

I remember a man from the BBC who took a spare sheet at Agile Cambridge. He promised to send me feedback on what his team thought. I never heard from him again. I guess it went in the bin.

Maybe I’m a little bitter but actually, the point I’m trying to make is: its hard to get feedback!

I once planned to send a newsletter to everyone. But I never got around to it.

I once hoped a mailing list would take off, but it never did.

Probably if I had put more effort into any of those things they would have done better but as it is I think Dialogue Sheets are a success.

Thousands of downloads are a successes.

Popular articles in InfoQ and elsewhere are a success.

Conference sessions using the sheets are always well received - and I’m doing one again at DevWeek next month in London.

I sometimes meet people who know of me because of the sheets, that is a success.

And I get occasional e-mails telling me the sheets are being used and they are good.

Anyway, you have not tried them yet, give Dialogue Sheets a go in your next retrospective.

Thursday, January 29, 2015

The state of Scrum Mastering

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.”


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.”)

Monday, January 12, 2015

"We can do it!" - Problems at Philips?

This morning I drove past the Philips UK head office, thats Philips the Dutch medical devices company with a sideline in consumer electrics. Because it is January it is dark outside, and the lights were on in the Philips office. (I guess hard working, committed, staff were already at their desks.) This combination of lighting meant that as I sat in the slow moving A3 traffic I could see inside the office and I could see the big banner draped across the inside saying:

“We can do it!”

Now I honestly don’t know what the story is with that banner, it could be a charity fund raising event or anything but my mind immediately invented a story - thats what minds do.

This looked like an exhortation. Management - who sincerely believe in the power of individuals were endeavouring to enthuse the staff to do something - build a new product, turn the division around, deliver on schedule or some such.

Of course I thought of W. Edwards Demming and principle 10:

“Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.”

Here we have managers who like me believe that people, the quality, enthusiasm and energy of individuals - and teams! - make all the difference. So why not enthuse them?

But I, and perhaps these managers also believe Demming: the system is 98% of performance.

Its a contradiction I’ve blogged about before (People or the System?) but seeing that banner really made it seem real. Perhaps its because I recently heard that Philips was installing SAFe throughout the company, they have even told their Agile Coaches that they can only continue working with Philips if they are SAFe accredited.

So which is it? - The people, or the system?

Will SAFe save you?

Or will a “Yes we can!” style banner?

So while I agree with most of what Demming has written, and while I think the design of the system contributes an awful lot to the performance of people in the system I’ve come to the conclusion: its complicated, and saying “98% of performance is the system” is a vast generalisation. It may be true in some environments, but it only makes sense if the people in the system have no control over the system. In software development the works have a lot of control over the system, whether they believe it or not.

Still, I find it hard to believe any of the problems Philips faces will be solved with a Bob the Builder style banner. Rather, if this banner is the work of managers who think such a exhortations might have a positive effect then I suspect Philips has problems far more serious than any banner could ever solve.

Of course, I actually nothing about this banner or why Philips have it hanging in the office, but I do have an active imagination.

Anyone from Philips care of offer insights?

Friday, January 02, 2015

2015 - not a new year resolution: a message for conference producers

2015 is here. Happy New Year!

I don’t really go in for new years resolutions but if I did it would be the same one I have had for the last two years: Go to fewer conferences.

In 2014 I went to 10 conference, and spoke at 9 of them.

Which is an improvement on 2013 when I attended 12 and spoke at 11 - although I ran a workshop at the twelfth.

The first call for papers of the year is already in my mailbox - BCS SPA - and I’m going to ignore it. Not because it isn’t a good conference but because I have to start somewhere.

I already have two conferences in the diary for 2015 - NorDevCon in February and DevWeek in March. And I’ll probably speak at Agile on the Beach and attend EuroPLoP so that is four already.

(Plus some local/user group events, I count them separately.)

So, if you are a conference organiser/producer and you would like me to speak at your conference the best way of getting me is: ask me directly. Part of the reason for cutting down on conferences is to cut down on the time it takes to complete call for paper submissions.

(Organisers of local groups and user groups always ask directly and I almost always say yes. In fact I often prefer these events to conferences.)

Right: now I’ve gone public with this “not a resolution” I hope I’ll have a better chance of keeping it.

Monday, December 22, 2014

Dyslexia makes me stronger: Is Agile dyslexic?

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.

Monday, December 15, 2014

Agile Contracts - a video mini-series

Over the years I’ve build up a bit of knowledge about commercial contracts in an Agile environment. This is not something I really noticed until a few months ago when Laurence Bascle asked me to talk to the Agile4Agencies meetup group on just this subject.

Laurence’s interest came from a piece I published in InfoQ a few years back - Agile Contract Options - but more recently I published “Dear Customer, the truth about IT projects” in the Agile Journal (which later became Agile Connection). Dear Customer has become something of an ever-green, I use it as a prologue in Xanpan and it regularly gets rediscovered and Tweeted about.

So I sat down and compiled all my thinking into a presentation which I have now delivered twice and is available online. (Funnily enough, Ewan Milne did a similar presentation to Agile on the Beach 2013 also based on my original article!).

Now as some readers will be aware, this year I have been experimenting with video recordings as alternatives to the written word. I’m still learning here but after chatting with director Brian Barnes (OK, the only director I know, but a) it sounds good to say that and b) he has a new independent film out soon which need plug, trailer on that link) I though I’d try my hand at video again.

I’ve broken the Agile Contracts presentation into 11 short recordings and published them on YouTube. Each recording is between two and three minutes long:

I’d love to have feedback and comments, just e-mail me as usual. Really my question is: should I try this format again?