Why you MUST apply your thinking OUTSIDE of work, INSIDE of work – Scrum shouts Empiricism!

We deal with uncertainty all of the time.

Everyday in our lives, there is a ALLOT more uncertainty than there is certainty.

You don’t think so?


Is that train ALWAYS on time to get you into work?

Are all of your peers and co-workers 100% sure to be in that day, no illness, no unexpected issues?

Would you bet your monthly salary that your favourite sandwich will be available for you that lunch time?

Look, most of these things usually go our way.


There is always an uncertainty that we are living with – the scale of uncertainty of course varies.

In software, we’re talking about ALLOT of uncertainty.

And there lies the problem with Scrum adoptions & transformations.

The misunderstanding that senior managers have of software development.

If time & budget is agreed but something changes, all hell can brake lose.

“I thought Scrum was meant to fix this”

“I thought Scrum was to make us get what we want”

“What do you mean Scrum doesn’t stop things from changing”

These are some of the misunderstandings I encounter all of the time with Senior Managers.

So before I even talk about Scrum, the first thing I do is educate on empiricism.

If we are using predictiveness to manage our projects then you may as well forget about Scrum.


“The right process will create the right outcome. The wrong process will create the wrong outcome” Sutherland

So, let’s talk basic empiricism.

Empiricism is when there is a lot more that you don’t know vs what you do know.

