The Product Owner Delta

ValueAddPO-2019-07-1-08-19.jpg

As regular readers might know I’m working on a book called The Art of Product Ownership to be published by Apress later this year. One of the chapters is entitled “Why have a Product Owner” and a few days ago a bunch of ideas crystallised into this…

The aim of the Product Owner is to increase, even maximise, the business value delivered by the team as a whole. The Product Owner does not so much create value themselves as increase the value created by others.

Think of it like this: if the team randomly selected work to do and delivered it to customers then some value would be created. (For the moment I’ll ignore the scenario where that work detracts from the existing value.) The aim of the PO is to ensure the work done creates more value than a simple random selection. The greater the difference, or delta to use a mathematical term, between random selection and an informed selection the better.

The general hypothesis is that intelligent selection of work by a skilled Product Owner will result in both more value being delivered and an increasing delta between intelligent PO selected work and randomly selected work.

This difference the value added by a Product Owner. I like to call this difference the Product Owner Delta.

Now in real life work is seldom randomly so Product Owners are not competing against random selection. In some cases the alternative to a designated Product Owners is someone else: a senior developer, an architect, a manager or someone else. In such cases this person is taking on the Product Owner role. They may not have the title, the aptitude, the skills or official position but when work is selected by one person they are de facto the Product Owner.

In other cases the alternative to the PO might be selection by consensus on the team, or a sub-set of the team. Now it is entirely possible that such a group could outperform a single Product Owner in selecting work – especially is they have market and customer knowledge, some analysis skills, time to do the background research and so on. In some cases this works, for example think of a small start-up staffed by software developers creating software development tools.

However, in some cases selection by committee might be inferior to a random selection. Imagine a team which has never met a customer, argue about what to do, duck key decisions and never say No to any request. Its easy to image a dysfunctional selection committee.

There is more to increasing the Product Owner Delta than simply selecting the highest value items. Timely selection can help too. If decisions are not being made, or committees are spending a long time making decisions then having one person simply make those decisions in an efficient, timely, manner can increase the delta.

Time has another role. Because of cost-of-delay simply selecting the highest value items at any one point in time does not maximise the value delivered. Time Value Profiles (see Little Book of User Stories or my presentations on value “How much? When?”) expose this and need to be another tool in the Product Owners repertoire.

And of course, the Product Owner Delta is not the only reason to have a Product Owner in the team, but it is probably the main reason.


Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The Agile virus

iStock-952804252s-2019-06-6-15-18.jpg

The thing we call Agile is a virus. It gets into organizations and disrupts the normal course of business. In the early days, say before 2010, the corporate anti-bodies could be counted on to root out and destroy the virus before too much damage was done.

But sometimes the anti-bodies didn’t work. As the old maxim says “that which doesn’t kill me makes me stronger.” Sometimes agile made the organization stronger. Software development teams produced more stuff, they delivered on schedule, employees were happier, they had fewer bugs. In smaller, less established companies, the virus infected the company central nervous system, the operating system, and subverted it. Agile became natural.

Perhaps thats not so odd after all. Fighting infection is one of the ways bodies grow stronger. And some virus have positive effects – Friendly Viruses Protect Us Against Bacteria (Science Magazine),
‘Good viruses’ defend gut when bacteria are wiped out (New Scientist), 10 Viruses That Actually Help Humankind (ListVerse), and virus play a roll in evolution by removing the weaker of the species.

The problem is, once the virus is inside the organization/organism it wants to grow and expand. It you don’t kill it then it will infect more and more of the body. Hence, software teams that contracted the agile virus and found it beneficial were allowed to survive but at the same time the virus spread downstream to the requirements process. Business Analysts and Product Managers had to become agile too.

Once you are infected you start to see the world through infected eyes. Over time the project model looked increasingly counter productive. Growth of the agile virus lead to the #NoProjects movement as the virus started to change management models.

Similar things are happening in the accounting and budgeting field. As the agile virus takes hold, and especially once the #NoProjects mutation kicks in, the annual budget process looks crazy. Agile creates a force for more change, agile demands Beyond Budgetting. Sure you can do agile in a traditional budget environment but the more you do the more contradictions you see and the more problems you encounter.

Then there is “human resources” – or to give it a more humane name personnel. Traditional staff recruitment, line management, individual bonuses and retention polices start to look wrong when you are infected by agile. Forces grow to change things, the more the organization resists the virus the more those infected by the virus grow discontent and the more unbalanced things become.

