Let me tell you WHY your devs dont care – because YOU DON’T brah!

Click, the kettle goes on.

Standing in the Kitchen I feel a creepy prescence behind me.

COO: “I spoke with Tom (That’s the Product Owner he spoke with)

….So Jem how comes we can’t deliver the sprint goal”

Pouring in the hot water into my delicious cancer infested instant coffee granules.

“Well it’s turning out to be allot more complex then expected”

“We explained to Tom that these stories in this sprint are larger than normal & that means more unknowns and now that we’ve started to reveal those unknowns… there’s increased complexity”


Me:”We have other options, we can reduce some of the sophistication in those stories as we discussed before & that could help with us getting closer to the sprint goal”

COO: “Well no, because that ain’t gonna cut it.

*Please note there is a wider issue here of this individuals ability & desire to understand how empiricism in software works. It would take a shelf full of mythical man month books (empiricism bit), throw into a blender with the DNA of a 1000 Nuns (humility DNA sorted) injected into his veins followed by a personality transplant to get – maybe – just a tiny bit close to WANTING to understand how Scrum works.

Me: I’ve made Tom  aware of  what we can and cannot do, you have two options. Less sophistication on those stories (as advised) or larger stories which more sophistication which take longer.

COO: “Well actually, I think there’s a deeper issue here”

“I am fed up of how little the team care”


Me: “Right…..how do you mean exactly…. how little the team care?”

COO: “You want a list?”

Drawing for my sword.

Me: “There’s a list?”

Sword now at his throat.


My fantasy sword twirling playfully under his Jimmy Savile sized chin.

Say something bad about my Scrum family…. do it.

I dare you.

And then,

He let it out.

Like a big, fat constipated baby that just ate a kilo of grapes.

This was a drive by, a drive by of smelly, ugly news.

“Those developers never turn up on time”.

“Those developers always look like they don’t want to be here”.

“Those developers never put in that extra when we’re in trouble”.

“Those developers DON’T seem to care”.

Man, I was just waiting to hear the Mortal Kombat line ” FINISH HIM”.


“I think the guys are little down at the moment in spirit yes”.

COO: “That’s putting it nicely Jem”

COO:”I’m paying them to do a job”

Interesting huh?

It’s not the 1st and won’t be the last time that we’ll hear of people complain about Dev’s who don’t care.

I wonder if they ever wondered why that was.



You can definitely GET people to NOT CARE.


When you told ’em about a project that needed to be done, they asked “Why”? You said, “because it needs to get done”.

When the user story got pushed back by dev and they asked “Why”, “what the driver behind the story was”, you said “it’s what we need to do”.

When they told you it was part of User Stories to understand the “Why”, you used fear and reminded ’em that they’re there to “do a job” & to “not slow down the process with extra questions”.

When a hard date was created to deliver a piece of software and the team asked you “Why are we shooting for that date”, “what’s the incentive here?”. You said “Because I want to have a date”.

When they pushed back and said “that’s just an arbitrary date & we shouldn’t be communicating 6 months ahead to customers tangible scope “, you said ” that’s the way it works round here”.

When the team said they were concerned with the micromanaging and asked why the dynamic had changed in the office, you said ” you need to get your head down and play the game”

When the team said that a big part of Scrum is the interaction piece and the ongoing conversations are there to clarify understanding, use group intelligence to do things better & asked why they need a ‘meeting room’ for these huddles… what did you say” because it looks like you are not doing any work and management don’t like the look of you not doing work”.

And you ask why these developers ‘Don’t care?’

Why they don’t come running to work quicker than the off-spring of a duracle bunny & a can of red bull?



This comes down to one thing, and one thing only.


To not take on feedback and listen to what these people doing the actual work have to say.

Arrogance to NOT explain WHY the business need what they need.

Arrogance to NOT have a dialogue & discuss WHY we need to use an empirical approach to software development.

Arrogance to NOT have the courage to challenge their senior managers views on the need for Scrum teams to stop interacting as it looks like “they ain’t working”

Do you know what noodles are?




Brains, Dev tend to have ’em.

A group of dev’s.

That’s allot of noodles.

Useful maybe?


Just think about it.

These people with brains  are passionate about technology & want to do awesome things with technology.

These people want to question what you want so they can give it to you in the best way possible.

Is that unreasonable?

