Hello again!

I received a little request at the weekend. Someone was watching my old Youtube video on Splitting User Stories:

In that video, I was commenting on the risk of one type of story spitting being overused. That of “Spikes”. They requested a little more detail on that risk.


“Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away.”


The aim of the Spike is learning. Why would I be concerned with learning?

Well, my worry with spiking is not the technique, but the overuse of it. Overspiking is something I see relatively often.


Why do some teams overspike?

Let’s visit that quote at extremeprogramming.org again and look at the follow-on sentence.

The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate.

That second part is the first problem. I see these teams being almost frightened to misjudge an estimate. So they Spike to effectively pseudo-code the solution during spiking, removing the uncertainty in the work.

What’s going wrong, isn’t the spiking – That’s just a symptom of the underlying cause, which is the treating of estimates as somehow a guarantee or commitment to a delivery date or size. We should all know that in the inherent complexity of software development, that there is a natural variation in work we do and too many outside forces influencing it be truly sure. This is why things like Scrum use the term “forecast”, because like the weather – It can change in a second. If a team is also using User Stories (also from Extreme Programming) then we need to be aware that this method has a natural uncertainty built in as well. That investigation is an integral part of the User Story concept wrapped into the internals of the approach. (See https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/)

I can understand though, that most “Agile Organisations” are not. And this pressure on one of the few metrics Agile teams may produce, is likely to occur, and likely to be abused.

We want to avoid this, because it will probably cost more in the long run. Spike X + Story Y = Z. There is a good chance that by simply integrating that investigation into the story, then by removing that throwaway code the actual work maybe Y or even smaller.

There are other reasons why overspiking can be occuring though. If you watch the video (Don’t worry – I’ll wait!) then you can see I adopted a rather naff straw hat to pretend to be….

Henry Jones Jnr! (They named the dog Indiana)

Archaeology or Tomb Raiding

Some of us have large and old products. Legacy they are euphemistically called. Often these behemoths are riddled with poorly written and documented code and features. Sometimes, it’s as simple as the knowledge about the system and it’s workings has passed out of the organisations mind. People are retired. Or left. Or been left and retired. Now the Product, which was probably constructed with lots of sensible decisions and ideas over time, but the collective gestalt of those sensible decisions and ideas is something far far more… more then they ever could have imagined. And now a load of new people have to try and imagine that entire context.

Painful. In that context, no one has a good idea what is going on, so everyone is spiking to try and experiment and discover how things work around here.

Have you ever seen a horror film, where the young and innocent (well one of them) teenagers venture into the ruins of the cold, dark abandoned house/hotel/castle/woods and one volunteers the idea “Hey, let’s split up!”

This is never a good idea. Unless you are the monster/killer/killer monster inside the aforementioned property.

But as an innocent developerImeanteenager, this is a quick way to die.

So, don’t do it. Don’t enter that cube of chaos on your own. Stick together.



Pairing and Mobbing are two powerful ways for a team to survive that Deathtrap Dungeon.

The final reason for overspiking I see, is some teams are not aware of alternatives.

Spike your Spikes?

Spikes are just one way to gain learning. Via experimenting with code. There are many other approaches we could run to gather that learning.

Alex’s Osterwalder’s “Testing Business Ideas”

It maybe there is a need for some customer interviews. Or surveys to gather data to reduce uncertainty on the WHAT and WHY of the solution. It could be looking at the analytics or even the discussion forums. There are a range of methods to help us understand more and learn. Spikes tend to work well for the HOW. But we have lots of others for WHAT. In real life those two often blur together more then we would like to admit!

Short and sharp. Like a good Spike, this blog post is over. What do you think? When do you see overspiking and what root causes do think led to it? Or do you believe there is no such thing as overspiking? I’d love to hear from you.



Idiots gotta idiot: Badmouthing the ScrumAlliance.

Never meet your heroes. They disappoint. Feet of clay, often worn proudly.


I regret anyone who would hold me in high esteem, a man who cannot limit himself when it comes to opinions or food. My oldest friends may admit that I am withering soul on occasion. And that occasion comes frequently.

But if one is to be the type that withers. One that continuously delivers snark, then I feel one has to have some base rules to what they snark on. The snark must be clever. An angle unspotted by others, The snark must be logical. It must be derivable by more than just the snarker when heard, And the snark should contain a dash of truth. If one is a politician, you want a lot of truth, if one is a comedian, then perhaps a bit less.

Sometimes people snark in a way that is just cruel, rude and false. I don’t like this. I would like to say it’s because my White Knight nature – dashing to the rescue, or perhaps because of my English deeply embedded sense of manners.

But likely it is because I am a developer at heart and I HATE errors in logic.

I have come across a big piece of Snarkware, and it does not compile.


