Scrum: How to drag (sorry, ‘help’) your Product Owner join the daily stand up

The Product Owner is part of the Scrum team.

The stand up is an event for the Scrum team.

So why in the world would you not be pushing for your Product Owner to join the stand up?

Let me start with some of the most common responses I get from Scrum teams & ScrumMasters who can’t get their Product Owner to the stand up.

“He’s not in the country”

So? Heard of Link? Skype? Man, c’mon! This all comes down to desire. We as Scrum practitioners need to push and pull one another in the interest of doing great things! Yes off shore Product Owners are more challenging to get to the stand up, but that’s all it is  – challenging. Not impossible. In one work place I was so determined we used to phone the PO up on my mobile & use it as the speaking token so he could hear each and every update on how we’re progressing, any risk which has surfaced and generally had his expectations managed in real time.

“The PO’s in an important meeting”

Is this meeting more important than the stuff you will be aiming to deliver in the sprint goal? Is it more important than an immediate decision he may need to make when he finds out that a story which was estimated as a 1 is now an 8 ? Does he want to lose that level of leverage? Nothing is more important than the Sprint goal to a true Product Owner. 10 minutes is a small but vital commitment to keep us inspecting and adapting on our progress to handle those inevitable unknowns that pop up.

 “it’s ok we can update her later”

You sure can. And we can play chinese whispers as well, let’s tell a friend to tell a friend to tell friend! Seriously. Remember, the communication gap is one of the biggest challenges in software development.

We already as human beings misinterpret or get things wrong. I have seen this many, many times – a developer takes on the job of getting an update for the PO because the PO can’t or won’t make the stand up. The developer doesn’t cover something or put the context around that something – regardless- risk does not get mitigated, expectations do not get managed and the PO loses his or her ability to make decisions based on new learnings. All because not joining the stand up. Misinterpretations can’t be removed, let’s reduce the communication gap & drag the PO along 🙂

“Not much has changed anyway”.

Says who? All due respect. But the PO is representative of the business. The same way we in tech do not appreciate the business making assumptions about how ‘easy’ or ‘small’ a story is to implement – we need to equally show respect and not assume with what we regard as ‘not much changing’. Whilst at Deutsche bank a developer in one Scrum team found that she could not get a particular symbol added to one of the items in a drop down menu. Didn’t seem like a big deal, and so the PO only found out when we got to the Show & Tell. The outcome? We didn’t meet the MVP for the clients needs since this symbol impacted the ability of a particular financial instrument to work within the application. If something changes the PO needs to know. We don’t need to wait to the stand up to update the PO on the change – but it’s damn good place to start. 

 

Yes but it’s not that simple, no one is listening to me!

David couldn’t catch the ball in the stand ups. Ever.

 

 

Been there, done that, t-shirts, key rings, fridge magnets – the lot.

So which is it in your case? I mean, how did it come to your organisation moving towards Scrum – who did they pick or turn into the Product Owner?

Did they  grab an expert user who has a million other things to do in their day job & told ’em “Hey you are our new Product Owner”.  Or is it a new Director or some other ‘senior’ person that likes the idea of Scrum but doesn’t understand the commitment it needs for the PO role to work? Or was it someone they hired who has a different understanding to what a PO’s commitments to the Scrum are?

Look regardless of how it became the way it is, we CAN do something about it – and by the way – it doesn’t have to be only ScrumMasters ‘doing’ the something about it.  As a Scrum team we are all responsible for inspecting & adapting towards our Sprint goal, the Scrum team together are more likely to get to that sprint goal – so show some courage and speak up.

Influencing the PO to join the stand up 

Use team pressure – If the PO is still sitting at their desk when the team are about to do the stand up, you’d be surprised at how powerful it is when we all physically turn and look at the PO waiting for his/her to join us.

Lead by example – As a ScrumMaster one thing I do is emphasise the importance of acting the way you’d like your team members to act. “we want our guys to go above and beyond to deliver great product, man the least we can do is be there to be part of their update to ensure they feel supported, motivated & heard”

Show case misunderstandings – Did someone update the PO about something which effected a story being delivered? Capture that item, keep hold of it, build an damn archive if you must – and then present the metric back to the PO: “Yeah looks like we had a few spikes completed but we never fleshed out new stories since we weren’t sure that was the thing to do – could you come along to the stands up”

Press the Empowerment button – “Yeah so we found that we got x amount of traffic with this tech at y cost, and we decided to carry on with the story..it seemed worth it”. Like I said above, explain to the PO that we don’t want to take away his healthy power bar in making business decisions based on new findings. The PO might want to drop a story or get a new one thrown into the backlog based on new findings. Remind the PO that by not coming to the stand up, they lose power in their real time decision making which effects the learnings of the sprint.