Is it unreasonable to care?

To care enough to ask if there is a BETTER WAY OF DELIVERING WHAT YOU NEED, TO GET SMALL CHUNKS OF VALUE OUT EARLIER TO TAKE FEEDBACK & GROW AWESOME PRODUCTS! (breaking up stories, identifying a true lean MVP, stopping big upfront design, accepting that customer feedback grows the best product etc)

To care enough that they are saying to you that Software has moved on from predictive bullish*t & TO WAKE UP TO empiricism  & address uncertainty in short time boxes, feed it back into our road map & make sure the customer knows the scope can vary from the get go – SO YOU DON’T LOSE FACE TO YOUR CUSTOMERS?


They care.

But you don’t want ’em to?

Don’t argue back – you clearly DONT WANT DEV’S TO CARE!

Come on!

You won’t tell em why.

Project zap creativity and initiative now on.

You won’t  listen to the right approach to software development (empiricism) which helps you manage customer expectations honestly and openly WITHOUT starting death marches which destroy the souls of developers.

Project let’s crush morales & create a death march which we know will end in a blood bath.

You won’t listen to the fundamental support they need to get Scrum working (interactions, events etc)

Project lets smash to pieces any energy and vibrancy and therefore desire the team have about their work or the team.

You are not willing to take on feedback in the crap dynamic being created which makes a morgue look exciting.

Project let’s make developers so fearful of having a conversation, requirements get misunderstood, group intelligence is dead and we’re seeing suboptimal solutions, pairing is dead – now cross functionality has gone into the after life along with autonomy 

oH I’m sorry, you wanted Dev’s to care?

How can they ?


Caring means you need to feel motivated about what you do.

Intrinsically, from inside, motivated.

But your arrogance is killing any intrinsic motivation which could every surface man!

Your arrogance…

It destroys energy, purpose, excitement, creativity, desire — inner motivation — which makes you WANT to get to work, WANT to stick around later to get that story into done, WANT to deliver that bad ass product, WANT to make your firm as successful as possible.

All of that stuff above, all of it.

It comes down to intrinsic motivation.

But intrinsic motivation is never going to happen.

Because you are too arrogant to listen, to be educated, to hear the truth, to discuss, to treat people like they are your peer instead of a subordinate.

Your arrogance is stopping developers from caring.

Don’t expect anyone to care, no matter how well paid they are.

Caring is a two way street.

If you want devs to care, you need to let ’em care.

5 minutes to explain what a ScrumMaster does – to a bunch of 14 year olds :S

Microphone handed over.

Nerves kicked in.

” Jem is a ScrumMaster”. Said the lady who set up this motivational talk.

These were a handful of sessions, presenting to Edmonton County School students on what I now did for a career.


Cue the confused 14 year old faces.

With the teachers in the hall looking even more baffled.

This is going to be fun .

“Is he some sort of BDSM guy who uses a rugby ball instead of a gag ball” whispered the Geography teacher”.

How inappropriate I thought.

But then most of my thinking is inappropriate.

Pressure does funny things.

So, how do I explain to a bunch of kids what the hell a ScrumMaster does in 3-5 minutes?

Stick to what your good at Jem.

In these situations “I do have the ability ” I told myself.

The ability to use the dodgiest of analogises to get my point across.

“You see when you go into Asda,there are people on the tills taking money right? There are people working in the isles stacking shelves. Well, I help these people who do the day to day work have a voice and make sure their voice gets heard in the decisions which are made by the people who pay them”.

“I go into organisations and get the people at the bottom of the organisation involved at making decisions at the top of the organisation”


That was the immediate response from one member of the crowd.

For those of you who haven’t been raised in inner city london ‘Brap’ (usually accompanied by a hand signal that represents a gun, yes a gun) is a way of showing ‘positive acknowledgement’ let’s say. (you get me though?)

Then some claps, and a couple of cheers.

“What kind of places do you work in?”

Someone shouted.

“Well right now i work in…

“No as in what kind of places?”

“Industry?” I asked.


“Right…. well I don’t work in anyone particular industry, can be media, it can be pharmaceutical, it can be banking…

But it’s all within the technology field”

The response?

“So you are a programmer or something?”



2 ish minutes in, you now have a couple of minutes left to explain that you are  in technology but ain’t a techy.