It carries on. The more successful agile is the greater the forces pressing for more change.

While companies don’t recognise these forces they grow. Hierarchical organizations and cultures (like banks) have this really bad. At the highest level they have come to recognise the advantages of the agile virus but to embrace it entirely is to destroy the essence of the organization.

Countless companies try to contain the agile virus but to do so they need to exert more and more energy. Really they need to kill it or embrace it and accept the mutation that is the virus.

Ultimately it all comes down to forces. The forces of status quo and traditional working (Theory X) on one side against the forces of twenty-first century digital enabled millennial workforce (Theory Y) on the other. Victory for the virus is inevitable but that does not mean every organization will be victorious or even survive. Those who can harness the virus fastest stand to gain the most.

The virus has been released, putting the genie back in the bottle is going to be hard – although the paradox of digital technology is that while the digital elite stand to gain the digital underclass (think Amazon warehouse workers) stand to lose.

All companies need to try to embrace the virus, to not do so would be to condemn oneself. But not all will succeed, in fact most will fail trying. Their failures will allow space for new comers to succeed, that is the beauty of capitalism. Unfortunately that space might be also be grabbed by the winners, the companies that have let the virus take over the organization.


Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

Agile is a Crunchy Nut Frog (and some dirty secrets)

800px-Argentine_Horned_Frog_Ceratophrys_ornata1-2019-06-6-15-26.jpg

Remember the Monty Python Crunchy Nut Frog sketch? – especially the final section..

Officer: Well why don’t you move into more conventional areas of confectionery, … I mean look at this one, ‘cockroach cluster’, ‘anthrax ripple’. What’s this one, ‘spring surprise’?

Shop keeper: Ah – now, that’s our speciality – covered with darkest creamy chocolate. When you pop it in your mouth steel bolts spring out and plunge straight through-both cheeks.

That like Agile to me. In AgileLand everything is sweetness and light. Agile has all the answers. Everything works. Agile is utopia.

I’ve taught enough Agile Introduction courses to know this is so – and pushed ti too. There is no scenario I can’t fix in the classroom with the application of the right Agile principles, tool or mindset. And if I can’t… well in that case, Agile is helping you see the problem more clearly and you have to find your own solution.

Honestly, part of the appeal of Agile is that: Agile is a damn good story. Agile paints the picture of a better world, and so it should. Particularly when delivering an Agile training course I see my role as two fold:

  1. In-part enough information so that teams can actually try Agile
  2. Energise people to want to try it this way

Except, there are some dirty little secrets in the Agile world which do’t fit with this picture.