A simple website of a few pages, badmouthing the ScrumAlliance (https://www.scrumalliance.org) the largest and most successful Agile non-profit certification organisation till now.

Now badmouthing bad agile is not new. I am a huge fan of some work done by an old colleague of mine Kerry Buckley, based off of some snarky content produced by one of the authors of the Agile Manifesto, Ron Jeffries.


The Half Arsed Agile Manifesto (or HAAM for short) is a good piece of parody, mocking those large companies that abuse the principles and practices of Agility. It rings true for many of us, who have seen similar patterns in our own old businesses.

So what differs the scrumsalliance.org from this? The HAAM is mocking misuse of agile ideas. The Scrumsalliance is attacking a particular group of people.

The scrumsalliance is attacking the very morals and integrity of thousands of people. Claiming that the SA is a commerical entity without morals:

“Your business has been ignoring the challenges of making significant improvements for years. Maybe even decades. Now your bosses have learned about the word Agile and you need to act…NOW. We can help. The fastest way to seem Agile without the risk of improvement is the Scrums Alliance certification ladder. Legitimize your people.”

Claiming that it is all about money generation:

You want to keep the same training budget next year right? We can help you spend, and then spend some more. Our certificates have certificates!”

BTW the ScrumAlliance is a non-profit.

Claiming that what is offered by this alliance is mere theatre with no real change:

“Your board members expect a lot. A now you can claim amazing achievement by changing job titles and renaming meetings. Shit that’s impressive!”

And for me, two ideas that show a bigger problem. A lack of understanding of Scrum and Agile.

I am happy to remove this when the real author comes forward….

Increase Group Think: My logic alarm goes off with this statement. Does the author think education is bad or wrong? Do they wish their colleagues to not learn? Are they worried about learning shared amongst all? Or are they claiming that the ScrumAlliance offers some form of unchanging and inflexible content that leads to unchanging or inflexible mindsets in their education packages?

The ScrumAlliance actually does something that very few other Agile certification bodies do. It does not prescribe* content. Slides, images, verbage. No. The SA actually sets Learning Objectives:

“Upon successful validation of the CSM Learning Objectives, the learner will be able to demonstrate at least three techniques for facilitating group decision making.”

Thus the trainer or coach can adopt whatever approach or technique they feel is proper to achieve that result. The ScrumAlliance acts as the quality check to ensure that the trainer has material and the skill to do that.

So already we have a challenge to this “group think” idea – Methods and approaches will vary.

But perhaps the discovery at the end will be the same, Cloned certificates!

No, because the LO model does not even say what the attendee should learn. It lists what they should be capable of. And that varies trainer to trainer. Coach to coach. The exact opposite of this point.

These Learning Objectives are built by teams of expert volunteers from across the Agile community to ensure we can educate people into NOT building Agile theatre but in fact real change.

There are Agile certification models that enforce content, slideware, verbage. But that is not the ScrumAlliance. Has the creator of this website confused their Agile organisations? There are businesses that like to maximise profit (like mine, http://www.agilebear.com) but if no one gets value from the learning, the budget disappears – and so does the profit. Anyone with any business sense knows that satisfying the customer and the consumer is essential to have return business. Customers are people and people are not stupid, unlike how they are portrayed by this parody. And secondly, AgileBear is not the ScrumAlliance. Has the creator of this website confused the ScrumAlliance with other private training businesses? Would the ScrumAlliance have reached such a large membership by making their consumers unhappy?

That’s not Scrum! What do you think the point of this image is? I am assuming it is meant in a projarative way. That somehow the victim is being oppressed by someone over a framework.

This does exist as a problem in the industry. But perhaps not in the way this author thinks. Forcing Scrum onto teams is an anti-pattern. Forcing anything onto anyone is an anti-pattern. My kids will not eat certain vegetables, no matter how much we push. This is why Scrum contains very specifically a job to help the team do Scrum well. The ScrumMaster. A role who serves the team. A person who coaches and facilitates. Not a policeman, as people will just hide their crimes. But a priestly figure to support and hear the problems. “Love the sinner, hate the sin.” This is what the ScrumAlliance advocates because this is what Scrum advocates.

So what’s going wrong? Is some business not doing that? Then they are breaking the rules of Scrum when doing so. Has the creator of this website confused the game with the players? If you cheat at monopoly, there is not much Hasbro can do about that, beyond publish warnings:

“Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.”

Scrum Guide 2020. Authors Ken Schwaber and Jeff Sutherland.

Or is this complaining about Scrum being inflexible? Being too controlling and limited?

“The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”

There is a logical flaw here. If Scrum is being imposed then they are breaking the rules of Scrum. The immutable part has much weight as the rest that is being ignored. If the immutable part is being followed, then Scrum won’t be imposed or enforced. Because we are doing Scrum-as-a-whole-thing. Scrum is not just the Framework. It is the framework, values AND Accountabilities/roles/jobs.

So either the author has gotten themselves in a logical traffic jam – Or they don’t understand what Scrum is. Has the creator of this website confused their Scrum? Or confused the abuser with the abused?

Or do they mean something as trite as HOW things are done? Scrum as implemented in a team has great contextual variety. Scrum itself has a very light rulebook. Most of what people fill their product development is with things that are not Scrum…

Personal Attacks.

As many will know, I have some philisophical differences with Jeff Sutherland. Both from a Scrum and a private business point of view. I disagree with some of his outside of Scrum personal beliefs. But that does not mean one can mock any person by sticking their head onto some clipart to abuse them personally. It is disgusting, and anyone who thought it was “good fun” or “that’s fine work” should be ashamed of themselves.

“The best part about defining an intentionally incomplete framework with an official guide is that it’s OFFICIAL! So we can say you aren’t doing Scrums if it not part of the guide. But…and this is where it gets totally AWESOME…it’s intentionally incomplete! So you HAVE to do stuff that’s NOT in it to even have a chance of making it work!”

Parody quote

Methinks someone doesn’t get Agile at all. The entire point of the entire Agile movement was that there is no one ideal way of producing software. That one must be empowered to empirically inspect and adapt, evolving both the product and the processes and practices associated with it. They also do not understand Scrum: Scrum, like Kanban, regards itself as an improvement process a method to inspect and adapt your methods. Not the method itself.

This incompleteness, is giving people space to fill it with content that is appropriate for their needs. The reason why Scrum is regarded as needing to be rigious is that it is a MVP of product development. You may need more, but you will struggle to get away with less. You need the trellis to support the plant. The flexibility each team has is how much detail and discipline they need around the handful of patterns that make up Scrum. How wide and strong you make the trellis is a team decision.

Again, the author seems to be running into a contradiction. If they are saying Scrum does not provide the answers needed, unlike an alternative – Well the alternative can only be Extreme Programming. The only true Agile software devleopment methodology.

However, the first line is complaining about being made to do things in Scrum they do not want. The problem here is XP would have exactly the same issue. It contains all the Scrum patterns and more. So are they arguing for Kanban? That would fail the first “we want answers” test. What is left? Devops? It’s not a comparable thing to Scrum. It’s more a philosophy that you achieve with methods like Scrum or Kanban or XP.

So the author is again caught in a bit of a trap here of their own devising.

The world famous Nigel Scale

All/nearly all ScrumAlliance trainers have been exposed to my notorious Nigel Scale ( Here is an out of date article on it from over a DECADE AGO – https://nigelbaker.wordpress.com/2011/08/01/the-nigel-scale/)

Basically, some practioners confuse core fundamental practice with contextual good practices maybe used. Scrum is only made up of those core patterns.

“Years of Scrums Alliance research has shown that attempting to measure success based on actual business value or customer outcomes is…well…really hard. Therefore it has been deemed best practice to make up an indirect measure of myopic productivity using a fictitious unit. This way you can control what success is and how much you get!”

The ScrumAlliance has not done that research. That’s a lie. The ScrumAlliance has not made up an “indirect measure of myopic productivity using a fictitious unit.” or even deemed it best practice. That is Story Points and was invented by the first Extreme Programming team in Chrysler. That is a lie.

Scrum does not contain the concept of Story Points, It is not part of Scrum.

Whether it is a good practice (NS2) or bad practice (NS3) is still up for debate. It has shifted from being super popular over the years, and I am not here to discuss it (though we can because like earlier – The problem with it, is people abusing the name and not using it as meant) The fact is this line is just untrue. A lie upon a lie upon a lie upon a subject of debate. Abusing points is a problem in enterprises. Has the creator of this website confused their XP with their Scrum? Confused the non-profit, community-led ScrumAlliance with private businesses like Scrum Inc that do use points in controversial ways? Or confused the law breakers with the laws?

“When no one can align on value, it’s better to just be really really really busy. Like, no less than 387% utilized. Seriously, do you want to get laid off or something? Plus, if you’re triple booked almost every hour of the day people will start thinking you’re super important. Promotion baby! Extra points for expecting everyone else to do the same, working after dinner, and responding to emails while on vacation.”

Being busy over output or outcomes.

This has nothing to do with the ScrumAlliance. Nothing. The Alliance has never done anything remotely like this, or recommended anything like this. The alliance has published articles on Sustainable Pace, and it is a part of the core LO’s of Scrum. So no trainer can be either.

The SA supports Scrum which has deliberate “BusyBreakers” in built to stop people pushing work into teams (Sprint, ScrumMaster) or pushing work into Sprints (Sprint Planning) and emsuring teams only pull what they can accomodate as a team (Sprint planning).

Scrums Is Like Training Wheels

“Are you seriously trying to kill a CHILD?!? You MONSTER!!! Don’t you know that code craft, devops, and kanban are WAYYYY too complicated for the ickle wickle bebies on your team? Their tiny team-member brains will literally EXPLODE! Don’t go confusing them. Be safe, start with Scrums.”

Scrum is not stabilisers. Scrum does not stop you failing. It is not training wheels. Scrum makes failing cheap and safe. Scrum is actually a balance bike. Codecraft, kanban, devops all great ideas – but kanban is a bit more like putting stabilizers on your bike you are already riding – “start where you are now” – and then changing the frame in transit. Codecraft and devops are like road laws and cycling proficiency. Same world but different things. Comparing these things like-to-like is strange. The baby language was an interesting choice. Exaggeration for comic effect normally works. Normally.


And then we finish with a page of made up Agile certificates that are thin carbon copy parodies of the ScrumAlliance’s three entry-level certifications. The humour here seems to be “pay money” and “sit through two days” – Though he does mention the examination needed. This is where the author hits home. The three certificates seem to be entry level. Barely enough content to align with a term at University (16+hrs each). How can you claim they’ve reached the top of the education ladder????!?

Of course reader, you can sniff my sarcasm. (Please don’t tell the wife). These are three of at least sixteen levels of assessment and resultant qualification one can achieve with the ScrumAlliance. But the author did not want you to know that. (Or perhaps they didn’t know themselves.)

To achieve the higher levels requires a little money, but far more importantly, a lot of effort and time documenting your learning, your journey, and alll the associated skills, people and organisations you have helped.

I passed my GCSE’s at 16. I was not a professional. But my learning wasn’t over.

I passed my A Level’s at 18. I was not a professional. But my learning wasn’t over.

I read for my Computer Science degree at 21. I was not a professional. But my learning wasn’t over.

I have done dozens of courses, taught hundreds, worked in companies all over the world on the coolest (and most boring) things you could imagine. I’ve coached everyone everywhere. I’ve seen things you people wouldn’t believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain. I am a professional. But my learning isn’t over.

There maybe organiations that only deal with entry level learning. But the ScrumAlliance is not them. There maybe businesses only focussed on the quick buck, but the ScrumAlliance is not them. There maybe authoritarian organisations forcing it’s members down one route, in only one way. But the ScrumAlliance is not one of them.

The ScrumAlliance is a bit shit sometimes. They are slow to react to members needs. They still don’t have a strongly endorsed scaling approach. The website has been a bit rubbish for years. As a member-led organisation, it can sometimes feel like committees and committees. Not enough members volunteer.

But none of that was mentioned. The author shot their mouth off, revealing their own incompetence and ignorance and missing the possible targets it could be aiming at. Such as Scrum Inc mixing certification programmes and a private business whilst also pushing Story Points as a measure of success. Or Scrum.org and Scaled Agile requiring slidware and content and allegedly even anecdotes.

If you want successful certification snark – Then look to this video:

The abusers will keep abusing and we must expose and ridicule them. The ScrumAlliance is not one of them. And neither is Scrum.

This parody seems to constantly confuse itself with self-contradicting complaints. Scrum is too strict. Scrum is too soft. Scrum is too detailed. Scrum is not detailed enough. Scrum is the ScrumAlliance which is also Scrum Inc and every private training company out there. Oh and throw the Scrum Guide in there as well. A positively pot-pourri of bitchiness.

So back to my rules on snark. Clever + logical + true (from a certain point of view)

The parody site fails all three tests. And has a look and feel that maybe putting itself a little close to the legal world… For the ScrumAlliance does have budget for lawyers, and it does use them.


EDIT: September 13th! Well, this post upset some people. Their counter argument was made and the response was I am a virgin and I cannot spell. Strong argument. 🙂

*In terms of spelling, I have popped back and corrected a few. (This was thrown together in about ten minutes.) I notice a particular snide dig at me accidentally using proscribe when I meant prescribe. Thinking about this, I may have been (accidentally) correct first time. I don’t think the ScrumAlliance proscribes material either. It assesses the Trainer and their Agile and Scrum Knowledge, and their experience – And lets them make the choice of material and method (within the LO guidelines) – So I’d like to thank the impolite author, through whose attempt to avoid refuting anything and instead making ad hominem attacks, has opened my eyes to another advantage of the ScrumAlliance.

Thanks! 🙂

Musings: ScrumMastery Full-time or Part-time?

Is ScrumMaster a a Full-time Role?

This subject has arisen many times over the last twenty years. It has recently popped up again when Jeff Sutherland, proclaimed “inventor” of Scrum said this:

Frankly, there is a lot to decompress in that statement – Red flags all over the place – But I want to dig into just the first part of the statement. “The Scrum Master job was designed to be a half time job.”

If it was “designed” as such, someone should tell the other “inventor” of Scrum. Ken Schwaber. In his original and seminal book on Scrum “Agile Software Development with Scrum” he says that “The ScrumMaster is a new management role” often assumed by “The Project Leader, Project Manager or Team Lead”. If there are many impediments “this position may need to be filled by a senior manager.”

Sutherland also claims that “The original model for the Scrum Master was Takeuchi and Nonaka’s organizational catalyst that manages up and down in HBR New New Product Development Game. Also on Taiichi Ohno’s facilitative leader who develops the cross functional team, can do all tasks that anyone on the team can do, and can help the team be successful in every way.”

If you would like to read the “New New Product Development Game” it says no such things about the leaders of the approach being able to do all tasks. The entire point of the “rugby” metaphor is overlapping skills in a cross-functional, autonomous team. A heroic leader that can do it all runs counter to that philosophy. Taiichi Ohno’s facilitative leader work is not commonly regarded as a source of ScrumMaster, and like OODA is not mentioned in any early Scrum writings.

So I believe there has been some post rationalising by Sutherland on ScrumMaster as a part-time role. And if you read the rest of the original post – You can see even he has stepped back from that in his own business. But not in a way that I would… But I digress.

So how I would I answer the question “Is ScrumMaster a full-time role”?

My answer is “Yes, in most settings we encounter” (I’ll handle exceptions at the end.)

Since this is an age-old argument, I will revist some classic points:

Do the people arguing against Full-Time ScrumMastery understand what an ScrumMaster does?

E.g. There was an example of someone doing Business Analysis as well as being a ScrumMaster to demonstrate the role was part-time. 

However, those of us with a deeper understanding of Scrum, know that ScrumMaster’s work the backlog. It is part of their job. Assisting the Product Owner and assisting the team. I regard that as just part of the ScrumMaster job, if needed.

I said many years ago that “Between theory and reality is ambiguity – And that is where the ScrumMaster lives.”  So this example strikes me as classic misunderstanding around the three services of ScrumMastery. Serve the Team, Serve the Product Owner and “Serve the Organisation.” (BTW like a therapist serves a problem drinker – not how a bartender does.) Most PT/SM ScrumMastery suggestions or examples are when people think the ScrumMaster only “facilitates” the events in Scrum. A simple error. 

I also believe Jeff Sutherland may not fully understand what a ScrumMaster does. Or, to be polite, I believe that he has imagined other mechanisms and methods to mean the SM does not need to do much on the “serve the org” theme.

Because the organisations he envisions are capital A “Agile”. Or because the surrounding management is fully Agile in mindset… and probably following his other marketed approaches. I believe this comes from his experience as a C-level person (ish) talking with higher level executives and coaches. Things look great as a honoured guest from 50,000 feet. Stripping away the nuance, this is an example of another simple error. The idea that once a business is in some imagined “agile” state, that everything is a wonderful, blissful, (probably static) state. In reality, humans human. Two’s company, Three’s an organisational structure. This is another example of “ed” thinking rather than “ing”

All organisations are in flux, especially “Agile” ones. That state of change means that the “service to the organisation” aspect of the the ScrumMaster role will perpetuate over time rather than dissipate.

Finally his statement of ScrumMasters taking on managerial responsibility in an organisation without managers is… odd. I do not want to break that apart further, but if we are kind it sounds like his ScrumMasters are doing.. proper Scrummastery! If we look at it unkindly, it sounds like his managerless company now has managers. Nothing wrong with managers, but he shouldn’t be using the ScrumMaster term so loosely. And if we were super-unkind, it could sound like he is breaking the very principles he asks others to exhibit. Pretending a Product Development Framework is a universal pancea or solution does no one credit.

However, this is an aside! Let us get back to part-time.

What does “full-time/part-time” actually mean?

Was Sean Connery a full-time actor? Did he need to act 8 hours a day for 300 days a year to add value to the films he was in? 

Should Firefighters be full-time? –  In the UK firefighters are mostly full-time jobs. Why? They aren’t putting out fires for 24 hours a day! Most the day they sit round flirting with women walking past their station and playing football. (I used to work next door to a firestation and they did these two things ALL DAY) But when the bell rings, they are focussed and quick. Because fires are all about cycle time. The quicker to the site, the smaller the fire. The less death and destruction. Imagine ringing 911/999 and being stuck in a queue. “Thank you for calling the fire department, your call will be answered shortly. You are number 73 in the queue. I am sorry we are delayed answerting your call. Here is some music… “ Their key metric is “Trouble to resolve”. How quick can I react? How quick can we fix this issue. 

Should Surgeons be full time? There is an aspect of professionalism. “Hi, today I’ll be playing the role of your surgeon. Normally, I’m a waiter, but today I will be removing your spleen..” We can all play at anything. But in serious settings with serious results, you want craft. Skill. Ability. You want this professionalism to be professional. 

Time and Space are critical factors in a CHANGE AGENTS role. If you are busy, you cannot take time to think. If you are busy, you don’t have time to try. You cannot experiment. You have no space for a second round. ScrumMasters must be TIMELORDS. One way, or another. 

There is a legacy of the factories left in this conversation. The working on a task as the only type of justifiable work.

Ian Fleming at his desk at Goldeneye, Jamaica

Back to actors. Actors, Writers, creatives are often asked “Where do you get your ideas from?” They come from the synergy of imagination and the world. The imagined and the reality. Thus, creatives experience the world as part of the “creative process”. This should be true of creative teams, (You probably now call them “developers” which shows the utter limitation in Schwaber and Sutherlands thinking) and the people leading them. I would say the aim is dedicated or not-dedicated. That is the real distinction. Sean Connery was a dedicated actor. He read widely about his craft. Firefighters are dedicated. They will die for you. Surgeons are dedicated. Cause you will die for them! To have that dedication requires respect to the craft. To respect the craft requires time and space. 

Now,  why does everyone WANT it to be part-time?

  • No extra cost. Developer now does this as part of their dev work as well. 2 resources for the price of one!
  • No change needed to management. Status Quo plays on. “Don’t you rock MY boat.” 
  • Thus, no change anywhere. The team empowerment is highly limited or non-existent. Zero change is the easiest change. Agile Theatre? More like Agile Mime. 
  • Allows Agile Coaches to float between these two stable and static worlds and justify their roles (The coaches lead “the change”) in a tacit agreement with management or just be periodically cycled out on short term contracts. 

But I feel again I may have gone too far. Suffice to say, the issue with SM as a JOB rather than a hat is a condition that is hugely affected by the context and surrounding forces being applied to it. 

Caveats! Where would I not have it full-time? If the work itself is minor or “part-time”. In a hobby setting, people can play at ScrumMastery. I can also imagine situations where the business-side is so wonderful and elegant (or small) that the change agency and business aspect is minor. I think this can apply in some Start-Up settings, but not any I have actually seen in reality. I think this is where Sutherland is trying to stretch Scrum into. And most of these idealised Unicorns seem to me just to be painted horses with a plastic horn pasted to their heads, defecating everywhere with the tech glitterati proclaiming it all paradigm shifting. 

Again, I go too far.  But not far enough perhaps.

So to wrap up as my kids need feeding.


The answer is:

KNOWLEDGE + SPACE + TIME + RESPECT = Dedicated professional ScrumMasters which leads to BETTER SCRUM which leads to BETTER PRODUCTS and thus LESS BAD COMPANIES.


Ideas and Rough Sketches: Changing Organisations, Icebergs, Penguins and Mikado mash-ups.

I was recently asked “How do you change organisations?”.


How. Do. You. Change. Organisations. ?

Intuivitively, I know what I do when I work to help change organisations… but can I:

  1. Write that down?
  2. Write that down in a clear and useful manner?
  3. Write that down in a clear and useful manner that is intellectually coherent and can stand critique with evidence and referenced examples?

I had planned* to do 3. I then descoped towards 2, and I am now rapidly heading past 1 to 0.

0. Sketch out ideas and concepts in a haphazard style.

So, I am afraid to say this post is going to float around the world of 0.

“The right tool for the right job”

As you will know, I have spoken at conferences about Agile Organisational Change since 2007. There has been some ups, lots of downs, and an evolution in both what I believe, what I see in industry and what the community generally accepts as good and bad ideas.

I do not proclaim to have some wonderful method or process one can follow to achieve success… but there are certain things I look to and try within large enterprises to try and change how we do things round here. 

So here is our first anti-pattern – And it makes me sad.


I loooove the word transformation, as it gives me the oppotunity to bring in one of my favourite subjects “obscure eighties childhood references” into play:


Robots in disguise. More than meets the eye! Autobots wage their battle to destroy the evil forces of… the Decepticons!

I adored Transformers as a child (and as an adult). I once based an open space workshop around that analogy!

It was called “Optimus Prime is Cool: Organisational Transformation and Transformer!”

Of the Transformee – The Truck

This was all about knowing thyself – Measure what you are before you start. If you are a truck – Know your dimensions, speed, MPH etc. Otherwise any organisational changes will be impossible to know if any improvements (or worsening!) has been made.

The Transforming

Understand the process of change. How to improve that change, and mistakes we can make… (hold this thought)

The Transformed

And what does the end state look like? The robot is more capable then the truck…

and the Transformer.

Me around 1984 (Note the V T-Shirt.)

Me! Or more precisely, you! Or even more precisely.. US! What do we look like? How do we need to work?


Now the sting in that workshops tail, was that transformation is the wrong word for what we do. Whilst transformation does give us the image of fundamental change – The caterpillar to the butterfly – The malformed crawler to the flying angel, it does bring with it a range of dangerous comparisons. The Butterfly is a one way sequential process with a beginning and an end… and an inbetween state – chrysalis – that is zero value and vulnerable.

So to revisit the above metaphor and destroy it…

The Transformed: The end state is in flux until we reach it. IF we ever reach it. Agile change is continuous and progressive. It will not be what you predicted up front.

The Transforming: Agile change is done in parallel, experiment-led, with an evolving and emergent model of change, as well as an evolving and emergent agile “operating model” within. It is not a sequential process where one follows instructions.

Leaders Optimus Prime (Transformers, G1, Autobot) | Transformerland.com -  Collector's Guide Toy Info

The Transfomer: This is not performed top-down like the eight year old GodNigel with his pile of plastic robots doing as he wills, when he wills it. This is a whole organisational activity. It take a village to raise a child? It takes a village to change a village.

Transformee: Why change? Being a truck could be right for us. We just need a slightly faster truck.

Maz @TFsquareone #GCWO on Twitter: "Hasbro Transformers G1 Powermaster  Optimus Prime & Hi-Q (1988). The first Optimus Prime toy I had and my  goodness it had insane play value. However much I
Powermaster Optimus Prime. Interestingly, this toy wasn’t even Optimus Prime in Japan. Instead he was Powered Convoy and… <SIGNAL CUTOFF BY BOREDOM>

Being agile is like being fit. Being fit doesn mean buying gym membership. It means going to the gym.. twice a week. Forever! And eat healthy. You can’t out train a bad diet. We will discuss eating healthily later.

So transformation is (alas!) the wrong word and the wrong mental model for this work.

Here are our next couple of anti-patterns to avoid. There are a few classic “quick wins” that will turn out to be “long losses” – so we want to dodge these big mistakes from day one. 

DO NOT: Copy or clone.

Clone Troopers | StarWars.com
Begun, the clone wars have. (strictly speaking it was one war – and how did Yoda know there would be more than one? <SIGNAL CUTOFF DUE TO PREQUELS>)

It has been very tempting in the last few years to curse out Henrik’s Kniberg’s work at Spotify. Back in 2012, Henrik did some great work as a coach with Spotify and he and Anders Ivarsson captured that in the below paper.

A video is also available on this online.

A lot of people liked this work, such as myself, and it became heavily referenced.

Then came the DARK SIDE. Certain consultancies and coaches started using this work, not as the experience report of what Spotify was thinking of doing, but as a TEMPLATE to copy in other organisations.

And that is when the wheels came off. First, because you are not a swedish music streaming unicorn. Secondly, if you were, well Spotify were not doing these things. They were ideas and experiments that have never been done, or done and cast aside, or evolved, or or or…

And thus “Spotify Model” became a shorthand in the Agile community for danger.

BUT it wasn’t Henrik’s fault. Nor Spotify. Nor that PDF. It was the fault of others who took some experiences and some ideas and wrapped them up as if they are a pragmatic, proven and idiot-proof methodology.

This CLONING model exists in many other Agile contexts. SAFe itself allegedly started as a clone of work done by Leffingwell with Nokia. Copy and Pasting others answers into your organisation is a doomed endevour. What were the questions you were trying to answer? What was the problem you are trying to solve?

The better Agile Scaling approaches (LeSS and Nexus but especially LeSS) seem to understand this difference, and only offer up really tried and tested Agile patterns – The rest falling into the world of experiments.

DO NOT: Attempt big bang change. Overnight. 

I think this is self-evident. But every big bang change leads to a.. big bang! Obviously, we would use our Agile principles to introduce these principles and processes – Otherwise we would be hypocrites! And if the change worked, we would be instantly wrong! Luckily, it won’t work – But it doesn’t stop organisations trying again and again to do that.

We will have to be Agile with our Change. Agile Change is about Agile Change and not just a change to Agile. We will start with a challenging goal or vision, we will build a backlog of change, we will do small slices, each one delivering value on it’s own, we will frequently inspect progress and the work, and make adaptions to the work. Thus the change will emerge and evolve into the highest value continuously.

DO NOT: Focus on the technology process tool part of the chat.

Since, you will need to evolve these processes frequently, so mapping them into a tool is silly and wasteful until stable. Also, the organisational structure needs to be considered. This seems like a quick win, get the same tool shared over 100 teams.. but the long-term damage caused by locking your approach down too early (allowing limited iteration), by having the tool imposed top down (limiting autonomy and self-organisation) and indeed, you would be performing the copy/clone anti-pattern at a technology process level rather than the business process one (Spotify et al) and getting all the problems associated with that as well.

And just like SAFe it wraps good practice with core practice and bad practice into a easily consumable (and impossible to digest) lump.

(Feel free to explore the Nigel Scale material for more on this conversation:)

The final part of the tool anti-pattern is..

JIRA and it’s ilk, are like Ticks. Easy to get, very difficult to remove.

Any method/tool/process that is easy to introduce and hard to remove, is very difficult to experiment with and pivot appropriately. If you see my collaboration tools blog post here, you will see some alternatives:

Collaboration Tools: 2021

Beware Harpoons.

Harpoons and lances
Many a thing falls into this context. Sometimes people as well.

PART 2: How I change organisations.

Right, the problem space is lightly laid out. (There are lots more mines in that minefield, but this is a 0 article, remember!)

So here are our first two tools.


THINK: All of the antipatterns listed above, are attempts to avoid critical thinking. To actually reflect and understand where we are and what is going on, and then tentatively and carefully inspecting and adapting our way through this difficult journey of change. And that is not unexpected. Human beings struggle with uncertainty. At a base level we crave that solid foundation, and when you are a manager or worse, a leader in an organisation, your knowledge of that field of play (The processes, the people, the products, the markets, etc) gives you confidence to make decisions.

This is the point, I’d like you to watch this video on leadership and VUCA:

So we can see, a range of thinking tools, and an appetite or at least acceptance of VUCA is needed to be able to approach this problem. I am sure I will add more to the blog on this idea in the future. But in the future, if you are a coach you need to turn your ego off and your brain on. THINK.


Experiment. Or as I heard Linda Rising say once ( Author of “More Fearless Change”), they are not really experiments as you are not running it multiple times, and you often do not have a control group – So really they are trials.

Try, try and try again. If it works, amplify the experiment, if it doesn’t, then dampen. Do this with different ideas, in parallel. Do this in differentr areas. But try. Discovery through delivery rather than deliberation through discussions in meeting rooms and zoom calls.

Try small. Try humbly. But TRY.

With these two basic (but under-utilised) approaches, now we can start approaching the problem itself.

My work on this is going to consist of three general areas

  1. Kotter.
  2. Scrumming the Iceberg
  3. Mikado mash-up.


I wrote a book nearly ten years ago. I never published it because it wasn’t very good, it was full of hypothesis and opinion but no facts and I got busy having kids.

The kids are older now, those random ideas now have facts behind them (or I’ll conveniently forget them) and it turns out we are in a post-fact society anyway, so since everyone else is running their mouths with books… perhaps so should I. At least in blog form.

Anyway, I now have a chapter of that book on John Kotters famous (and cutting edge AT THE TIME) work on organisational change. I am going to cut and paste it… but if you see any editorial comments like this <Hello! This is Nigel2021 speaking. I may overrule or disagree with Nigel2011, but I will keep in the original content so you can contrast where we are now, with where we were then.>

So let’s go!

Kotter Change Strategy with Scrum.

John Kotter is a professor at the Harvard Business School and author, and is the leading authority on change and change leadership. His international bestseller “Leading Change”, covered a famous 8-step process for implementing successful transformations – Conversely, this process can be looked at, in reverse, to see the 8 classic errors a Change programme will make. I want to discuss those here and bring forth how using Scrum can help mitigate these huge issues.

Step One: Create Urgency

For a organizational change to start we need to create a sense of urgency – Or at least make visible and harness the current underlining sense of concern. Most of the early uptakers of these techniques on an enterprise scale, did so because there was large and hairy problems with the business that needed changing.


Error #1: Allowing Too Much Complacency

Even in those organizations – just because the leadership saw an issue, did not mean that the workforce did – Or more precisely, the top did, the bottom did but the insulated middle layer, they did not. This is often where change programmes hang – not because of the workers but because of the middle managers with limited visibility – not at the coalface, and not at the business front end, it is easy for this community to “sandbag” a transformation. We need to ensure the pace of transformation and motivation to move forward is high on all levels. Bringing in external professional coaches and trainers (CLANGG! That’s the sound of an advertisement) can really help get the initial sense of urgency going along with strong and coherent vision (which I promise is coming soon…) If we do not have a sense of urgency, if we have apathy, we are not going to be able to get any traction with the change. However, don’t mistake sense of urgency for fear. Fear is something relatively easy to generate in an organization but it will severely constrain us. People will perform the equivalent of pulling up all their drawbridges and hiding in their metaphorical castles. Penetrating those mental castles would be very difficult indeed. We need to prime people with the appropriate sense of urgency whilst keeping them open to new options. <Nigel2021 here! You can also motivate change and create urgency with a Sense of Purpose. Something positive and engaging, and not just ooh-err we are in a bit of trouble. Harder but I feel more satisfying.>

Step Two: Form a Powerful Coalition

Convince people that change is necessary. This requires support from key people within your organization. We spoke earlier about Change MANAGEMENT – Well, really it’s about Change LEADERSHIP.  It is said that you “can find effective change leaders throughout your organization – they don’t necessarily follow the traditional company hierarchy.”  Luckily, with Scrum we have a system that embraces this concept totally  – We can bring together a cross functional team of empowered individuals to lead the change, This is where the concept of ScrumMasters is crucial – we have embedded Change Agents thoughout the organization to help this coalition and in the largest organizations to generate a task force to do this work! We need then to build these individuals into a cohesive team.

Error #2: Failing to Create a Sufficiently Powerful Guiding Coalition – How committed are your coalition? I have a rule of thumb – The Empty Chair Twice Rule. Anyone can miss a meeting, a call, even on something as important as this. If you miss it twice? It is likely that person is missing this for some underlying reason. Not bought in? Not enough time? Not enough commitment? Belief?

<Nigel2021 here – I have some material on this powerful coalition idea. Even Kotter has moved on from that commitee being solely enough. He now talks about a volunteer change army. That is what we will need to create? How? See the next area – But the answer is ScrumMasters>

Step Three: Create a Vision for Change

Why are we doing this? Why? Why? Why? Once we understand why (and this need to be real and tangible – “more money” is not tangible enough) then we can start articulating what this vision actually is – Though Scrum does not provide any visioning techniques, a lot of us in the Scrum movement draw upon Jim Highsmith’s ideas around Product conception and visioning (Elevator Pitches, Future Press Release, Peer Consensus) and Luke Horsemann’s Innovation games (Product Boxing, See the Future) to help us generate and genuine, tangible, inspiring direction.

Error #3:  Underestimating the Power of Vision – Vision is CRITICAL. It inspires, it sets direction, it motivates, it helps us self organize as a coalition team and it helps the change itself (which will steer in a variety of directions as we discover more about our organization then we ever wanted to know) stay the course.

Step Four: Communicate the Vision

We must constantly bash the organization over the head with WHY. People are not stupid, they will not jump just because we say so – they need to be persuaded, they need to understand WHY we must make these changes. The vision is the carrot to wave under the organizations nose. And this must continually happen. Every day. Big businesses are quite collectively dim – they don’t mean to, it’s just often a symptom of their structure – this means that we have to constantly articulate WHY and WHERE  we are heading so that people can align their practices within that big picture. <Nigel2021 – Back to Sense of Purpose again – The vision can be an articulation of that sense of urgency but I guess in a positive way and not just the classic negative one.>

Error #4:  Under-communicating the Vision by a Factor of 10 – Kotter has calculated that Visions are often under communicated by a factor  of ten possibly a hundred or even a thousand? The error of thinking a one off communication or “summit” will somehow carry people through months of work. Change and possible pain – is far too optimistic. We must constantly communicate the need to be Agile and why we must be Agile to the organization as a whole. Frequently.

Step Five: Remove Obstacles

What is blocking the change occurring? Are some people resisting? Are their processes or practices getting in the way?  As we know, Scrum is a issue generating machine – It’s like your Mother-In-Law.  It will constantly nag you to improve. It is like an MRI Scanner – It will show up all your problems so you can fix your problems. It does this in terms of “The Change” as well as in terms of the teams running Scrum.  Removing Obstacles will enable to the change to move forward and ease the effort required to be Agile within the Organization. We must recognize and reward the change leaders, the coaches, The ScrumMasters, the internal early adopters and we must identify those people that are being anti-bodies to this change – being resistance – and we must work with them, coach them to understand why this approach is valid and the right one for us. 

Error #5:  Permitting Obstacles to Block the New Vision –People go to hospital. They have the scan. They find out bad news. For some it is very bad news. What do they do? Treatment? Sometimes the treatment is painful. Some people just turn off the Scanner and don’t go back to hospital. These obstacles are not going to go away. They will not fade with time. We can hope we as an organization will “get better” in time.

<Nigel2021 here, This is why we need to do Scrum as a change approach – To really put some energy around the removal of these obstacles. Many “Agile organisations” I know have not removed fundamental root cause obstacles. Instead they work around them. It is not working very well>

In my experience, Hope is not a Strategy.

Step Six: Create Short-term Wins

Success feels good. People only really believe when they see it with their own eyes. When I started doing Scrum, I was very skeptical (It’s my nature – sorry) but when it was shown to work, with my environment, with my team, my friends, I was won over. We need to demonstrate as early as possible success to people. We cannot expect fancy slides and clever talk to cover the “gap”. Success reduces fear, reduces resistance. Often large organizational changes have been created and pushed in a very traditionally planned manner. Like the metaphorical waterfall with all the value coming at the end. You may have seen the traditional change curve, where people say “Don’t worry – it’ll get worse before it gets better.” Who waits for it to get better in practice? Not many people, considering in badly planned changes this curve is LONG and DEEP. Luckily, Scrum requires that each Sprint (normally monthly in a change context) we must have something demonstrable. Something valuable to the business.  Within Scrum we are forced to create short term wins as part of an iterative approach as well as work the long term vision. Pick good opportunities then reward those that succeed. Or you could take the Ken Schwaber approach and pick the scariest most risk laden project – at least that way people can’t play games with it and strangle it in it’s proverbial cot.

Error #6:  Failing to Create Short-term Wins –An Agile Transformation is expensive and time intensive. If you do not show quick ROI like all big projects you are under a lot of pressure straight away. And in change projects they are all too likely to be killed unless a VERY strong ROI can be continuously demonstrated. “What have you done for me lately” is a very good motto for the Change.

Step Seven: Build on the Change

Declaring victory too early. Real change runs deep. A pilot is fantastic but that is all it is. A Pilot. You should rotate Change agents to keep them fresh (I once spent far too long in Sheffield on my own) and keep a constant eye on your Transformation Backlog. 

Error #7:  Declaring Victory Too Soon

Nuff Said. <Nigel2021 – Oooh topical! For 2010. Bush declared victory too soon. There was lots of pain after this event. Real change is long term, and long lasting. Most changes fail because the funding and organising is in months not years. Especially around Agile Coaches.>

Step Eight: Anchor the Changes in Corporate Culture

To make this work you need to embed this as part of your culture. People will leave, retire and new people will take their place. Does the Culture become part of them or do they start diluting the culture? When we hire new people (especially at higher management grades) we need to endure they align with our vision and engulf them with our ways of working and principles for a significant period of time

 Include the change ideals and values when hiring and training new staff.  Have strong succession planning in place for the majority of your key roles, both change coalition and in general across the organization. 

Error #8:  Neglecting to Anchor Changes Firmly in the Corporate Culture

It doesn’t matter how great the leader is – If they leave we need to continue on without them.  Otherwise, all this is for nothing. <Nigel2021 – Succession planning is critical ESPECIALLY in your change agent roles. They have high turnover so we need to ensure we don’t keep randomly pivoting with each new coaches personal proclivities>

 Be decisive – Delete NoNo’s.

NoNo is the name of a penguin. 

No wait, come back! 

NoNo is a part of Kotters book, “The Iceberg is Melting”, where he uses an interesting approach of a cod-children’s story around Penguins and Icebergs to make some important points about change.

NoNos (both the penguin and the archetype he has generated) are “highly skilled urgency killers” to quote Kotters “Sense of Urgency”. A NoNo is not a sceptic – Sceptics can become very useful champions once you have won them round. (Sound familiar? Hint – someone writing this article was once a sceptic) NoNo’s look to discredit those trying to create the sense of urgency and will do anything to derail the process. The line between Sceptic and NoNo is well documented in Kotters work. Intent is the big driver – A Sceptic is open-minded but… Sceptic. A NoNo has made up their mind already and is fighting (openly or covertly).

Kotter (and I) recommend you never try and co-opt NoNos. The famous metaphor of tent sleeping arrangements and toiler facilities does not apply here. NoNo’s are not house trained. (or at least tent)

You ignore NoNo’s at your peril. You can hope they won’t go around destroying and politicking against the change… but Hope is not a strategy.

Kotter recommends distracting the NoNo’s (literally sending them away to some foreign office) or immobilizing them with social pressures, this can work with those on the lighter end of the NoNo spectrum, but will not help with the major NoNo’s or you can get rid of them.  This is my preferred strategy. The amount of times I have personally heard “I wish I dealt with XXX sooner.” And XXX is always a person. You will have a clear idea early who are the NoNo’s. You need to do something about them, because trust me on this, they are working every day to do something about you. <Nigel2021 agrees with this even more. Love your sceptics. They are THINKING and TRYING but maybe struggling and need help, and can help us! NoNo’s are destructive and we need to exorcise those demons.>

Goodbye and fairwell,


2. Scrumming the Iceberg

My work on Kotter has hinted at this, but lets dive a bit deeper.

Coaching Team Strategy – Eating your own Dogfood and Boiling Frogs.

Our coaching teams should also be operated on a Scrum model. Whilst coaching, training and consulting are time dependant. (You have to perform certain work on certain days) we should still use a velocity concept to <forecast> work. More than anyone, it is too easy for coaches to work at an unsustainable pace. Four week sprints make the ideal planning horizon. 

We utilize Scrum to roll out Scrum into the development teams themselves -“Eating our own dogfood” – and we’ll gain all the benefits from the framework. Reduced risk, Short term wins, Visibility and the ability to embrace a changing world. This will also us to gather feedback on how Scrum works in your organisation.

Large scale changes cause increased risk, fear and resentment whilst gradual systematic change programmes allow us to keep people, process and projects content and allows us to bring these products along with us. By using Scrum, this also allows us to make small gradual “baby step” changes to teams and organisation without risking any current deliveries.  This is the “boiling of the frog”.

“The boiling frog story is a widespread anecdote describing a frog slowly being boiled alive. The premise is that if a frog is placed in boiling water, it will jump out, but if it is placed in cold water that is slowly heated, it will not perceive the danger and will be cooked to death. The story is often used as a metaphor for the inability of people to react to significant changes that occur gradually.”

Wikipedia 2010.

Scrum works best in Knowledge based environments building a cohesive and ever changing whole. The most common manifestation of this is Software – but Change projects fit perfectly into this metaphor. A need for a cohesive end product (the organisation), the need for vision (often lacking – which we’ll come back to in a moment), the need for planning but at appropriate levels (detail now – epic in the future) a need for constant short term wins as well as steps towards a larger whole, a wider wisdom-of-crowds from diverse, cross-functional teams and frequent inspection and adaption to empricial judge our position and pivot to the next best position. (Retrospectives, Reviews)

So we have our Product Goal, probably an aspect of the overall vision of change, we have a backlog of all the work we want to do to achieve it. We prioritise it, we select a subset that creates a viable increment of value – We plan it, and then we do it. Every 4 weeks we come together to review our work and retrospect to learn and pivot on new information.

However, you maybe asking, “why do I need to plan my work? I’m an Agile Coach? I sit with my team who hired me and work with them until my contract runs out. I don’t want *another* coach sticking their head into my business”

Oh dear. I am sorry. But there is an iceberg approaching and we need to Scrum it as a organisation to get out the way!

The Traditional Organisational Pyramid

Most so-called Agile enterprise transformations have not taken full advantage of the principles, tools and techniques that we apply. Too often, they have implemented Agile at the “bottom,” in their development teams, but have not embraced the principles at the “top,” the strategy levels of the business, or even at the “middle,” within the layers of middle management and process.

<I said that in 2010 and things are better… but not as much as I would hope>

Change Management

I now want to explore an areas that crucial importance to any large organisations transformation. The management of the Transformation itself.

There is an common saying in the Change management world – “Seventy percent of Change projects fail.”

This is an astonishing, apocryphal, but also very believable figure. Look at the large organisations doing Scrum currently – I would easily say there is a high failure rate – or more precisely, since even doing Scrum awfully and only at the lowest levels of a business in a haphazard manner is still far more successful then what came before, there is a high failure rate “to achieve great results.”

The first mistake is to “forget our principles when we scale”. (Geoff Watts 2007) Most coaches recommend a gradual rolling out of Scrum into a team to prevent large  drops in performance and to reduce the risk of non delivery – Why then, do large organisations often try and either plan their change in the traditional flawed predictive model, or try not to plan their transformation at all and be swept along with the flurries and changes of direction that comes with a rapidly moving business world?

Enterprise Transition Commitee PRIMER.

 “[ETC]…is a single Scrum team responsible for managing the adoption. This team is called the Enterprise Transition Team or ETC. “ [Enterprise Transition Council/Committee]

Schwaber: Scrum and the Enterprise 2007 page 9

<Things have changed since> Ken recorded his Enterprise Transition work,  in “Scrum and the Enterprise”

I prefer term Coalition over council or committee. (I hate committees – people always seem to put committees together to stifle rather than to expand. To strangle an idea rather than catalyse it )

The Enterprise Change Coalition is going to be a genuine coalition. A coming together for a single purpose. Not to manage like with a “council” not to be subservient to any other part of the organisation, as a “committee”.

A coalition is “an alliance among individuals or groups, during which they cooperate in joint action each in their own self interest joining forces together for a common cause.”  – Wikipedia 2010

I’d recommend you have a “friendly” HR person available in the coalition. There will be a variety of change in positions, roles and responsibilities and you will be inducing turnover and possible disorder. There will be unhappy people. We want to make sure this is done with the right principles and within the legal employment framework. Especially in Europe, it’s very important to do the right thing in the right way.  Or get sued!

We can start building my idea of an Agile change organisation structure as follows. (as mapped on to the original organisation pyramid we showed you earlier)

The arrow of ETC

We have the Enterprise Change Coalition (ETC) existing at this highest point in the organisation possible, with a strong visionary sponsor chairing this committee. This coalition is mostly made of up senior important organisational figures who are bought into the change but not solely made up of them. There will also be cross functional members from the entire strata of the organisation “bottom” to “top” from all the main communities. Product Owners, Team Members, ScrumMasters, Stakeholders and other colleagues. Each will have a contributing influence and visibility of things that the others cannot see.  Without the real workers this would become an ivory tower talking shop. Without the leaders, this becomes a sharing of greviences in a bar, without power or position.

This will be structured as a Scrum Team.  Schwaber recommends “The most senior executive in the enterprise is the Product Owner.”  As I said before, it is better to think of this as a coalition more than a mere self-organising Scrum team. It is more self-directed. 

<Nigel2021 here! Scrum finally caught up with me on this front in the latest (2020) version of Scrum. Self Directing teams have power over WHY, WHAT and HOW, compared to the traditional Scrum Development Team owning the mere HOW.>

The PO in this situation will, at a minimum, have to be “presidential.” I prefer the leading executive to be building this group as a guiding coalition (see Kotter) and so prefer the Executive to be acting more as a ScrumMaster than Product Owner. In that case, the more senior but less involved organisational leader (Chairman over Managing Director) may be the Product Owner. 

If you have the main executive as Product Owner, this can then lead to a very top-down rollout of Scrum. (Some leading Agile figures would shudder at one of those words “top-down”, “roll-out”.) I will decouple this slightly from Scrum and this discussion and will use the term “Sponsor” for this senior leading figure.

<Nigel2021 – Looking at this with ten years experience. I do fear top-down transformations far more now. Because they are often so badly done. Building more of an Agile Leadership Team involving all levels can really give some bite and some raw pragmatic intelligence to this change.>

<Nigel2021 – OK here comes something a little more controversial!>

Centralised Coaching Team

You will need to have a coaching team dedicated to the roll out of Scrum <lets change that to Agile Change> across the organisation. This team will also need to be cross-functional, as they will work across the diverse areas of the organisation. They will be made of Agile Coaches from a variety of backgrounds to encourage diversity, avoid groupthink and to have a little healthy conflict. A Dash of change management experience is also useful but get the balance right – It is very easy to take the coaching team down a too pragmatic route. You do need some fire in there!

<Nigel2021 – I have more material in video and presentation form on my opinions on this teams construction since 2011 – But that is probably another blog post!>

The coaching teams needs to be out of direct line management of all but Enterprise Change Coalition. The alternative is a coaching team that is well aware of it’s position in the organisation. Too low down and it will not feel it has the authority to deliver genuine change, it can easily be squashed or mitigated by it’s own line management, and it may feel a need to align with the policies of it’s own place in the organisation. 

TRUTH: I was on a Agile Coaching team that was part of An Architecture Design community that directly reported to the Chief Architect. Hmm. Talk about putting a fox in the henhouse.  Or maybe the Agile Hen was amongst the National Union of Foxes yearly conference. Either way, it was a very awkward “odd couple” and severely hampered and finally destroyed their transformation.

The coaching team needs a roaming remit – to be able to align with the goals and vision of the Enterprise Change Coalition.  These two communities need to be tightly coupled.

There is one more piece in this puzzle. The piece that is missed.  The secret ingredient…. No. Not embedded coaches, but instead….

ScrumMasters as the Change Army

ScrumMasters. We will be building a layer of change agents waiting to be called upon! We’ve all talked for a long time about the Change Agent aspect being crucial in the ScrumMaster role. We have all discussed the essential nature of the ScrumMaster as a long term, full time role. This is why. <Nigel 2021 – This is why most Agile Transformations struggle. Due to the neutering of the ScrumMaster community. And the replacement of them with a thin layer of externally hired short-term contractors as “Agile Coaches”.>

Build ScrumMasters. Now.

We have a superb organisational change workforce, ready to embrace the need to continuously improve. Linked in with the coaching team/s providing expert support and the ETC dealing with vision and the biggest disfunctionalities. All connected. All interwoven. All focussed on people, purpose, principles and practices in the right way.

The ignoring of the ScrumMaster community in this way is criminal. Embrace the power and effect of this community. They are the assault troops (to use another horrible war metaphor) for the change. (P.S. I originally wrote “We are the assault troops.” – You can take the boy out of the ScrumMaster job, but not the ScrumMaster out of the boy.)

If we don’t do this, then the decoupling of the SM’s from the ETC and Coaching Team will cause us all to head in different directions. Thousands. And this can easily lead to sub-optimisation, where teams individual optimisations for themselves, effects the organisation as a whole. Or worse, the teams don’t optimise anything, the scrummasters fade into process enforcers, and the status quo management, can slow, suppress and finally stop any progressive change.

With that in place, (or under serious construction with HR), then we can in parallel approach the third aspect.

Nigel2010 and Nigel2021

<Nigel2021 here. Agile Coaches and ScrumMasters is a hot topic at the moment in the Agile space – With some businesses deleting all their SM’s and having a couple of roaming Agile Coaches covering the gaps… oh and traditional management doing the same old thing. What a car crash. I am less pro-centralised coaching team then I used to be, but the de-centralised model has crashed and burned everywhere – So we do need to find a balance, and the SM’s are the key here that NO ONE IS USING. This needs to be another blog post I think.>

3. Mikado Mash-Up.

Hello! This is back to Nigel2021 again – Before I start this, I notice the same idea has emerged in quite a few places, as well as the underlying pattern being incredibly common in successful agile organisations.

Mikado is a pick-up sticks game originating in Europe, played with a set of same-length sticks which can measure between 17 centimetres (6.7 in) and 20 centimetres (7.9 in).

In 1936, it was brought from Hungary (where it was called Marokko[1]) to the United States and named pick-up sticks. This term is not very specific in respect to existing stick game variations. The “Mikado” name may have been avoided because it was a brand name of a game producer. The game is named for the highest scoring (blue) stick “Mikado” (Emperor of Japan).”

Wikipedia – 2021

Each player’s goal is to pick up as many sticks as they can, one at a time, without making the other sticks move. 

The Mikado method is a book and methodology to help refactor existing legacy codebases. (https://www.manning.com/books/the-mikado-method)

The Mikado method is far more interesting and complex and useful then how I use it. So from now on I am going to call my work, Mikado Mashup.

The heart of the real Mikado method is

  • Set a goal 
  • Experiment 
  • Visualize 
  • Undo

And a lot more interesting ideas on top of this! But I use this to gradually move teams from traditional component delivery models into a more value driven feature team based approach:


“A feature team is “a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.” Feature teams are an essential element to scaling up agile development. Without a feature team structure (but instead, a component team organization—based on code ownership, combined with a single-function organization—analyst group, programmer group, testing group, …) your organization is likely to create numerous wastes and sub-optimizations that lead to a sequential (waterfall, …) development cycle. Feature teams structure resolves many of these wastes but also introduces change and challenges.”

From featuresteams.org

We want to avoid a couple more anti-patterns in any organisational change:

DO NOT: Map Agile or Scrum onto your current structure. 

I used to do this – Adopting the Kanban approach – “Start where you are now”, to reduce political strife, power games and to get the ball rolling swiftly for another quick win. But without significant energy, it can be impossible to move on from this state. You end up with at best slightly better then you used to be… for leaders. But fr the workers a worse experience. Or even worse, mere Agile theatre of post-it notes, standing up and JIRA JIRA JIRA as far as the eye can see.

I relate this back to the popular change tool, the Satir change curve.

Well Assimilated Change
From Steven M Smith’s blog – https://stevenmsmith.com/ar-satir-change-model/

Again, a whole article lurks with this one idea – But inherently it is the idea of a new foreign element inducing chaos and disorder and then as Steven says on his blog:

“The members discover a transforming idea that shows how the foreign element can benefit them. The group becomes excited.”

And as we all have seen with many change programmes, the introduction of foreign elements and chaos can lead leaders to stop the change before the integration and success of the new status quo can happen.

Well, in my experience an Agile approach both dodges this problem, and steps straight into another one.

Bad agility. Half arsed Agile, as my ex-colleague Kerry Buckley called it – https://www.halfarsedagilemanifesto.org – We all hate it, it’s everywhere. Why? Because shoddy agile is better than before. Ron Jefferies (Agile manifesto author, friend of mine and professional curmudgeon) calls it “Dark Scrum” – A better name would be “Dark Agile.” A corruption of Agile values and principles AND practices.

So, to quote

In the kingdom of the blind, the one-eyed man is king. - Desiderius Erasmus
As Kurt Vonnegut said: “If you can do a half-assed job of anything, you’re a one-eyed man in a kingdom of the blind.”

So, if we map agility onto what we do now, we are setting our selves up for big failure.

Agility is about big change… in small packages.

And at a lower level of detail:

DO NOT: Use Component teams and try and connect.

You will end up with a sea of dependancies, a mountain of blockers, an army of schedulers, a JIRA full of… well JIRA and more process then you started with at the beginning. And like in the film “A Bridge too Far” a fantasy version of the very real Operation: Market Garden in WW2: Where the allies attempted to capture 9 bridges to allow an army to race across them and deep into Axis territory. If they couldn’t take and hold every single bridge in the plan, the plan was doomed.

A bridge too far… can you guess what happened?

Component teams are the death of agility and the death of your business. We must move into value driven feature teams cross functionally spanning the components.

Re-enter the Mikado Mash-Up

I combine that Mikado Method idea of

  • Set a Goal
  • Experiment
  • Visualise
  • Undo

To gradually and iteratively slice up component teams into feature ones. Doing one small change at a time, so not as to disrupt the delivery or value of the remaining stack.

An example:

Imagine we have ten systems with multiple teams working on each system. There is an assumption that all ten systems need to currently plug together to deliver value.

So what first?

My first goal would probably be to create a team that can trace value through the systems

Then run experiments to do that. Possibly a “Barium Meal” ticket that passes through the current structure and illuminate the route these stories take, the time taken and the waits that the story is forced to experience.

Visualise that journey, so all can identify what we are seeing.

Undo: If the story runs into a cul-de-sac – Either politically or just due to the type of requirement it is, I would rewind, stop the trace and select a few more examples to trace.

Now at this point, simulation is hard becauise there are a thousand possible outcomes.. but lets keep playing the game.

Let us assume we find there are actually not TEN systems on the value path – But actually 7. The three others are independent or valueless…

Now my next step would be can we take that into one team.

Goal – One team delivers value,

Experiments: location study, technological tools, team building, Agile coaching etc,

Visualise: The flow again and the various activities within

Undo: It is only one team being built – the others are still working in the legacy way, so this teams work can be unwoven if needed, and can be managed on independant management tools.

Now the first team will run into all the problems you would expect. People, Process, Practices, Principles, Product Technology and Politics.

So they act as a tracer bullet for the future teams to gradually roll online. Not as an example to be copied – That would be falling into all the anti-pattern traps of this entire article (spotify, cloning)! But as a scout or minesweeper to find all the pain points and problems – And then we can clear them for the following teams, so they do not impact 24 teams at once.

I can easily see the first half dozen teams all being “scouts” for problems.

As we evolved and emerge the teams, the need for large amounts of dependancy tracking dies, the need for heavy supervision tools fades. The tool set can actually stay fairly simple and flexible. Keeping our organisational muscles and tendons still supple… for future change. We don’t need JIRA or it’s like, because WE’VE NEVER NEEDED IT.

So this gives us a ScalING and ChangING models. Models that allow us to understand and surf that ever changing organisational landscape and allow us to bring more teams delivering value sooner. Whilst keeping light. Each feature/”rainbow” team delivers end-user value. With the exceptions managing their own lives. Delivering value independently of those core value streams.

I imagine in a real life situation there will be many many more smaller mikado mash-up steps. Many many more undos! But as a simplified example I think this works.

I have found someone else using Mikado with an organisational theme: You may want to look at their approach here:


Gosh I am so deep in now, I think I need to stop this article. I will drop another article next week – One of my older Agilifying Agile Coaches ones – Talking about community. Those internal and external coaching networks are going to be important to make this all work.


BTW if you have read this far – Tell Nigel the code “Destro” for 50% off his PunMastery book!


Feedback, Metaphors, Analogies, Short-cuts and Examples.

Today has been another interesting day. At the moment of starting writing this, I would call my emotional barometer “sad”, but if we engage the emotion wheel:

Photo via Instagram / @trainingsbyromy

Disappointed and Remorseful with a dash of Disrespected comes to the fore.

As a middle aged man brought up by an ex-military father, (and caring and practical mother), I didn’t leave my childhood with much capacity to communicate my emotions. These were at best primary colours (bad, sad, angry) and suppressed. I did not feel emotionally stunted, as much like an Ant does not understand quantum physics – I am not sure I had the self-awareness to understand the lack of nuance.

As such, and as I have grown and “matured” as an adult – I have found a deeper understanding and… more crucially. a deeper language. Helpfully assisted by the Emotion Wheel tool above.

So the tone is set, what about the content?

I often get feedback on my work.

Feedback is the breakfast of champions, but sometimes it is hellish lumpy and unpleasant.

If you discount it, you treat the opinion as unworthy. Who is to say you are the hero and they are the villain? Everyone is the hero in their own life story.
If you absorb it, you treat the opinion as true. Who is to say they are right and you were wrong?

Sometimes it comes at such an angle, that there is an easy answer and there is a hard answer. Though the easy one maybe wrong. Or at least sub-optimum.

Often it’s something in the middle, but the middle is hard.

It has been said that feedback is the voicing of the unspoken, (perhaps unagreed) and unmet need.

As a trainer and coach (but especially as a trainer) I try to adopt a stance that is humble, engaged, open-minded, constructive and very much low status. If you have seen me teach, you will know I try to dress down, I am very self-deprecating, I try to create a warm, fun and funny experience.

The reason I play this role – Is that it is me. It is not a character. It is who I am. However, I am also razor-sharp and withering, if the mood changes. Like The Doctor (https://en.wikipedia.org/wiki/The_Doctor_(Doctor_Who)) I may look like a fool, sound like a fool, perhaps even act like a fool…`

The thirteen faces of the Doctor

But I am no fool. Perhaps some miss that.

Today, I got some feedback for work. I was caught out by it, perhaps because of the timing and the style, more than the actual content.

Some content surprised me though. There was a comment on the use of metaphors and analogies. If you know me, you will know that I integrate myself, my experiences, my stories and my interests into the delivery of any workshop. This feedback was offered from an inclusion and diversity angle, that the use of older english/american anecdotes and idioms mean those from different backgrounds may struggle to understand what is meant.

Which on the face of it, seems reasonable and appropriately corporate.

Except, this really rankled with me. I was really angry/felt disrespected/resented that. Why? Surely that is a reasonable request to alienating language?

Let me explain. I feel that analogies and metaphors can rely on prior knowledge and experience. This allows them to work as a mental short-cut to a point of learning or revelation. To use these perhaps could be less fair to others. (Though I wouldn’t wish to go down that argument pathway too far, as you could end up with any word that had a prior or differing meanings being verboten, or language kept so simple we are allowed no words above two sylla….. )

If you get this meta-reference – It very much is a short-cut

Short-cut’s exist outside of analogies and metaphors. They can be drawn from our shared experiences. “Hey, how about that local sports team, heh?

But that is seldom how I use them. I personally and deliberately use examples. Why? Because then I can use that example as a story-telling device. Setting context, background (often ostensibly for those who have never seen or heard it – but really for all involved) and then using that story to reveal some truth. The context is all there in the experience. It may look like an analogy or metaphor… but the value is in the entire arc of the story.

Sometimes that story is a humourous one. Why? As Shakespeare said: “Many a true word is spoken in jest”. Myself and a couple of friends are speaking at Agile2021 exactly about the use and possible misuse of humour as a coach or trainer. We can use humour to sharpen, blunt, and approach topics it is hard to do other ways.

So as an example..

Darth Vader. A well known fictional character from a galaxy far far away and known across the world. What is he as example of? I often introduce him via a toy I have sat on the desk in front me. Sometimes waved at the camera.

Some laugh, some look bemused… and then I introduce him as a “seven foot cyborg with a breathing problem” and perhaps act out a little skit of him being generally threatening in his traditional passive aggressive way “You think you are being treated unfairly..”

So we have set the scene. We’ve introduced the character. Set up who he is and what he represents.

Authoritarian management. Scary bosses. Perhaps even that “Sociopath” in the office. You don’t need to have seen anything remotely connected to Star Wars to get it. It’s often funnier and more engaging when people do not “get it” straight away. The gradually revealing of the surprise creates engagement, understanding and rapport. As they go from surprise, confusion, laughter, understanding – And now we have a great tool to use in any further “authoritarian management” conversations. We have built a shared understanding, a shared example that we can all drawn up throughout the learning. An example that isn’t threatening or offensive.. unlike Dave from Accounts.*

*Dave does not exist. Sorry Dave.

Stand-Up Comics call that referencing to a past piece of material a “call-back” (https://en.wikipedia.org/wiki/Callback_(comedy)).

Thus, we can construct strong learning artefacts that are symbolic and memorable and use them again and again to explain and educate the rather abstract concepts of Iterative and incremental Product Development.

This has worked pretty well, all over the world for over 700 workshops.

So this journey of understanding leads me back to…


The point of anything I do, is not to spoonfeed someone material in a palatable form. It is to get them thinking. If you think your lack of understanding something is my fault as your teacher?

Well, you’re right it probably is.

But, there is a chance it may not be! There is a chance that this confusion or disagreement is actually part of what you are supposed to be experiencing.

I regard it as my job to make the discomfort as pleasant as possible – If that is not an oxymoron. But I must ensure there is discomfort. It needs to be Safe-to-fail and not just safe. You need to be able to fail. There are wrong answers and bad takes. I’d prefer you’d take them here where it’s safe, and not in work where it very much isn’t.

This takes me to luminaries such as Sharon Bowman (https://www.bowperson.com/about-sharon/) and her book “Training from the Back of the Room.” I do not proscribe 100% to all of her theory, but it does challenge you as a trainer, and courses created under these methods could challenge the attendee.

Looking at improv again – perhaps Yes, And… is all about taking ideas and building on them. That does require input and engagement in the right tone.

Or perhaps Bloom’s Taxonomy:

To understand that education is the use of the brain/CPU and not just memory/data. To be able to use these ideas you need to be able to do more than just memorise. To implement and interpret, you do need to… be able to implement and interpret.

Edward De Bono died recently. The father of lateral thinking. If one does not understand something, perhaps think. Perhaps think from a different angle like De Bono identified. And then if you are still unsure: Speak.

Because it maybe that lack of certainty is part of the point. Your uncertainty is the right thing.

Even if it is as simple as something as a cup of tea. What are the acceptance criteria for a cup of tea? Strong? Sugar? Milk? What if you don’t put milk in your tea? What if the discussion on whether the mucus discharge of a cow (i’m showing my preference here) should go in our lovely tea, is actually what we should be discussing and is not a case of cultural assumption from one culture onto another… or even more interesting.. what if that cultural assumption should be part of the simulation?

So on this learning journey, and when heading to deeper simulations, the need to assume positive intent, engage constructively and speak humbly is critical. Add to this pot-pourri a vital ingredient. Your intellect, and you can gain a lot. Think.

So, back to the feedback. This was to assist with the delivery of the same workshop for another team on Monday. How can I use it in a constructive, “Yes, and”… way? How can I assume positive intent, engage constructively and speak humbly and not be a hypocrite filled with resentment?

To quote myself:

Sometimes it comes at such an angle, that there is an easy answer and there is a hard answer.

The easy answer is remove all examples that do not translate across the world.

Though the easy one maybe wrong. Or at least sub-optimum.

If I do that, it will be hellish dry and abstract. So what is the hard one?

Explain an example more clearly? Would that help?

Or do I make it part of the act. I am an englishman and I will explain to you these quaint english things. After all bringing your whole self to work is crucial – And in a different country, maybe these ideas will seem cool and exotic. Much as in Lean, a lot is made of its japanese roots, perhaps I shall just embrace my experience with even more vim and vigor and translate that to the attendees across the world.

Often it’s something in the middle, but the middle is hard.

.. and I will need to take on the chin some of the other feedback contributions. I do speak too quickly. Especially if english is your very very second language.

…. (but here is the problem. I’m not sure I can do anything about that.)


Here is the funny kick to the end. If I was asked what I would be doing differently for the next workshop with the remote team I would have said… Speak slower, remove some of the cultural references and explain examples with a bit more depth.

But no one asked me.

I’d also extend the exercises to give them more chance to translate, annotate a few more points and cut some of the deeper content. The best person to ask for feedback is you.

The emotions I felt earlier today were Disappointed and Remorseful with a dash of Disrespected. The disrespected has already faded. Nigel’s little ego has headed back into it’s shoebox. Remorseful is one that sticks. I have revealed before that I am a people pleaser – https://www.coachingconfidence.co.uk/tag/geoff-watts/ – a trait I am working on to lessen. So when someone doesn’t have a great experience with me, I feel that deeply. It actually pains me.

Many years ago now, I had an old, grizzled project manager take me to one side after a course, and give me feedback that my stories are too long and have no punchline or call back.

I nodded with great gusto and thanked him for his feedback.

He had missed half the course because of a P1 emergency and missed… well, you can guess what he missed.

Sometimes with feedback you action it, sometimes you take it under consideration and then there is the times you just have to put it on the backlog.

If you know what I mean.


Collaboration Tools: 2021

A few months ago, I was asked to deliver a short workshop on collaboration tools. I enjoyed the entire process of creating the material, the research and the participation of the attendees. Then I put the workshop on the shelf, along with many others. And then…

As I am want to do, I was caught up in an online “discussion” on tools. Specifically alternatives to JIRA.

Jira is named after Gojira – The original japanese name for Godzilla. One of these is a gigantic monstrosity that destroys everything in its path… and the other is a big lizard.

You can see that repartee in the previous post. (I particularly enjoyed the last comment that said I was the worse agile coach in the world and they were going to buy my forthcoming book and burn it. Which means at least one sale so go me.)

Anyway, back to the other tools. I thought it maybe worth while turning that workshop into a little article. How little… err we will see.

This is the simple answer. You wish to collaborate remotely with each other, some form of interactive, rich functionality, simple to use online whiteboard, and some sort of strong and powerful video tool is needed. My favourites and the most popular at the moment are Zoom and Miro.

So why can’t the article finish there?

Because what does Collaboration actually mean?

“The action of working with someone to produce something.”

When people talk about Agile tools… are they talking about collaboration? Or are they talking about collaboration.

This is our first major hurdle. Bad actors using tools for the wrong purpose. JIRA as a management of teams tool. Offering traceability and documentation… and limited collaboration.

So firstly, if you wish to audit, trace and document – Do not misuse the teams and products planning tools to do so. You will corrupt them and the content within. Auditable lies are still lies. There are good products you can use to create this content. Collaboration tools should not be used for such things.

For evidence, go look at any JIRA installation, and note how disengaged the actual developers and value-add staff are from the Work breakdown aspects (HOW) and how unhelpful that is, and look at how the (WHAT and WHY) product breakdown is being captured – The Product Backlog or it’s equivalent is hugely overloaded with junk, out-of-date content and is impossible to understand or visualise holistically.

We need to use the right tools for the right jobs.

Enter: Excel (and it’s brethren.)

If you have large amounts of organisational process and noise then capture it in more appropriate forms. The MS office suite has been used for this for decades. Specifically Excel – Which is still the heart of many audit and reporting approaches.

But here comes the problem…

This is derived from an Article that Alistair Cockburn (Agile Manifesto Author, inventor of Crystal) wrote about Agile tools, almost 20 years ago, in 2004.

What is going on, and going wrong, is the attempt to use Technology tools for the wrong reasons (control, supervision) and to ignore the other crucial areas of collaboration and the tools offered within to discover the real problems.

(Then we would have to fix them… but that is another article.)

The overlapping of these aspects of tools is what maybe causing problems.

If we dive into technology toolsets. There seems to be three general themes.




Cooperation is where people have looked to tools such as Miro, Mural, Whiteboard, Lucidspark, Wikis etc.

Communication is the current king of kings, Zoom, and the other such as Teams, Skype, Facetime, Webex, Google Meet, GotoMeeting and the chat tools such as Slack, Discord and of course Outlook and her email siblings.

Coordination is when things have been dark in terms of process. There is a large range of actual software frameworks and tools to allow multiple developers to work together – And that vast list is only getting bigger. As a former developer, I am a fan of anything that supports us in building high quality systems in a collaborative manner. Git/GitHub, jenkins, BitBucket, even Basecamp etc – These all support us to a greater and less extent with the code.

But the Agile toolset that started emerging soon after agile started speading more widely – Those were all variations of Excel – but online with a range of imposed or semi-imposed process management practices on top of the work.

As time has gone on, tools like JIRA have picked up more and more optional process, making organisations heavier and heavier. Slower and slower. And bad coaches enable this vice.

But why? Because these businesses are not Agile. These leaders are not Agile. They want the workers to be Agile. What they frame as coordination, is actual control. What they frame as alignment, is actual obedience.

But there is a light at the end of the tunnel. Much like JIRA et al have crept away from supporting teams, to suppressing organisations… so have the online whiteboards. Those murals and miros and surfaces have been enriched with options that allow them to become what we have always needed – Mass accessable, flexible environments for people and teams to work together. Genuinely AGILE COLLABORATION TOOLS.

So what has held us back? It is some of the other aspects that leaders, managers and coaches are not doing their jobs on.

Direct quotes from Alistair Cockburn himself.

Collaboration requires a healthy, constructive environment. Some find the word “safe” to limiting – But safe to me doesn’t mean a lack of challenge or conflict – But that we are secure with that level of discussion and disagreement. The coach/facilitator/ScrumMaster are key here. To create this environment and (as facilitator means) “to make easier” for the teams.

How to make easier for the teams? That leads us to Physical tools:

More from Alistair

As Alistair says above. We need tools that assist our thinking and work place interactions. In the last few years this has expanded brilliantly, bringing the sense of the physical to the virtual world. And visa versa. Whether it is the sets of pre formatted planning tools – to add professionalism and a bit more rigor to the traditional index card. (We did this back at BT in 2006 – I even wrote a paper for the ScrumAlliance on it), and the online whiteboards available as touchscreens – Bringing those online boards back to the physical world as well.

Physicality can bring creativity. See Fran O’Hara’s, the visual facilitator, work below.

Visual facilitation brings a greater sense of narrative and structure to a meeting… and a message.

And this takes to the heart of problems with Tools.

“To err is human, but to really [foul] things up takes a computer”

Imagine the Tool is a computer, and the work you are doing on it is a program.

Is it well written? Structured? Organised? Having a faciliator is crucial… but what are they facilitating? 

The key issue is that automating terrible processes leaves you with terrible automated processes. JIRA is cursed with these terrible, anti-agile ideas encoded or built upon it’s bug tracking hide.

The tool should not be doing this heavy lifting. It should be lighter, and these processes should have both the contextual flexibility and discipline and rigor they need.

So in the world of Collaboration Process tools, we need to:

Sam Storm posted a nice message about this that I have lost the link to….
Set clear workplace agreements and as a team ensure we adhere to our agreements.

This is why ScrumMasters exist – to act as rather disciplined enablers of these agreements and facilitators of these events and methods. JIRA makes a terrible ScrumMaster.

And in this remote world, you may want to split responsibilities in any complex facilitation event:

I do this with online training where possible. Having that support was incredibly reassuring when online education was new.

If we think more deeply about this, there are a range of facilitation tools from Kaner et al, and many other that we can use to better enable collaboration. For this workshop I went back to my past. Not as a trained and certified Facilitator, but much further back to my childhood… when my parents were alive and Radio Amateurs. Sometimes known to people outside that world as Radio Hams.

From the world of RSGB and their radio club SBARC (South Bristol Amateur Radio Club) I drew from the Radio Amateurs code of conduct – And found many patterns we can and do use in building collaborative spaces.

All these patterns can be used to help remote teams collaborate within and with each other. Creating that trust and rapport will then allow us to not even need to contemplate outside reinforcement and performance tracking.

Next is the final aspect for PROCESS for me and how it leads into the next area of collaboration tools…

Agile and Scrum in particular are experiment-led models. You create, you deliver, you learn, and you adjust. Inspect and Adapt. To do that you need Inspection, Adaption and Transparency. To have visibility you need to have safety. To have safety, this means you need to be changing how you think from Fail-Safe to Safe-to-fail.

Thinking Tools are the heart of an Agile experience. More than any method. If we can catalyse that thinking approach, we are well on our way to changing how we work and how we succeed. JIRA and it’s ilk will never do that.

I always enjoy when Paul Goddard (author Improv-ing Agile teams, @paulkgoddard) posts this image. Which he does. Frequently.

The classic improv approach of Yes, and…In the discussion of JIRA we recently had, we had very “Yes, but” negativity from coaches who should be more open minded and interesting in learning and discovery. I’ve spent an age playing with some of these large enterprise planning tools – And I include the old ones from before Atlassian! I can’t say it brought joy – but it was an experience. Paul taught me (probably in a pub) that Everything Is An Offer. Everything in improv is a opportunity to build upon. And with that “mindset”, it makes life a whole lot more interesting and wider. What can we do here? How do we take this forward?

Listening is a powerful thinking tool. A critical tool if you are going to genuinely collaborate and not just impose your strong will onto others. As we have seen on social media, it is easy to hear what isn’t being said, but even easier to hear what was never said. Your perception filter has a bias… and that bias is influenced in all the wrong places by your previous bad experiences.

So learning to really listen… without it, it doesn’t matter what you write, or track, or supervise.

And finally to the environmental collaboration tools. For remote organisations and people, that has meant the discovery of the tools of youtube streamers!

Good mics, Good lighting and a good camera are essential if you are going to have any form of high bandwidth communication with each other!

I used to work for a telecommunications company, so I am probably biased… but pick up “the phone”. Talk to people. See each other! Don’t just send tickets with limited information and even more limited context. Build relationships within and outside your team. Communicate, don’t just drop a mass email. Think (like radio amateurs) of the quality of your transmission:

It isn’t just the technology of course… The most popular language in work is bullshit.

And also think wider than yourself. This next picture is from some work a fellow Certified Scrum Trainer, (and friend), Richard Cheng did. What should your office be laid out like if you are to genuinely collaborative.

And what does your current home office look like? Is it fit-for-purpose to collaborate?

Do you have these? Have you ever had these? Yet I bet you have a JIRA login and password.

And now let’s step back. Let us look at the organisation from a higher level… How do teams of teams collaborate? How do those clans collaborate? How do these internal united nations collaborate?

As Geoff Watts (@geoffcwatts), author of ScrumMaster, ProductMastery, TeamMastery and PunMastery (with Paul Goddard and I) says:

“People forget their principles when they scale”.

Look at your teams of teams? Are they one big product? or merely a league of seperate products welded together in a feudal organisation? The only commonality your King?

Or worse, are those teams merely producing code or horizontal technical lumps for other teams to consume. Can anyone really deliver value, outcome or even impact? Or is it just busyness or output?

You see, some of the most important environmental collaboration tools are:

  1. Empowered, engaged and collaborative Product Managers
  2. An allied network of Humble, Caring, supportive and trusting Servant-Leaders
  3. Actual value delivering product “feature” teams filled with cross-functional, diverse secure and protected talent. Ideally co-located. Emotionally and intellectually if not physically.
  4. Simplified and slim management structures.
  5. A technology ecosystem that is mallable yet not manic, flexible yet not flimsy. Modern and forward looking, but real and realistic.

If you map some form of software development lifecycle management product onto the old structure, you will just get at best mild pain relief for leaders, agile theatre of middle managers and more pain for the poor value add workers.


One form of process or product mass applied across all different teams is a recipe for disaster. Just because it worked for Spotify doesnt mean it will work for you. Just because the feature is activated in your version of JIRA, does not mean it is even a good idea for anyone. (See this article for more information: https://nigelbaker.wordpress.com/2021/01/28/the-nigel-scale-2021-context-is-king/)

And the more complex you make it….

Semi Obscure eighties Star Trek reference for you kids out there…

So to wrap up, The collaborative technology agile tools you need in modern organisations are:

At the start, the installion offers seemingly quick wins, “We rolled out the Agile tool in Q1..”, but rapidly you eat up those wins and become trapped in the very source that was originally filled with help. You become expert in your own monstrous JIRA installation, (wisdom worthless to any new employer) in an organisation ruined by it.

But all of Alistairs identified areas of Agile tools overlap. And that overlap is what has caused problems. Because we’ve tried to fix THINKING and ENVIRONMENTAL fundemental problems with TECHNOLOGY and PROCESS.

Ask yourself this, what was the question that led to the answer.. “JIRA”. You will find that you will need to take the time to ask yourself a far better question.

At this point, you rename yourself Jira coach… or go change the organisation.



A linkedin Comment about JIRA and “Think”.

This is a new record. I have a linkedin comment so large, I needed to host it here.

I will add some context around this comment later:

EDIT: I said I would return! I have tried to pull out the relevant content from the original Linkedin thread. There are other good posts in there so if you can find it, it maybe worth the read. I’m not linking to protect one of the posters, as their behaviour goes…err… “downhill”. I am assuming they’ll delete it – but if not – let’s give them another chance.

So Jac starts with a good point. You can’t just stand on a position of “Anti-X”. If have to offer an alternative.

So I did. TBF I thought that would be the end of the matter. Miro (other whiteboard products are available) and Excel (Not many other spreadsheet products are available) is a common combination used by us all for the past innumberable years.

However, I underestimated (or overestimated) the situation…. So my response is below. Feel to read it in a world-weary yet resigned tone.



Edit: If you would like the tl;dr version: Individuals and Interactions over processes and tools. Working software over comprehensive documentation.

There are so many ways to take this “conversation” forward: Let’s try these: 

Firstly, snark-as-a-coaching-stance is a bold strategy. I would be interested to see how that turns out for you. If I were coaching you (which I am not), I would recommend avoiding that as it can have a detrimental effect on your interactions with others and how you are perceived. As an Agile Coach you are supposed to approach a subject without personal snipes, as those sorts of comments will be noted and remembered long after your good work is gone. I have experienced this and would not wish the same on you. 

Secondly, it seems you have read snarkiness into my post saying “think”. I would suggest you also “think”. Consider what was meant. Consider what assumptions you are making. What emotional reaction you have assumed and thus emotionally replied to.  The answer to the original problems are in my original post, if one merely applies some critical thought to the situation. If you would like me to spell it out more explicitly, I shall – but with shame that you cannot do it yourselves as proclaimed senior Agile people.

[PMO Director] is wrong. Fundamentally wrong. Why? 

One, (to keep it simple), Tools like Miro cover the gaps that Excel has, the gaps that were mentioned as problems in the earlier post. So the answer is right there. Excel AND Miro. Not just one or the other. 

Two (the more expansive and powerful answer) because I have seen Excel and Miro (Hell, even physical whiteboards) pass the highest levels of CMMI and Audit in some of the biggest and most bureaucratic organisations on earth. This is not some outlandish claim on social media. This is not a new or controversial opinion. These facts have been tracked in the Agile community for over a decade (probably nearer 15 years) by dozens if not hundreds of people and organisations. So much so, there now exists Audit offices *using an agile approach* to audit. We solved this very problem in 2006. 

The fact that there are people with senior Agile positions, who seem not to know this, is very sad to me. But as many know, I have written, spoken and presented on that phenomena for many years. 

Three, everything you are discussing (multi-timezones for teams, et al) falls under terrible organisational structure and design. You should be working to remove such fundamental problems, and not enabling with an overly complex bug tracking tool masquerading as some sort of collaboration vehicle. If JIRA is the answer, you are asking the wrong questions. *Think* about all the other aspects that are affecting this. Most JIRA usage at the moment is not for audit purposes but because organisations have structured themselves into component based, inventory production systems with little to no team autonomy, and then use SAFe and JIRA to ensure compliance and “alignment” (in reality “obedience”) This is a MINDSET/Culture problem and an ENVIRONMENTAL problem. Which one is trying to answer with PROCESS and TECHNOLOGY. You are answering the wrong questions. And making a bad situation worse. 

My (perhaps futile) hope was that as more experienced practitioners as yourselves would be able to spot that, given some reflection. Which is what coaching-as-a-stance is all about. You have the answers. You need to be able to unlock them yourselves. “Think” is a Socratic question. Reflecting your own knowledge, wisdom and intelligence back onto the problem. Some do not like what they see in the mirror. 

It strikes me that the snarkiness and follow up comments to that Socratic question shows a reaction that actually would be interesting to coach. That visceral response is often a case of some underlying perhaps sub-conscious aspect being triggered. It would be fascinating to find out more. 

Who knows? I am not your coach so this does not consist of a problem for me. What I would say is your ignorance does not constitute impossible. There is a huge difference between Can’t, Won’t and Haven’t. 


Postscript (13/07/21): I note some edits have started appearing in that thread with questions and statements being previosuly made being post altered after replies have been submitted. I find that “shifting” remarkably.. “shifty”?

Now the goal posts have moved a second or third time and it is now about Data security and goverment departments only allowing data to be hosted in the UK. As an argument that is interesting except for a couple of small things:

  1. They use Miro in these goverment departments.
  2. You store sensitive data not in Miro.
  3. You can buy other whiteboard products that allow onsite hosting.
  4. There is a big leap of logic between “must store data locally” to “use JIRA”.
  5. There are many great data security products that you can use that do not pretend to be Agile collaboration and planning tools.
  6. None of this will change anyone’s mind. Alas, their mindset is fixed.

Epilogue: And I am very proud of myself for avoiding any form of “Do you know who I am?”

Agilifying Agile Coaches: Part 4 of 6 – PURITY vs PRAGMATISM

The two devils… er ducks on your shoulders.

Nigel2021 here! If ignoring a blog for four months and then posting four times in one day, is wrong, then I don’t want to be right! Here is another cut and paste from Nigel 2018. Let’s see what that skinnier but much stupider Nigel has to say about the three P’s. Purity, Pragmatism and Passion!

PURITY vs PRAGMATISM: Dissecting The Core Of Agile

We are now half way through our journey. We have explored a variety of angles into the practices of Agility. I now wish to turn that lens onto the core of agility itself.

I finished the last article with a warning about methodologisation. The idea that we can know all about the handling of a problem in the complex problem space is, by its very nature, the very behaviour that spawned our traditional waterfall processes. If we adopt this thinking in the Agile space, we will begin to reinvent the waterfall wheel. It may seem safe. The faux certainty may make us more content, but it will lead us back to from whence we came.

This is a huge danger for us coaches. We can easily fall prey to the very behaviours we claim to hope to help change. Frederich Nietzsche said it best:

“[You] who fights with monsters, should look to it that [you] do not become a monster. For when you stare into the [abyss], the [abyss] stares into you.”

You can substitute for abyss the word waterfall, or enterprise.

My favourite was this quote from twitter:

There is another side to methodologism as well. By taking apart an idea and analysing it in detail, you may lose site of the overall experience. I have heard it said that “Humour is like a frog. You dissect it. You kill it.”

The trouble is, the spirit of AGILE is like a frog. You dissect it, you kill it.

So what has this to do with core fundamental practices?

That is the subject of this article. “PURITY vs PRAGMATISM: Dissecting The Core Of Agile.”

As a scrum person and Certified Scrum Trainer, I am quite strict about the base core practices of Scrum. For one simple reason. I have found through experience that keeping discipline around those patterns has helped me and others deliver valuable products more effectively and with more success that when we have adopted those patterns in a weak or piecemeal fashion. In that sense, I am a purist.

The trouble with the phrase purist is that it can give people the wrong idea. It brings to mind the zealot, the fanatic, the person unconstrained by real world concerns.

They may prefer the term pragmatic. “We want a pragmatic coach who can help us make this work in the real world.”

I adore the phrase “the real world”. As if all Agile coaches live in Narnia! I used to lash back at this phrasing… until I realised by over reacting to it, all I did was give them more evidence that I was indeed the zealot they feared.

Then I had a realisation. I am pragmatic. I am a pragmatic coach.

How? Well I could argue that the last three articles have all been about pragmatism. Taking and adjusting good practices to suit teams in different contexts. Understanding the inherent agility in Agile.

But it’s more interesting than that. The term pragmatism means:

“An approach that evaluates theories or beliefs in terms of the success of their practical application.”

This is exactly what I have done with Agile and Scrum since I started “doing” it as a developer back in 2003.

You see, this is a false differentiation. It does not have to be Purity vs Pragmatism.

It could be Purity Through Pragmatism.

So, I will admit I am a FUNDAMENTALIST on the FUNDAMENTALS.

What are those fundamentals? For me, it is the Agile Principles over particular practices. (Though, as a Scrum person, I think those practices require great discipline, as well.)

The Agile Principles are NS1. The absolute core that is often overlooked. The Agile Manifesto is too high level to really be implemented beyond a mild cultural sensation, but the principles have teeth. And they bite.

When people water down Agile, they start there.

Let me introduce to something produced by an old colleague of mine, Kerry Buckley (@kerryb). He was inspired by a range of people including Ron Jeffries, one of the creators of Extreme Programming and one of the seventeen writers of the Agile Manifesto:

THE HALF-ARSED AGILE MANIFESTO. (http://www.halfarsedagilemanifesto.org)

This is a gigantic issue across industry. I cannot think of a company where they are struggling because they have been too disciplined in their Agile values, principles and practices.

I could start a list of companies suffering from a half-baked Agile approach today and would be still reciting it next week.

Watering down Agility does not make it stronger. This is not homeopathy. The placebo of visual walls and post-it notes will only carry you so far.

Depending on your particular flavour of Agile you prefer, there will be other practical things falling into this categorisation. Visualisation and minimisation would probably be in a Kanban fans box. Test Driven Development, probably in an Extreme Programmers. But those agnostic types? Those that follow no flavour? This is where we (coaches from that space) have to be careful. It is too easy for all of us, for our principles to falter in the face of pressure, pain, pleasure or pennies.

So we are going to need to be stiff. Really stiff on those values and principles. We are going to need to be unwavering in those. Remember as an Agile Coach, you have an agenda. Agile.

You are working to help them transform their own personal world of work through Agile.

I have seen arguments made by people far more successful than me, about how “Agile isn’t the destination, but an approach. A mindset to take you on a journey.” True.

I have seen others use this to say that this means they are not really an agile coach, but more of a leadership/business/improvement coach. Maybe.

My fear, though, is treating Agile like another thing or widget or process is doing it a huge disservice. It is a big deal. It is a vast culture change for nearly all organisations. It is a huge structural change for anyone taking it seriously. “Flattening hierarchies”, is a euphemism for large reduction of middle management roles. It is a big thing. If it is just another tool in your toolbox, then you are not being pragmatic, you maybe being mercenary. And the one thing we must bring as a coach is passion.

You see that is often the real differentiation. Passion vs Cynicism. The one thing you can bring as a Coach is positivity. An enthusiasm. It requires no training or certificate to be an engaging and upbeat person. This makes you very different from a traditional life coach, for example, who is supposed to keep a constant neutrality.

So those issues brought up by methodologisation, corruption of the coaches behaviour and the deconstruction and thus destruction of the fundamentals of Agile approaches and Scrum? They can both be mitigated by a strong focus, deep appreciation and discipline around the twelve principles of Agile.

Be aware though, we still want to ensure these principles are not treated like religious texts. We should as coaches be able to build them with a team from first principles. Whilst that maybe overkill in some situations, having the ability to do so when needed will increase buy-in. I often find I need to do that with more senior management. Get past the jargon and back to basics. Then build.

So education and coaching of the principles can be done through different stances, whilst perhaps reinforcement or defence of those principles can be done with more direction if needed.

And that’s easy right? Well, let’s look at some of those principles:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Do you do that? Or are you dislocated across the globe? Are you looking at the word most and thinking, “Well, actually, it doesn’t preclude distribution…”

Or “The best architectures, requirements, and designs emerge from self-organising team” and you are thinking “Well actually, it says best, and whilst I agree in principle, my product owners will still be writing all the stories..”

Or even “Business people and developers must work together daily throughout the project.” And you are thinking “Well, actually, we have ex-business analysts as proxy Products Owners. You see the word must could mean… err… Maybe….. Damn.”

Beware the Actual Well. Voltaire said: “Best is the enemy of good.”

Well, Nigel says: “Clever is often the enemy of good.”

I’m sorry if this is harsh. I’m just passionate about principles. They are bigger and harder than many realise. Let’s work on them with a bit of passion!

Being positive and passionate does not mean you have to be naive. There is an area we have to bring not only pragmatism. But a dose of cold dark reality.


Making real organisational change happen is a messy, difficult, dirty affair. It is the world of politics, and not many ScrumMasters or coaches are equipped for that challenge. There is no point us coaches being iconoclasts like Leon Trotsky (https://en.wikipedia.org/wiki/Leon_Trotsky) cursing the system from the outside. We need to be deeply wrapped in the experience, without being corrupted by it. 

I took two great pieces of advice on change from the autobiography of Tony Blair. (https://en.wikipedia.org/wiki/Tony_Blair)

Now whether you liked him or hated him, Tony Blair was one of the most successful British Prime Ministers in modern times. He came from a left-wing party but portrayed himself as a centralist on most topics. He struck me as an excellent politician, with all the positives and negatives that word infers.

The first bit of advice I have followed, is his belief that “one should never confuse strategy with tactics.”  He would (especially around the situation on the island of Ireland), often do very machiavellian acts, (such as claim that each side of the conflict wanted to speak to the other, to get the other side to admit it would speak to them.), but he would do so with the positive strategy of trying to bring peace. A far greater good. Now as a Coach, I think these are two extremes examples, but the overall metaphor does hold true. We need to mentally separate acts we take in organisational change from the aim of the change. There will be tactics that may not align 100% with our intended direction in the long-term, but are necessary for now, and we should not confuse them for the end goal. This is not being flexible with principles but with how we get there.

His second piece of advice, was around the concept of goodwill or karma.

Blair broached the idea that every Prime Minister (elected leader) has a certain amount of goodwill or karma with parliament, with their party and with the general public themselves when they are elected.

Many leaders waste this goodwill, frivolously. Later in their leadership, they have a great need for this goodwill. They need to use it for some great and important change. And it is all spent. The leader is in trouble.

When we think of “the cost” of organisation change, we often think in cash money. Never in goodwill. All ScrumMasters and Agile Coaches (and organisational leaders!) have a bank of goodwill they can draw upon. Many go overdrawn pretty quickly and expire. Whether resignation, firing or sidelining, they are no more. They are an ex-coach. Coaches need to nurse their bankroll and build it up. Carefully and intelligently. And then spend it wisely. 

I have a big concern that the way many Agile Coaches are employed, has a huge effect on goodwill. “Low level” team coaches are employed as contractors for six month “gigs”. In this model, we are given little reason to care about genuinely improving people’s lives. We may be interested in keeping our day-rate. Mercenaries do not incite great loyalty. Perhaps the model we use to engage could be destroying our ability to engage? We are in checkmate from the first move? Your level of goodwill starts low, lacks the structural ability to go up in any sustained way and the clock is ticking…..

Again, this is where we have hard choices to make. Years ago, I was given the advice that the price you charge has a huge influence on the huge influence you can bear. If you charge more, people take you more seriously. That’s easier said than done.

COMMERICAL WARNING –Whilst you may not believe it reading these articles, I am a capitalist not a communist. I have personally tried to influence this troubled world of organisational change by putting together some online training videos.

Enterprise Agile Transformation For Coaches.

Available for purchase here: (https://www.frontrowagile.com/courses/enterprise-agile-transformation-for-coaches/overview)

The videos consist of one or two grand philosophies, but mostly a range of practical tips. After all, Rome was not built in a day!

My philosophy was to try and lower the cost of entry into some of that knowledge, whilst still commercialising them and making some money.

After all, even the most passionate coach is not a priest. This is a job, and requires pay.

That is being pragmatic! 🙂

So, over four articles we have visited a range of ideas, concepts and models on putting some agile into the phrase “Agile Coach”.

For the last two articles, we are going to visit the other word. Coach.

See you all next week for “Get By With A Little Help From My Friends.”

Here is article 5: https://lnkd.in/d4N9jsd

Missives from Messages: Story Telling, Story Telling

This post is based on another letter, this time on the subject of “preparing for talks”, and “How do you find out so many memorable sentences? Your entire talk was made of 33% sentences quotable verbatim”.

Again, the context here was I just delivered a presentation on Agile Anti-patterns…. and since it was delivered on Halloween, I had to give it a suitably *delivish* twist!

Please watch this first!

Please allow me to introduce myself, I am an Agile Coach of wealth and taste…

The subscriber to the letter wanted to know how I go about creating these things. So, to my reply: I’ve added some extra commentary on this presentation specifically, as an example.

Up to this point, I had never analysed how I produce something.

  1. I would start by saying I am very scrummy about it. I start with an idea normally – A high level concept or vision.

The original idea for this started back in 2015, when I was offered a slot for presentation at a Scrum User Group around Halloween.

My original pitch:

“Sympathy for the Agile Coach.

Please allow me to introduce you to my co-presenter, Louis Cypher, MBA, PhD, Kanban Trainer, SAFe consultant, Six Sigma Super Black Belt, Scrum Study Certified Trainer, Certified ScrumMaster, PRINCE2 Practitioner, OFG Certified Architect, PMP. He is an Agile Consultant and Thought Leader of wealth and taste. He has been around a long, long time and you’ve probably met him in some form or another. A couple of days before All Hallows Eve, He will take you on a journey of his personal experiences of Agile and will show you the nature of his game. He will reveal a range of fantastic opportunities and ideas to take back to your teams and take your career to new heights.

And all it will cost is your Agile Soul….”

I had the idea of doing some sort of anti-pattern presentation, The presentation will be about dodgy agile coaches and a mix of dodgy agile anti patterns that initially sound OK but actually suck and the seven deadly sins – Things like putting JIRA at the heart of your agile methodology…

2. I start creating a rough skeleton and then just iterate iterate iterate.

I do put a lot of hours in. I think about a lot of things all the time, and if something comes to me, I add it in. The presentation grows over many weeks. I add a bit. Walk away. Add some more. Think about it. Think about it in context. Add a bit more. Walk away a while. It’s like an oil painting, I visit and revisit.

I am a magpie in that I pick up phrases, little bits of language, ideas etc and I personally like musical lyrics, poetry etc and stand up comedy and thus I try to incorporate sharp phrases and slogans.

So for this presentation, I asked the Certified Scrum Trainer and Coach community for any dastardly anti-patterns they had seen… and boy, did I draw upon those anti-patterns! I added my own patterns I had come across, and also tried to use humour to sharpen them. For example, comparing velocity is a huge anti-pattern, so I joked about winning the race of velocity being key – And that links into the famous “Escaped Lion” story.

As one could tell from the original presentation,


I used standard corporate cheesy slideware, and gradually metamorphisised the fonts and colour into a black and red font… dripping blood! The original idea was they would gradually realise this is not true rather than give away the twist at the start. I referenced the eightes horror film Angel Heart, and eventually….

3. Keep iterating.

Just because a presentation is done, doesn’t mean it is done. The video above is probably the third major version of this. The second version was a complete graphical change – With slideware is now based on a style I created derived from John Carpenter’s preferred titles from his films like Halloween, The Fog, The Thing.

That was a version that ran at the Dublin Scrum Gathering that was so popular it got a standing ovation!

The twist idea disappeared – (Though I was told a few attendees in Dublin didn’t realise!)

This particularly one was always going to be prefilmed and shown as a video for the ALI2020 conference… so I could play with the form even more. I completely rewrote about 75% of the workshop, and added a huge theme of Scaling Methodologies. So it’s kind of a sequel/kind of a remake.


But with filming, it opened up many more options – Going from theatre to cinema – Options I couldn’t utilise fully due to constraints such as money, time, ability, skill and talent…. but as you can see I tried, and god loves a trier.

So evolve, evolve, evolve. Play with the medium you are working with.

3. Be Sharp.

I try to get my key lines as sharp as I can. That is where twitter has helped! I have read comedy stand-up books, improv books, writing guides, (Unbelievably, certain sounds are funnier in english than others!), finding a strong turn of phrase does help. I often cheesily offer awful alliteration, or sometimes reverse what I say, and say what I reverse. I do think there is an element of poetry to what we do as story tellers… else I could just read wikipedia. And if you can find an elegant turn of phrase.. go for it.

4. Yes, But there is a huge improv element to the work.

Playing Lucifer, for instance. I did not have most of his reactions pre-planned beforehand. I had a couple that I had used before. “Hand/Mince” but most of what I was trying to do, was to get into character and feel it and believe it and then say what he would say in that scenario. There was no script for the performance, there was just some high level bullet points. As I workshopped it more, more ideas came out and could be incorporated.. but alas, unlike a real play – I only get to perform this once or twice. So carrying that memory from presentation to presentation is HARD.

Remember, we are all acting when we present. It’s just most of us a pretending to be competent Agile Coaches! I find I can (normally) be more myself on stage these days, as I have access to those improv techniques and “Yes, and” mindset. This may not make any presentation better, but it makes me feel better ready for the presentation.

5. The Quest

Think of the journey you are going on together. I knew the journey Lucifer had to go on and so made sure I didn’t start to extreme – Because if you start extreme where does it go from there? He starts happy and sly, gets hugely excited about his new scaling approach and delights at the end in his victory. He has won the war and you didn’t even know the battle had started. Starts off humorously amoral, moves into plain amoral and then finally arrives at evil. What quest do you want to take your audience on? Whats the start? Where does it go? What are the conflicts? What ups the ante? What is the climax? The epilogue? Without an arc, it’s just a series of pictures and text on slides.

6. Synthesis

Back to my magpie nature again – My mind is always fusing different things together for good and ill. This is why I constantly misuse or abuse words and fuse new ones out of old. I do similar things with ideas and that seems to create lots of unusual directions to go. Sometimes it works and sometimes it does not. Combining the layers of Dante’s inferno with a scaling approach is an idea with a loong history. At a company I used to reside, there was a joke that they had more levels of QA then layers of hell. Ho ho ho. But it turned out to be 1. They were referencing Dante – so I had to read all about that and learn – and 2. They were wrong. They had less layers. But adding that strangled anecdote and my brain fusing powers together, brought Dante’s inferno to the workshop.

7. Stagecraft

Finally, finally, I do have bits of “business” of stagecraft – that I have used and honed over the years – I often drop those in almost casually to help me move through a conference workshop. (BTW Stagecraft historicially means the scenery not the acting.. but I am using it as a synonym for acting here, as acting hints at falsehood)

If you watch a comedian on youtube on Conan, Letterman, Tonight show, you will often see “spontaneous” bits of theatre pop up again and again! That bit of “business” is used again and again and again. Having those tools in your toolbox allows you to better manage an audience or situation. I have often used audience participation to build rapport and engagement if I feel my material is getting too dry or long.

“Who here uses User Stories? HANDS GO UP.

“Who here abuses User Stories” LOTS MORE HANDS GO UP.


It doesn’t just have to be humour. As in the previous blog post, it could be analogies, it could be examples, it could be cool little sayings.

8. Polish it up... and kill your darlings

Finally I make it look pretty. I do this last so not as to waste any time making beautiful content that gets cut. I often at the end find myself removing excess content to try and get back to the key premise of the piece.

… or sometimes that is the moment you FIND the key premise of the piece… and it wasn’t what you were expecting when you started it! Finding the narrative arc of the presentation, the story being told. Sometimes it is evident, sometimes it needs to be pulled out. For instance, I did a presentation on uncertainty in which I came up with the title “TBA-TBC-WTF” before I had any idea of content! So I used that uncertainty as a funny narrative driver!

I go on a journey or quest through a presentation, so it’s not just a random collection of ideas or slides. The devils narrative this time was not to try and seduce you to his approach – (That was the 1st presentation he did – Trying to take you to the Dark Side) but instead to celebrate and delight in his success. You are all doomed and you just don’t realise it yet.  That connectedness helps the presentation flow, assists with the transistions between content.

It is funny that Art is in the eye of the beholder. Sometimes the story you thought you were going to tell, isn’t the one you end up telling… and sometimes the story you tell, isn’t even the one you they hear.

So I rehearse. Oh not out loud, but in my head. On public transport. Waiting in an airport. On a toilet. Eating my dinner. (not at the same please) but playing those ideas and the flow over and over in my head again and again.

I then forget all that during the performance – But occasionally one or two of those ideas stick and pop out my mouth. The rest is improv and cheekiness.

And that’s the beauty of the narrative form. Enjoy!


OMG I forgot to tell you about what the “top secret project” actually was!

It’s this:

Punmastery! Agile Jokes for Agile Folks!

This is how bad lockdown got. Geoff, (www.inspectandadapt.com) Paul (www.agilify.co.uk) and myself (www.agilebear.com) got together and wrote a hilarious/toe-curlyingly bad* Agile Joke Book!

*delete as appropriate

It is available on Amazon in all nations, and if you buy it, I make one pound. If you buy a million copies I become rich.

I think we all know what we need to do. Start your christmas shopping early… after all Aunt Agatha needs a book that contains the punchline “cross-functional beans”.

It’s backwards – I don’t know why, but hopefully the jokes are funnier.