“Not exactly. Think of me as someone who supports a team of programmers & makes sure that they are happy with their working environment & makes sure they are clear on what we need to do to be successful”

With all positive facial expression of “Ahh I get it” the response was…

“Ahh so you are a manager of programmers”

Cue the emotional face palm.

Now I have like a minute and half at best to  to explain the difference between a facilitator and a manager to a 14 yr old kid who’s only experience with the word ‘facilitator’ was when they needed to get some obscure item from the care takers Facilities cupboard.

“I am a cupboard”

“A human cupboard that contains obscure items.

“Broomsticks, blue tac, deflated footballs, I am all of these things”

“I am not just any cupboard however, I am a mahogany cupboard”

I did not say any of the above.

I am not tall enough to be a cupboard.

I’m more like a bedside draw.

My real response went like this.

“What’s your favourite sport?”

“Football” he said

Ok, so imagine you are in say a… 5 a side team.

There are two different types of people who ‘run’ the team ok?

There is the manager & there is someone called a Facilitator.

Let’s first look at how the manager runs the team.

Before you go out on the pitch, this is what I tell you and the team:

“You, you go after the ball & once you get the ball, you pass it to Tim.

Tim you pass the ball to Michael

Michael when you get the ball hold onto the ball until Liam is unmarked.

When Liam is unmarked, then pass him the ball.

Liam when you get the ball, hit the ball with your right foot into the back of the net”

Ok, now imagine I am not your manager – imagine that I am the team’s facilitator:

“Guys, you’ve trained hard for this, take a sip of your Lucozade, and let’s win this match!”

Do you see the difference?

A slight look of confusion.

“Mmmm yeah but.. but how will we know guys know how to win if you don’t tell us sorta thing?”

The moment of servant leader enlightenment!

“How long have you played football for?

“Since I was 10”..

“So you’ve played for a little while?”


“You like to play football.

You know how to play football.

You know where the goal is.

So go play football”

A wry smile appeared.

A smile akin to a newbie Scrum developer that is told “don’t worry about how the expert user wants the problem solved, we wanna leave the how part to you”.

“Think about it” I continued.

“Who is the one playing football, who is the one actually on the pitch, kicking the ball & has experience of knowing how to get the ball?”

“Me?” the enquriy

“Yep, you”

“Why should I limit your options on how to play football when you know how to play football”

“I want you to remain creative”

“I want you to be able to think for yourself”

“Maybe if you ONLY listen to my instructions on how to do things, you might end up in a situation that I didn’t give you steps for and then you might not know what to do”

That look “ahhh I get it” with some wide eyes.

“If I told you exactly what to do, if I tell you that you must pass it to Liam…  maybe  Tim becomes free in front of the goal and you don’t need to pass it to Liam….”

“If you think for yourself, we might score more goals”


A good section of the crowd liked the sound of that.


I only had 5 minutes and in reality I spoke for maybe double that.

But I learned something about myself that day.

I learned what my instinctive, passionate and true feelings for Scrum really are.

Did I talk about how empiricism works?

No. I would have loved to! But I just didn’t have the time.

When push came to shove and I had limited time to speak about Scrum, what did I choose?

Let me pick out the key statements I made that express my instinctive and immediate feelings on what a ScrumMaster does.

  • “Getting the people at the bottom of the organisation involved in the decision making at the top”:


  • “Guys, you’ve trained hard for this, take a sip of your Lucozade, and let’s win this match!”


  • “Why should I limit your options on how to play football when you know how to play football” :


  •  “Maybe if you ONLY listen to my instructions on how to do things, you might end up in a situation that I didn’t give you steps for and then you might not know what to do”:


  • “If you think for yourself, we might score more goals””


Nearly all of the expressions above capture Empowerment, the need to keep creativity & create initiative, the need to motivate the team & the actions to take to increase the teams ability to self-manage — and the all important part — that as long as the team know what the goal is — trust them to deliver it.

No mention of iterative development, no mention of code quality, no mention of a CI infrastructure.


Because to me, the fundamentals of a ScrumMaster come down to human skills and the ability to facilitate with a servant leadership style.

No doubt, given 30 minutes I would have gone into empiricism and how the ScrumMaster supports this approach by driving the Scrum rules.