Remind the PO of their importance – “Hey Mr PO you know when you come along to the stand up and you energise us talking about what great things this goal will bring, it really motivates the guys. Not to mention how they respect you as a peer turning up into the trenches as one of us ensuring that their clear on the deliverables”. Man there are so many examples of how I remind the PO of what great value they bring when they come to the stand up! Find the positives & sell ’em!

The Power of a coffee (or beer) – Stepping out with your PO out for a bite or drink allows you to create an informal and open conversation where we can be more candid with one another.  Make the effort to lunch or whatever with your PO to make ’em feel like they are part of the team and want to be part of your team events.

IT’S NOT A PERFECT WORLD.

No it isn’t. But if we have good working relationships, speak openly about what we need and why then we are definitely iterating towards a better world.

The key is to keep it human and showcase the dysfunction we experience without the PO being at our stand up …help them understand the problem their absence can cause.

And don’t expect perfection, that ends up in disappointment.

Just because we can’t get the PO at every stand up, that doesn’t mean we should loose heart or get annoyed.

In Scrum we aim to deliver iterative small bite sized pieces of value, little and often.

That also applies to changing mindset.

Keep patient, keep human & showcase the problems to your PO.

Here’s how Scrum handles (some) risk project managers!

In the interest of not being machine gunned with “hey you know nothing about Risk Management” – I want to be clear from the  jump. My focus is on Scrum & Risk. And that is to say that risk in the context of a Scrum setting is anything that could stop the Scrum team from delivering a sprint goal. For those less savvy with Scrum, it goes like this. Scrum takes what the Product Owner wants done in a sprint and the team go after this sprint goal. Anything that impacts the team from getting to this sprint goal – for me – I see this as Risk in Scrum.  I am not talking about the broad subject of risk management  – i.e say the ideation stage of creating a product where you may want to identify new competitors say. I am talking specifically about risk which affects the Scrum teams ability to deliver a sprint goal.

The problem – we’re scaring people.

There was a Project Manager (PM) talking with a ScrumMaster (SM)- the PM asked…..”how does Scrum handle risk”…..the reply? “Well Scrum doesn’t handle risk, it’s actually silent on the subject”. Disappointingly I have heard similar answer from SM’s and other Scrum practitioners – and although their answer is technically correct – it does nothing but scare the crap out of PM’s. And I can understand why!  “Hold on so we are doing Scrum now and you’re telling me this methodology or sorry framework doesn’t handle risk – at all, and I should just back off and trust the team?”. Is it any wonder why so many Project Managers turn up to stand ups with a pen and a pad and are watching cards move around the board like stalkers – where the hell is the reassurance to explain what Scrum has built into it, to handle risk?

Scrum is silent on risk you say?

Is it really? Scrum is silent on risk?  Now it’s time to pull out the big guns and throw down one of my stupid drawings to show you that I mean business. Grrr.

“This story is bigger than a 3 dude, we’re looking at an 8 – just a lot more complexity with this one than we expected. What do you think Mr. PO?”. Risk mitigation in real time. Now the PO has the opportunity to say “ok push on with this bigger unexpected story, and I can manage expectation on how it impacts the other stories in the lower part of the sprint backlog” or “ok, let’s drop it out of the sprint, and go for some lower hanging fruit”.

“Bro you’ve been on that story a few days now, everything ok… we could pair on that just to see how we can move it forward?” Now that junior who’s been stuck on that story can tag up with a dev and push that story forward, a little cross knowledge loving and increasing the odds of getting that story through to ‘Done’. Sprint goal protected, risk mitigated.

“Guys how comes we keep pulling in stories into progress when I (QA) am on the back foot with a big old bottle neck? Can we stop pulling in new stories and all chip in to get the QA bottle neck down please?”. Boom. The team chip in and test one anothers work, issues get found out earlier, we have more time to respond and therefore increase the chances of getting more stories to done. Sprint goal protected, Risk mitigated.

“Yeah looks like those stories need a certain type of data in the test environment – Bobby from operations ain’t around to run that script to make that happen – is there anyone else in ops who can sort this?”. If we can get that data, we can test that story. Now we’re surfaced the problem, we can go after it. Again, that means we’re protecting the sprint goal. Risk getting mitigated.

If we can bring PM’s along to the stand up and show them how we handle risk through inspecting and adapting in our Scrum event – they will begin to feel more reassured that Scrum is definitely NOT silent on risk.

 