First up is Micromanagement (#1).

As I said in Devs Hate Agile, the Agile toolkit can be used for good or evil. If someone wants to be a micro-manager par-excellence then Agile – and particularly Scrum – make a great toolkit for micro-management too.

The intention behind the Agile/Scrum approach is to give those who do the work the tools and approaches to take control of their own work. When they do so then great things happen – the workers control the means of production! However those same tools can be used by very effectively by those who would control the workers.

What micromanager would not want every team member standing up to justify themselves at 9am each morning?
Surely a micromanager would want working software at every opportunity? – and if you fail to deliver working software then…

In part this is because Agile is a great tool for apportioning blame (#2). When builds fail you know who did the last check-in. when tests fail you know who broke it, when cards don’t move on a board, sorry I mean Jira, then the powerful can hone in on those not pulling their weight.

Kanban is even better than Scrum here. I remember one Project Manager who used the Kanban board (26 columns!) we constructed to demonstrate why everybody apart from him was slowing work down. Try as I might I couldn’t get him to see each of problem to be worked on. To be fair to him, he was the product of a system where almost every step was undertaken by a sub-contractor, he had no power to change or reward sub-contractors, only to whip them.

Both these points illustrate the second dirty little secret: you don’t need to do everything (#3).

Simply holding stand-up meetings and end-of-iteration activities is a massive improvement for some teams.

Developers who adopt Test Driven Development will produce fewer bugs, waste less time in the debugger, and the testers who come after them will spend less time reporting bugs. Thus fewer bugs will need fixing and schedules will improve.

A Kanban board with WIP limits will improve workflow even if you do nothing else.

Yes, if you do every part of Scrum things will get a lot better.

And if you do every part of XP the total benefit will be better than the sum of the parts.

Part of the genius of Agile is that it can be implemented piecemeal. But that also means organizations and teams can stop. I’ve seen this a number of time: I introduce a bit of Agile, the immediate pain is relieved and the company looses the will to go further and improve more.

After all, who am I but an external consultant to tell them they could do better?

Once the pain if gone then the need to change goes too.

Now some dirty little secrets are being exposed. Most readers will know I have been active in exposing the dirty secret of Agile Project Management: the idea that Agile and the project model (aka project management) can work together.

Sure they can work together but… why? what is the point? Why go to the trouble of integrating Agile and Project Management?

Once you start working Agile the project model looks absurd. Hence #NoProjects – and why so many people have arrived at the same conclusion about projects independently.

In fact, it goes further than that. Companies that introduce full blown Scrum – including self-organizing teams – risk destroying themselves. In traditional, top-down, hierarchical companies Agile and self-organizing teams must be contained otherwise it will destroy the whole hierarchy. That is why banks struggle with Agile, the chocolate on the outside is really nice but sooner or later what they are eating runs up against what they are.

Finally, you might notice that in this post – and indeed in many of my other post – I don’t agree with other Agile advocates. Go and read Jeff Sutherland (I don’t agree over self-organization), Mike Cohn (I don’t agree over stories and points), Keith Richards (not the rolling stone, the APM man, I don’t agree over projects), Jim Coplien (he doesn’t agree over TDD), Joanna Rothman (we don’t agree on stories), Dan North (we don’t agree on teams) and just about anyone else and you’ll find I don’t agree 100% with anyone.

True, I make a point of being a contrarian – go read my old Heresy: My warped, crazy, wrong version of Agile.

But the thing is: none of these people agree with each other.

Everyone in the Agile communities interprets it slightly differently.

The final dirty secret of Agile is: the experts don’t agree – there is no one true way (#5).

I feel sorry for new comers to Agile who expect to read the one-true-way but I’m also sure none of us “gurus” would want to any other way because we want variety and experimentation. And perhaps that is why one-size-fits all Agile scaling is always doomed.

Frog image credit: Argentine Horned Frog by Grosscha on WikiMediaCommons under CCL ASA 4.0 license


Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

 Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

Identity over roles and responsibilities

iStock-899732676-2019-05-23-15-36.jpg

When was the last time you read your “roles and responsibilities” description?

My guess is, it was about the time you applied for your current position. Of course, if your HR department, or agile coaches, have decided to change your description you might have read the new document but even then, did you?

My guess is most people remember little more then the job title.

Like so many documents, it goes in one eye and out the other. And the longer it is, the more detail the less you are likely to remember.

So it won’t surprise you when I say: I don’t think roles and responsibilities documents have much use.

And it might not surprise you when I say roles are pretty pointless too.

To my mind your personal sense of identity, your own idea of who you are and what you do, plays a much bigger role in the actions you take in work and the responsibilities you accept – and those you ignore.

If, for example, your business card says “Business Analyst” it is not because someone defines your work as a “Business Analyst” it is because you see yourself as a business analysts and your sought out a business analyst role. You are a business analyst because you see yourself as a business analyst. You are not a programmer because you didn’t apply for a programmers job because you are not a programmer.

Let me suggest that what you actually do has little to do with what it says in some document, rather what you do is determined by your sense of identity, your identity may well be entwined with a job title. Identity is a powerful motivator.

If you consider yourself to be a programmer, a software engineer, software developer or whatever, then you probably shun business cards altogether but the same idea applies: you are a programmer not because you read a job description and say “I like the sound of that”. You are a programmer because you like doing the things you think a programmer does.

Of course this can cause problems because different people see things differently. Things fall between the gaps – your manager expects you to update the user manual and you see that as someone else job. Or things get difficult because two people try to do the same thing: the programmers try to design the software and so too do the architects.

Things get more complicated when people – us consultants! – start trying to change things. Maybe we say “programmers should test the code they write” but programmers say “testing is a Testers job.” Its even more difficult when you try and remove responsibility for someone: “programmers are no longer responsible for updating the system documentation.”

This is why I despair when people tell me problems can be fixed by updating the “RACI matrix” – don’t ask me what R A C I stands for, it seems to be a tool where responsibilities are listed against roles. RACI doesn’t change identity.

But you know what? – I like the way the world is. I do not want a world were people do what is on their job description and don’t do what is not.

People who are doing what they think needs doing, and who are doing it with the aim of producing a better outcome are motivated.

People who are doing something because it is in a job description, or because they’ve been told it is now their responsibility are not so motivated. Job description documents are pretty useless.

Whether you agree with me or think that people “should” do what is in some document: simply stop expecting them to do what it says. Instead look at what they do.

Go further, if something is missing ask “Who would like to do this?”. Work with people who are motivated by asking them what they want to do.

Few, very few, people are truly disruptive and working against you – unless of course your final outcome is something evil. Work with them.

Delete the roles and responsibilities documents.


Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and now Project Myopia audio edition

Building software is not like building houses (thankfully)

DSC00248Light-2019-04-26-13-45.jpg

I hate the “building software is like building buildings” metaphor. For a start most software people know so little about physical building that they are comparing the messy world of software construction with a idealised image of what they think happens in construction.

The above is a picture from my back garden last week. Only a couple of weeks ago the back of this house looked much like the back of my house, except it had an small, ugly, 2m x 1m kitchen extension on it. And it had an over grown garden, a third of which houses this big extension while the rest of it is full of building debris.

The builders moved into this house less than six week ago. During that time they have: cleared the garden, cleared the house of remaining furniture, dug foundations, concreted foundations, built a two story side and back extension, ripped the roof off both this house and the ajoining house and replaced the roof while also constructing loft conversions on both houses. The roof came off on Monday and the new one was done by Saturday.

Builders – roofers and brick layers – go fast. Three years ago I had some work done on my house. I was well impressed with the speed the builders ripped the back rooms apart, tore down a wall, bricked up a door, and built a new wall.

Then it goes slow.

Once the actual “building” is done the wiring, plumbing, plastering, decorating and other fitting-out starts and o my, it goes so slow. Hold ups are regular as parts and people are not available when needed. There is a constantly changing cast of workers as specialists appear for a few days and then disappear.

I expect it will be four or five months before anyone is living in my neighbours house again.

During that time it goes slow, work people come in but it is hard to see progress. And the progress is far less clear than when a wall disappears, or a new wall comes into being overnight.

And so it is in software… usually.

The thing about construction – both physical and software – is that so often the most visible bits are actually among the most quickest and straight forward. These are the bits where not only can progress be made rapidly but visibly too.

But lots of time is spent on less visible bits – the tricky bits. The Devil is in the Detail as the saying goes.

When people say “How can is possibly take so long?” they are speaking from the experience of seeing the visible bits happen fast. The less visible bits, where the time is consumed, they don’t know what is happening during the less visible bits and have few memories to guide them – but they did remember it went fast last month!

When my house was being worked on I often felt like saying “why isn’t it done yet?”. The big changes, the heavy lifting, was done. How could all this other stuff? – the minor bits, the bits which didn’t require actual building – take so long?

Fortunately, software doesn’t need to be like this. There are alternatives. But working such ways means slowing down the early stages to deal with the detail as you go. Overall you get a more consistent (and sustainable) pace, and may well finish sooner but you loose the quick start that impresses people. Almost from day-1 they start complaining about the lack of progress.

Not being a builder I don’t know, but I do know I hired experts and I have to trust them. And I never tried to say to them “If this was software you would be done by now.”

(Now I’ve written this blog I remember, I’ve said something two years ago… Heavy Lifting is the Easy Bit. Worth saying again I think.)

Story Generators

iStock-913773630small-2019-03-22-17-35.jpg

Recently I’ve been looking again at Jobs to be Done and OKRs (Objectives and Key Results). I increasingly see them as story generators and a potential solution to the tyranny of the backlog I described last time.

When I first looked at Jobs to be Done (and OKRs actually) I wondered if they constituted a fourth, top, level on top of Epics, Stories and Tasks. I’ve long argued against having more than three levels of things to do (or requirements as we used to call them.) There are big meaningful things to do (stories), really big things which we don’t as yet understand but look really valuable (epics) and the immediate small things to do right now (tasks).

Actually, I’d rather think most things can be dealt with by two levels and one level is the even better. So adding a fourth “even bigger” thing on top of Epics just felt wrong. Technologists (like myself) have a tendency to map everything into hierarchies; inverted trees with fractal like branches. But not everything is, or should be, a hierarchy, mapping the world into a tree like structure can add complications.

Unlike stories (and epics and tasks) Jobs to be Done don’t really lend themselves to the transactional “Done”. While you could put a Job all the way to Done on your Kanban board and track it from “To do” to “Done” in reality the customer job still exists. Sure you’ve improved it but you can improve it again – another example of Stable Intermediate Forms. This seems to be the great potential of Jobs to be Done, they keep on giving: as much as you improve your product to help with the job you can still improve it some more.

So each time you analyse the Job to be Done you should be able to find more stories to deliver to improve it. Hence the Job to be Done is not a “story” to do, it is a Story Generator. Every time you look at the job to be done you find more stories, every time you examine the result of the latest improvement you find more stories. The job will never be done. Some might see that as a bad thing but that also means the job presents a stable focus for ongoing work.

The same might be true of OKRs but in a slightly different way. Because the objective is reviewed periodically – every quarter or so – it lacks the continuity of Jobs to be Done but perhaps allows the team to switch targets, maybe it is stable enough.

The key results may well be stories in their own right, or they may be things which lead to stories. Either way one can expect some key results to be achieved and marked as done regularly. As they fall they are either replaced by new key results building towards the objective (which themselves lead to stories) or new key results are added for new objectives.

I’m sure there are other story generators out there but the key thing for me is not the mechanism but the existence of the generator. Once you have a story generator you do not need a big backlog of things to do. The generator will replenish the backlog whenever you need more stories – either because you have done them or the value has fallen.

Using a generator removes the need to have a big backlog which removes the tyranny of the backlog. The team are now free(r) to concentrate on delivering value towards their objective.

Finally, I wonder if anyone has used both OKRs and Jobs to be Done together? Right now they feel like alternative generators to me, having both seems like a bit like overkill. Although I accept that maybe OKRs are more corporate and Jobs to be Done are more product focused. Anyone got any experience using them together?


Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and now Project Myopia audio edition

Tyranny of the backlog

BurningDownTheBacklog-2019-03-14-16-19.jpg

The backlog is a great idea: all the things we think the team will build, or perhaps: things they might build, and it might contain other work, like evaluation or reviews. Yes, the backlog is a great idea, all the stuff the team might do, well perhaps not all, it is seldom complete, after all, as they say “stuff happens”.

The truth is: backlogs have a tendency to grow. All too often I find teams who are struggling under the weight of their backlog. They can’t spare time to do experiments or learn something because there is stuff to do. The backlog becomes a tyrannical ruler and all of it MUST BE DONE.

Look at that hypothetical burn-down chart above. By sprint 15 the team is well on its way to completing all the original work. But the amount of work they need to do is higher than when they started. It is not as if the team have been doing nothing. Look at the next chart, it shows how, most weeks, more work is added than is done.

DoneVAdded-2019-03-14-16-19.jpg

To my mind finding more work isn’t a problem, indeed teams should be finding more work. Problems stem from the fact that backlogs – and tracking mechanisms like burn-down charts – try to full-fill competing needs.

  1. The backlog is used as a store of ideas for work to do. This makes sense, you can’t do everything today so postpone some to the future. A backlog allows you t move some things from peak time to off-peak, although software development teams rarely seem to see off-peak time.

Plus, having a backlog makes it easier to say:

“Thanks for your suggestion Fred, I’ve added it to the backlog, I’ll let you know when we get to it.”

Rather than:

“Thanks for your e-mail Fred, we deleted it once we stopped laughing.”

It makes sense to give a new idea a quick once-over. But doing a proper analysis is time consuming:Discussing what is being asked for takes time, as does setting acceptance criteria are. And then there is business value to assess and other work priorities to consider. Therefore, put it in the backlog and do all that later (if it ever gets scheduled.)

Without a backlog we would be forced to make a binary decision: do it and do it now or reject it.

In fact the backlog can become a natural filter: as stories age in the backlog some items will jexpire. Unfortunately many Product Owners don’t feel they have the authority to delete old requests so the backlog grows and grows.

I call such a “constipated backlog”: work goes in but very little comes out. When the only way for items to leave the backlog is by doing them the rate of return falls.

  1. The backlog fills another role because so many teams are still expected to meet project success criteria which ask for “everything to be done.” The backlog becomes a tyrant when people believe that one day it will all be done. Worse still, some people plan using this assumption.

People want to know when “it” will be done, how long it will take and how much it will cost. It takes time to answer those questions and if the backlog is growing any answer is going to be wrong.

In fact, it is probably wrong to think everything will ever be done. Unless one freezes the backlog and refuses to add new work then it is likely that low value items will be postponed while new, more valuable items, will take priority.

As an industry we need to drop the idea that a backlog will ever be done: the backlog as repository of ideas is at odds with the backlog as a measure of completeness.

Think about it this way: some of the items in the backlog are very valuable. Some items are worth very little. Some will cost more effort than the benefit they bring. If we do everything then the low value and the high value will all get done. Conversely, if we encourage new ideas and weed-out as many low value items as possible our rate of return will be higher.

But very few teams follow this model. Many more teams are slaves to the backlog, and their quest for an empty backlog is doomed.


Like this post?

Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Audio & free eBook of Project Myopia

A little bit of time sensitive news, albeit at the risk of overwhelming my regular readers – especially those who take this blog on the mailing list. Sorry.

The #NoProjects book, Project Myopia is available as a free ebook from Amazon (Amazon USA) for two days, Tuesday 26 February and Wednesday 27 – well, strictly speaking midnight Monday/Tuesday till midnight Wednesday/Thursday Pacific time, so 8am Tuesday to 8am Thursday GMT.

This is to celebrate the release of the audio version of Project Myopia which is now available on Audible and Amazon (where the free ebook is too), and possibly some other places where Audible has distributed it.

Unfortunately, Project Myopia will not be free in every Amazon. My full apologies, I think it is going to be free for UK and US Amazon customers, and probably Germany customer too. Elsewhere I’m not sure, Amazon don’t make it easy to find out.

I know I have readers elsewhere so I’m really sorry about this. At some time I’ll see what I can do about this restriction.

An (agile) coach’s dilemma

iStock-521796758s-2019-02-13-14-54.jpg

I’d never met the team before. It was a small company in Cornwall and the big boss man was away on holiday that week. They took me upstairs to the meeting room. We talked for about an hour and I could tell there was something on their mind.

Eventually one of them asked:

“we have this question we’ve been talking about for ages we’d like you to help with.”

This was it, the $64,000 question.

“Ask” I said.

“Well… should we be using source code control?”

To some of you this might sound funny, to others shocking, but believe me, on average I meet one team a year who don’t use source code control. On this day I had two voices, one in each ear.

The voice in my left ear said:

“You are only a coach, you are here to help them make their own decisions. Talk about their goals, what they want to achieve, find out if they think source code control could help them. Let them explore why it might be the wrong choice.”

The voice in my other ear said:

“Jesus Christ…”

On the one hand the (agile) coach is there to help the team reach their best. The coach isn’t there to tell them what to do, the people – the team – are the experts in what they do, and they are self-organising. The coach is there to help them unlock their superhero powers.

On the other hand: the coach has done this before. If they are any good they have not only worked with many teams before and read many reports in books and blogs but they wrote the reports, their teams are in the case studies. The team may well be experts in Java, JavaScript, inertial navigation, limb-replacements or whatever but the coach is the expert in agile. The coach is there to teach.

If you’ve read about coaching in other contexts you might recognise this as a question of non-directive coaching v. directive coaching. Agile, and agile coaching has never really come to terms with that differentiation.

As a coach you have next to no authority, all you can hope is that the coachees come to respect you and trust you enough to follow your suggestions. But then, maybe you shouldn’t be suggesting anything?

But if you claim to know anything – about coaching, about agile and heaven forbid software development – is it right to hold back on them when you know the answer? Isn’t it dishonest not to say what you know – or at least sincerely believe – to be true?

And if you can see what they need to do, don’t tell them but work to help them see that answer, well… thats just manipulation isn’t it?

When do you allow free will and when do you railroad?
When do you unlock self-knowledge and when do you teach?
When do you let people take decisions you can see are mistakes?
When do you know facts that will help? And when are you just full of the same biases as everyone else?

Take the documentation question: classically trained developers who have never worked in high-performing teams commonly see documentation as the answer to so many questions:

Question: How do we make sure requirements are clear?
Answer: Documentation

Q: How do we help new recruits find their way around the system?
A: Documentation

Q: How do we keep track of the code design?
A: Documentation

Q: How do we agree which bugs to fix?
A: Documentation

Q: How do we communicate with customers?
A: Documentation

Some people just don’t know what they don’t know.

I too was trained that documentation was the answer to these questions and more, I too saw the lack of documentation as a major problem when I started work somewhere new. It took time (and Railtrack PLC) for me to realise documentation wasn’t the answer, it was John Seely Brown and Julian Orr who help me to realise documentation was a problem, and it took Capers Jones to make me see the cost of documentation.

But should I impose my view of documentation on a team? – should I even be making them see the world as I do?

Ultimately the team are self-organizing. They have the right to document, or not to document, and they can decide to ditch the coach. (Being an agile coach can be a high risk profession.)

Ultimately they are allowed to self-organize long (seated) morning meetings. They are allowed to reject TDD, BDD, CD, CI and just about every other agile practice.

And you know what? They could be right.

Coaches need to be self-aware and with that self-awareness comes self-doubt. Just because a team doesn’t follow the normal rule book doesn’t mean they are wrong. They could have a better solution. They could have a solution that works better in their context.

Back in Cornwall, I paused for a few moments while the angels on my shoulders argued their case. Then I said:

“Put it like this, without source code control I wouldn’t get out of bed in the morning.”

With that question settled I moved onto the issues. What problems would it create? Why wouldn’t you use source code control? What is the worst that could happen? What difference would big boss man see?

Arse about face really but it worked. The following morning I walked into their office and found them checking everything in.

Eight years later that small company has grown more than 20 fold: would they have done that if I had answered differently? Might they have done even better? Did I make a difference or was it all them?

But I still face dilemmas like that everyday I’m “coaching”.


Like this post?

Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Throwing mud at a wall

iStock-515277657small-2019-02-6-18-44.jpg

Throwing mud at a wall is a metaphor I use again and again. As a description of what I do and as a metaphor for creating change in organizations.

When you throw mud at a wall most of it falls off immediately. Some will stick for a little while then falls off. A little sticks permanent. Perhaps too little to see. So you throw some more and the same thing happens. Sometimes it looks like no mud has stuck but actually a little bit has even though you cannot see it.

Every time the mud falls off it is sad, even depressing but you have to keep throwing. Thats all you can do really.

You keep throwing, the more mud that sticks the better the chances that more will stick next time. Gradually, slowly, sometimes imperceptibly the mud builds up. As long as you can maintain your energy, stamina and resolve, you keep trying.

It can be depressing. Sometimes you can stay positive and you give up. Perhaps you move on to another wall.

In this blog, in my books, in my tweets (thankfully vastly reduced recently) I throw mud. Yes, I am a mud slinger, some people think I doing it with bad intentions. But my intentions good, I see a world that needs to think differently.

And when I’m hired to help companies I see it much the same way. I throw a lot of ideas at people, I suggest lots of changes, I throw mud at a wall and most of my ideas fall off. Much of what I suggest gets ignored. No matter how much I talk I have no authority, people are free to ignore me.

Some places I’m very successful, some less so. When I’m inside a company I try to be a bit more directed with my mud throwing, and I limit the ideas I’m throwing. But still it is a question of stamina and resolve. Some places are just more receptive to new ideas than others.

And actually, this is my model for all organizational change. To my mind, all us “change agents” (yes I hate the term too) can do is make suggestions. Throw ideas at people, if they like the ideas, if they think the idea might help then they might adopt it. But they don’t have to. It is hard to force change on people, if you try they may say they will change, they may go through the motions but sooner or later – when your back is turned – the mud will fall off.

Individuals have free will. Most of them want to work as best they can. So if some “agile coach” turns up with an idea workers don’t think will work they are free to ignore it.

I’m not a great believer in authority: just because you are blessed with the title “Manager” (or “Director” or “Executive” or even “President”) doesn’t mean people will fall your orders immediately and without question.

The best way of getting your mud to stick, getting your ideas and changes adopted is to help people understand how such changes will benefit them as individuals. Benefit them in the work they do, the quality of their life-work balance and the pride they feel in work.

Conversely, there are some people, even some organisations, who are totally unreceptive to mud. They go out of their way to avoid it. It is hard enough throwing mud which doesn’t stick, but when people don’t want it to stick, well, I’m probably better off going elsewhere.


Like this post?

Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”