No doubt, given 30 minutes I would have spoken about the importance of quality in software development and how the ScrumMaster can facilitate discussions on proven techniques and methods which increase quality in what we deliver.

No doubt at all, that there is allot I couldn’t cover.

But in 5 minutes, I covered what I thought what most essential & the best part was … it was not thought out. It was instinctive and even with retrospection it feels right that I focused on the servant-leadership model above everything.

What would you say if you only had 5 minutes?

Would love to hear replies 🙂

STOP TECHNOLOGY STEREOTYPING: Developers ain’t cyborgs buddy, they are artistes!

Man, sometimes the smallest bit of ear wigging – sorry – I meant unintended observation – can give you the greatest of light bulb moments.

So I’m sitting here drinking a protein shake.

Chocolate chip cream infusion.

Sounds more like a frappuccino right?

It is a frappuccino.

So I’m drinking this high calorie,sugar fulled, high fat, artery clogging milkshake that will spike my sugar levels & make me feel like god for 3 minutes & then turn me into a lifeless corpse.

I have no issues with my choice in fattening,disgusting beverages which will contribute to the death toll of human’s through some cardio vascular related disease.

Completely comfortable here, no insecurities.


The heads of sales walks into the room. He’s talking to one of our UI/UX guys (a designer), he says…

“Yeah, Pete following what we spoke about. What I’m after is something really punchy, something clean looking that delivers the message of being hip but professional you know?”

blah, blah, blah – but the next line killed it for me.

“Yeah, yeah sounds good Pete. I mean you’re the designer so how you make it sing, that’s your thing so yeah… go for it!”

Let’s just be clear on what happened here.

So, a customer walked over to the designer & told ’em what they wanted, what their goal were WITHOUT prescribing ANY kind of solution.

INFACT – the customer made the point of the designer bringing their creative juices to the table with the “that’s your thing… go for it!”.

How comes we don’t see the SAME customer, approaching developers with the same mindset?

That guy in sales will approach a developer with a request & the conversation will go something like this:

“You see Tim, what I need is a little pop up box here & when it pops up right I want there to be two little buttons on the box which allow you to either say yeah I’ve done that activity or actually I want to dismiss that activity”.

So sticking with the format we had above (when the customer approaches the designer, let’s apply it to how the customer approached the developer).

The customer walked over to the developer & told ’em what they wanted, how they wanted it & prescribed a solution.

Are developers seen as cyborgs who need to be told WHAT & HOW?

Do they have no creativity?


How come the designer is told the goal & is given a reign on how to deliver that goal WITH NO SOLUTION – BUT the developer is NOT told the goal, is NOT given a free reign  on how to deliver the goal & IS PRESCRIBED THE SOLUTION.

Stereotypes of developers being cyborgs


Just because developers write ‘code’ that you don’t understand or do ‘techy’ things which you in the business might not care for – that does not mean that they are not creatives.

Developers ARE creatives.

Creative people are NOT just those who have a fancy set of colouring pens that can draw cool funky pictures and logos.

I’m not trying to patronise, I’m just saying we need to think of creativity in a much broader sense.

And no, I ain’t looking to open up the can of worms that is defining what creativity is.

For me, when there are a 1000 ways of getting to a goal, then that suggests that it takes creativity in the number of things which we can consider to deliver that goal in an awesome way.

If those 1000 ways have been practised & apply by experts in a particular field, is it not a good idea to support their creativity to get me the best solution?

I mean really?

If I was a CEO who’s life blood was built upon technology – technology which is used by a group of guys day in day out – technology which a group of guys have studied, applied and continue to study & apply this technology in 1000’s of different ways to do awesome things – would it not be a good idea to simply tell these technologists what I want as a business goal & LET THEM use their creativity with the technologies that they are experts in to DELIVER my business goal?

What would give me a better product?

A product which is developed by a team who have been empowered & encouraged to utilise their creativity in their chose field (technology) to present to me a variety of options on how they can deliver me a great product?


A product which is developed by a team who have had no encouragement to utilise their creativity, are fed solutions by people who are not experts in their chosen field (i.e the business telling technology how to create stuff) – and therefore having limited options in how a great product can be delivered.

I think we know what we’d pick.

We need to realise that developers are creative technologists.

They are experts in their chosen area of technology, they understand the technology, they know how to utilise their choice of technology in many, many different ways to achieve different desirable outcomes.