So, you do a little bit of something (sprint anyone?), take the results (show & tell sounds a good place for this ūüôā and feed it back into your plan (ah yes roadmap management)

That’s what Scrum does right?

It allows you to keep empiricism alive through it’s events & mindset.


Before you talk Scrum to the head honcho – you need to educate on empiricism.

If you are a senior manager reading this, or if you are any kind of change agent that is trying to push any agile approach (which all are built on empiricism since we’re delivering software) I would like you to answer the below questions.

And answer them honestly.

I want to see how you accept empiricism in your every day life – but are inconsistent when it comes to your work place.

Go ahead & answer – I am willing to bet my months wage that 2 out of 3 answers will be option C. And if not, you’re lying ūüôā


You’re feeling lazy and peckish so you grab some pre-made Aunt Bessies Lemon Drizzle loaf cake.

Baking tray, check, crack a couple of eggs, mix & as per instructions “Bake for 30 minutes”

Before you serve it, check that the centre  of the cake is cooked.

If the centre of the cake is soggy after 30 minutes -which of the following options do you pick?

a. Eat the soggy cake

b. Throw yourself onto the floor & cry

c. Let the cake cook until it’s ready


It’s Saturday night & you’re looking forward to watching your favourite movie.

The tv schedule states that it begins at  9:35pm, however the world cup is being played before the movie.

If the game goes to penalties, the movie may start later.

If the final goes to penalties & your movie has not started, which option do you pick?

a. Phone the bosses at ITV & complain

b. Throw yourself onto the floor & cry

c. Wait for the penalties to finish & watch your movie


You were preparing a meal & you cut your finger, pretty badly ūüė¶

The doctor tells you it should be ok, and healing time is around a week.

He also advises to keep an eye on it if it turns green & to come right back.

If your finger turned green would you:

a. Phone the doctor & complain yelling “You told me it should be ok you bloody liar!”

b. Throw yourself onto the floor & cry

c. Go back to the doctors & get it sorted


So we accept empiricism in our everyday life.  We have a plan, we do something, we see if that something is going to plan and if it is not we then take the best action we can.

Aka Scrum – we Inspect & Adapt.

So why are you willing to accept empiricism in your every day life but have a problem with it when it comes to software delivery?

Oh, was your reply :

“Because I am paying you for it”

Well, in that case I’ll dress up as Mystic Meg, supply me with a crystal ball & some tarot cards then yes….. you are right, money should solve the problem.

Right process, right outcome (empiricism)

Wrong process, wrong outcome (Predictiveness)


How to use Peer pressure to get your Scrum team back on track!

“I don’t know why he’s playing so rubbish Jem”

“It’s weird, he’s not performing at all – his heads not in the game”

My brothers captained his local football team for a little while now, and just like a ScrumMaster he’s someone who wants to do all he can to get the best out of his team.

He continued telling me about one of his team challenges…

“I told him exactly what I thought, I give him honest feedback but I have to say, it’s not making any difference”.

It made me think about my day to day role.

How do I, as¬†a ScrumMaster handle ‘bad’ performance or someones ‘head not being in the game’?

“What about the rest of the boys? Have you said anything to them about his change in performance?”

That was my instinctive reaction.

“Nah, that’s my job right ?”¬†he replied.

How interesting.

Was it just the captains job to point out someones ‘bad’ performance?

Or should the team show some collective leadership to sort out any challenges they may have?

See for me,  if I notice a a change in player performance or morale, I have asked the team what they are doing about it?

Before I push on.

Let me be clear on what I regard as ‘bad’ performance ¬†or someones ‘head not being in the game’.

-People not respecting the Scrum events

-People turning up late all of the time

-People not  talking up about risk (i.e stands up, if that story went up in complexity you need to tell us like yesterday)fe

-Peoples morales going down.

Basically everything to do with STOPPING the team from going towards Scrum success. (Working as one organism, doing all they can to deliver their Sprint goal, not managing risk effectively, not sticking to team commitments and just overall screwing with the Scrum framework)

I ain’t talking about a developer who is struggling with the challenges of learning TDD, or a developer who misunderstood a requirement, or ¬†a developer that isn’t the sharpest guy when he pairs up with another dev in a certain part of the code – NONE OF THESE THINGS are to do with ‘bad’ performance – this is part of learning, this is part of accepting that we all have different abilities and it is ‘different’ that creates a balanced healthy dynamic in Scrum teams.


How do I handle ‘bad’ performance or someones ‘head not being in the game’?

When Tim kept turning up late, some times the default response from ScrumMasters is “ok, we need to get a fine system in place”.

You’re basically looking to create a deterrent right? Something that stops someone from doing something, or not.

Now that works, but for me I think there are better drivers that we can create for people to take Scrum events seriously.

Also, I may be the guy who is there to protect the health of the team and enforce Scrum rules – but that enforcing of the rules is also what every single Scrum practitioner should be doing – Dev, QA, BA, Designer, whoever – if you believe in the power of the framework and someones working against it, question it.

Look – I ain’t saying that being a ScrumMaster means you can’t point out problems or dysfunction – of course you can but I also feel like if you are the one who is always seen to be pointing out the problems you are discouraging people from thinking for themselves & not allowing the team to self organise and figure out it’s own problems as a team ¬†– and so until they notice it, I sometimes allow teams to get things wrong, experience it, reflect and then have a strong driver to stop whatever it is from happening, happening again.

So as I was saying…..it’s 9:30am.

Stand up.

There was no sign of Tim.

“So what’s the deal with people turning up late guys?” Me.


I ignored it. And I waited.

“Tim’s not here.. he’s late again” said an uncomfortable Pete.

“Yeah that’s Tim¬†for ya ” replied Tom.

Wry smiles all round.

“Painful isn’t?” I chipped in.

“What? Him always being late for the stand up? Yeah means we need to update him when he does get in” Responded Tom.

“Yep,so…. what are you doing about it exactly?”


“So you guys are cool with him turning up late all the time?”

A little antagonisation is healthy.

Blank faces, some murmurs – no conviction, coming back.

“Anyone spoken to him about it?”

“You guys are a team right?”

“You’re going after the same goal, we’re all in it together aren’t we?”


I took the foot off the gas and let it go.

Day 2.

9:30 am

Stand up begins, no sign of Tim.

Stand up complete.

Tim walks in.

Nice timing.

“Sorry guys, the train…”

Sudden interjection.

“C’mon Tim” said Paul piped up, he continued….

“Every time you’re late, we have to explain where we are off line ….”

Maybe my question of “what are you (the team) doing about it?” had triggered something.

“We could all just do it once in the morning pitched in” Lisa


“Sorry guys.. Tim’s sheepish reply.

And then it came out.

“Come on man, get here on time … we need you here” Paul.

Something happened.

Pressure happened.

Not pressure from me, but pressure from the team.

Peer pressure that said “We need you here, we need here on TIME¬†so we can do this thing together !”

Pretty powerful stuff.

Because Tim’s face was one of self disappointment.

No one wants to let down the side.

When we think of peer pressure we sometimes have known it as a negative thing, but if it is peer pressure for something that is for a team goal and that team goal is positive in Scrum – peer pressure can be a great tool to address ‘bad’ performance in Scrum teams.

I have tried the peer pressure approach over the last few years to address any individual problems that I have had in Scrum teams and have found it to be more effective than individual pressure (i.e. me approaching that individual and telling them what I need from them)

When your team put pressure on you, when your team put pressure on you to be accountable to what you committed to – that really hits home.

That REALLY IS more potent than individual pressure.

Sure I could have said something to Tim.

But then he would have had only me to let down.

But now?

Now Tim has the  entire team to let down.





Senior Managers: Why Scrum needs you to stop bullshi**ing.

 Everyone has a manager.

I get that.

Everyone has someone that they report into at some level.

Me I used to report to my dad.

My dad? to my mother.

My mother? To god.

C’mon seriously.

Even your CEO has a manager – the customer. (That’s for another blog)

Let me get to it.

I saw a head of a certain department working on a huge gant chart the other night before I left work.

“You do know that big old chart is 90 %wrong don’t you?”

“More likely 100%” he laughed back.


Concerning much?

The involuntary vomit touching the back of my throat after seeing a Gant chart in an ‘Agile’ environment was bad enough. But.

Having this ‘senior’ manager accept that this gant chart that he is spending time working on provides a useless & fake projection of the future -WHILST- finding it funny?

That’s another level of derangement.

“Yeah the CEO needs to see where we’re going, it’s really off but it’s something”

Don’t be that alarmed by such responses, I used to be shocked – not anymore.

Dan North put it perfectly:

“We are SO terrified of uncertainty ‚Äď we would rather be wrong than uncertain”

How crazy is that.

We have senior managers who are their to radiate information upwards – to help those in the higher echelons (your sales director say) understand the progress made are not made by the Scrum team to manage expectation – BUT INSTEAD of feeding back with the truth to upper management – they decide to bullsh*t.


And you thought throwing up a Scrum board & writting some BDD Scenarios made us ‘Agile’?

Get the f**k out of here.

You can do all of the Scrum events & have the prettiest looking avatars on your board EVEN with a spiced up Kaizen – but if you ain’t doing the feedback of truth – then you’re just bullshi**ing yourself.

Don’t Confuse MOTION with PROGRESS.

The whole point of Scrum or anything half empirical is to say “hey we are going to do a little bit of something, see what happens & and then take the output and feed it back into our plans”.

To not honestly express the output of what has happened is the biggest mistake you can make,

The very thing that Scrum is built upon & in my view is NOT drilled home enough by those teaching Scrum courses.

Stop talking about the events & artifacts – let’s talk about the essence of what Scrum is.

Scrum is the art of the possible.

Inspect & adapt.

Do stuff. inspect that stuff. then adapt to that stuff.

How can your CEO or head of sales adapt if that senior manager who is meant to report up is not providing the true output of what we have inspected?

“Yeah looks like we can’t get to that feature set based on what we’re seeing with the complexity guys”

Great Рnow is the time for you Mr.Senior Manager to take that fact & go and tell anyone who has an expectation or has set a customer’s expectation in receiving that feature set.

Playing a game

Bullshi**ting as a senior manager through withholding information will only end up in misery.

The lies snow ball.

The stuff that is coming out of your sprint is not being feed upwards and now the expectations of the people at the top think everything is hunky dory.

Mr. Senior Manager is now under pressure to play catch up.

Meet command and control.

Mr. Senior Manager thinks getting ‘tougher’ on the Scrum team and telling the ScrumMaster that “they need to go faster and put in the extra time to make it happen” – that’ll make up for the work that didn’t come out of sprint 1, 2 & 3.

Micromanagement begins.

A good ScrumMaster locks horns with the Senior Manger & in the best case the Senior Manager is forced to go back and manage expectations openly.

In reality, that rarely happens.

I have seen this time and time again.

That Senior Manager is not feeding the truth back up top because maybe around the corner it’s bonus time.

Maybe he thinks he can get away it by forcing the team to ‘just make it happen’.

There are many naive reasons as to why such Managers feel the need to bullsh*t – but none of them, not one – have any good impact for the organisation or the product.

If you are a Senior Manager working in any software environment that involves a time box where stuff is done – stop bullshi**ng your peers, your boss & yourself.

Scrum needs you to be honest.

It needs you to say “this is what really happened at the end of our sprint, update your road map like this and manage your customers expectations”.

If the truth does not get back after the Sprint, you’re setting yourself up for a very messy situation.