“So we went after 23 points but came out with 13. It looks like it’s going to impact the next sprint because now we have hang over…. mmmm, I better look at how that impacts our roadmap”. The Show & Tell event in Scrum lets us look at what the team have delivered and then feed our findings back into the plan. This is important because it allows the PO to get back to people like the Sales Director and help him manage customers expectations. “Sorry Larry, not sure we will have that MVP demo in time for March – it looks more like June”. That is mitigating risk. If we can’t deliver product in time for something, we need to communicate the situation so people are informed to ensure that they don’t lose customers by letting ’em down at the last second. The Scrum event of Show & Tell lets us inspect and adapt to mitigate/manage risk.

 

“How comes we’re not hitting our sprint goals, this is becoming an ongoing thing – what’s the problem guys” (PO talking). The retrospective is the event where we again inspect and adapt in the interest of looking at things which did not go so well. “Look Mr. PO we are seeing 60% unplanned issues and 40% project work, we’re getting way too many business requests (unplanned work) coming through to the Scrum team and that is hurting our sprint goal”. This is just one example of how Scrum has a dedicated event to help the team to surface dysfunction in the interest of doing things better. And because Scrum is based on 1-2 week (ideally) iterations, that means we get to find out if we’re doing things wrong pretty early on – and then do something about it. In the above example the PO can better safe guard or get tougher with what he lets into the sprint as unplanned work. This would allow him to increase the odds of the team meeting the sprint goal (if left undisturbed) and that again, is mitigating risk through protecting the sprint goal.

If you have the luxury….

If your team is all on site, then try to ensure you all sit together. The Physical set up of a Scrum team is very, very effective in making sure that things are not misunderstood – (in reality misunderstood less :)), there is more group intelligence which means better ideas to get to the bottom of the problem which can result in more efficient approaches to delivering a goal …as well as the team gelling part. A well gelled team who have good rapport look out for one another so when they see somebody stuck on a card, they don’t turn a blind eye to it. They want to help – helping is getting more done – getting more done is protecting the sprint goal. Protecting the sprint goal is mitigating risk.  W

Show case how Scrum manages/mitigates risk to the PM or senior manager…

It’s up to us 

Risk is constantly managed in Scrum – and WE as Scrum practitioners need to point out where & how we manage/mitigate risk so that we can build confidence with those people that we are trying to transform – away from micro management & into servant leadership. Most of the PM’s I’ve worked with who are trying to micromanage do so because they are scared. Scared that work is not going to get done, or that the team ain’t gonna pull their weight if the PM isn’t their watching like a hawk.  We need to show PMs how our Scrum events protect the Spring goal and manage risk in a real time fashion. Invite them along to events, put out those words ‘Inspect & Adapt’ – we can showcase Empiricism through our actions to build trust, gain reassurance and ultimately reduce the stalking!

The Scrum framework contains Events, techniques, artefacts & an overall mindset which is there to manage risk.

it’s our responsibility as Scrum practitioners to express that.

So yeah Scrums silent on risk guys.

And Pavarotti was silent on singing.

 

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?

Sure?

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.

BUT.

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.

BUT.

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 🙂

Ready?

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.

So.

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.

Silence.

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

Silence.

“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?”

Silence.

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

Silence.

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

Mmmm.

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.

Wow.

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.

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”

COO:”Right…”

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”

Silence.

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.

COO:Silence

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

Wow.

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

No one JUST STOPS CARING.

BUT.

You can definitely GET people to NOT CARE.

HOW TO STOP YOUR DEV’S FROM CARING.

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?

Seriously?

Dude.

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

ARROGANCE.

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.

Developers.

Software.

Brains, Dev tend to have ’em.

A group of dev’s.

That’s allot of noodles.

Useful maybe?

Man.

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?

To care enough to question the value behind a user story SO THAT YOU DON’T WASTE YOUR TIME OR MONEY ON SOMETHING WHICH IS MORE EXPENSIVE IN DEV TIME THEN IT IS IN BUSINESS VALUE.

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 ?

R.I.P INTRINSIC MOTIVATION

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.

“ScrumMaster”

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”

BRAP.

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.

Nod.

“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?”

Mmmm..

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

Nod.

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

Brap.

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

EMPOWERMENT, INCREASE TEAM MORALE, MOTIVATE THE TEAM

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

INCREASE TEAM MORALE, MOTIVATE, REFRESH ON THE GOAL.

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

INCREASE INITIATIVE, INCREASE CREATIVITY, INCREASE THE ABILITY TO SELF MANAGE

•  “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”:

EMPOWERMENT,INCREASE INITIATIVE, INCREASE CREATIVITY, INCREASE THE ABILITY TO SELF MANAGE

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

INCREASE INITIATIVE, INCREASE CREATIVITY, INCREASE THE ABILITY TO SELF MANAGE

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.

Why?

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.

So…

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?

Why?

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?

Or.

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?

;p

Ahh the sweet smell of creativity!

lol

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?

No.

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

BUT.

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

Now.

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.

So….

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.