It is in your interest to treat your developers like you would your designer.

Challenge your technology stereotypes.

Even if it means kitting out development with  soft, round, flat-crowned,hand-knitted berets speaking in a french accent wearing cashmere roll necks who wear bright coloured socks.

Did someone say stereotypes?



Ahh the sweet smell of creativity!


Bin your sins or stay blocked – illustrating annoying context changes on your Scrum Board to promote change!

Recently I was working with a team that were dealing with a number of disturbances.

When I say disturbances I’m talking, the sprint kicks off & Unplanned Work comes in.

Is that unique, is that unacceptable?


My view, Scrum teams need to have all the support in the world to ensure they are left alone to deliver the Sprint goal.


Scrum teams also have to provide some level of a support function when it is needed for multiple reasons.

1st & 2nd line can’t resolve an issue impacting a client in production.

Something just exploded in Production and no ones noticed yet, but it needs gravitas from a Scrum team to help support nail the issue.

The sales team need to confirm business logic on how something works for a pushy client & the only guy that knows is Bob in the Scrum team cause he’s been in the same company for 10 years.

And so.

I ain’t saying we should have a stream of Unplanned Work.

I am saying I understand the nature of delivering a project (the sprint work) & helping the business keep it’s wheels on (the support work).


When the disturbances are constant.

When the disturbances involve pulling developers off of work they are working on to address issues.

That’s expensive.

Expensive because it involves context changing.

I would like to show you a mini case study of a team who were made to do this allot & what we did about bringing this problem of context changing to the attention of the Product Owner.

I’ve simplified this board to give you the focus on one developer’s pain….

Tim is working on Story 1. There are 2 stories, Story 2 & Story 3 which are blocked.


An unplanned piece of work comes in. The PO has explained that it can’t wait and needs attention ASAP.


Tim stops working on Story 1, and picks up the Unplanned Work. Story 1 is then placed into the ‘Blocked’ box.


Tim is working on the Unplanned Work when suddenly the Product Owner comes over and explains that it’s “vital that this ‘request from the business is handled ASAP -since a customer needs to know the answer to a question which only Tim would know”.


Now the 1st Unplanned piece of work goes into the Blocked box & Tim begins working on the new Unplanned Work item.

Now take a good look at the Blocked box.


Does that look right to you?

Does it seem right that we have stories & Unplanned Work placed into the Blocked box?

It didn’t sit well with me.

The fact that we were not illustrating that there was a problem.

A problem in the high disturbances we were receiving.


Here’s the 1st thing I did.

Some healthy antagonising 🙂


Sad smileys anyone?

“Why do we have sad smileys on those cards” asked Tim in the Stand up.

So we had a discussion, with me asking the below question to the team:


We were hiding dysfunction through misusing the Blocked box.

Think about it.

When something is blocked its an external dependency & we accept that the artefact belongs in the Blocked box.

But when someone is pulled off an existing piece of work to do ’emergency’ stuff a la Unplanned Work – that item is not Blocked.

If I am working on something, and I am pulled off of that something and made to switch context, then that item belongs in one place and one place only.

Meet the SINBIN.


This is a quick, easy modification to your board which shows how many times the team have been disturbed/pulled off whilst in the middle of something to handle an Unplanned Work item.

Here’s how our Unplanned Work items look now.


Now we have clear distinctions between work which is truly Blocked & work which has been Sin binned.

When that SINBIN box begins to mount, nudge your Product Owner…

“Looks like we’re pulling off the guys to deal with Unplanned Work, all that context changing isn’t healthy…. it’ll most likely effect our Sprint goal”.

This is how we need to handle Unplanned Work which forces developers to be pulled off existing work.

Every context change impacts the effectiveness of getting a card through to done.

We need to show on our boards, the frequency of these types of requests to drive home the point that context changing slows us down.

Scrum – Let’s stop talking about speed, let’s start talking about what’s possible.

Scrum is the art of the possible.

Let’s talk about what we can really deliver WITHOUT ever compromising quality!

Getting ‘more’ story cards over the line which do not have quality built in only means more defects & an application which will become harder to manage and sustain.

That’s a blocker for Agile delivery, since we need an application which has been built that is easily maintained & allows easy changes to be made.

Let’s stop talking about speed, start talking about what’s possible.