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.

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 🙂

Try removing your QA section to get MORE done!

So this was the problem we were seeing:

Look familiar?

QA field jam packed with stories?

Finding out about issues (stories created during sprint) at the end of the sprint?

Seeing hangover at the end of your sprint?

Why?

Maybe your QA got sick.

Maybe your QA was more busy than normal with support requests.

Maybe your QA was spending time writing acceptance criteria with the PO for the next sprints set of stories.

Or, maybe we need to stop thinking as the QA as the only person who can QA work.

Acting as teams, not individuals 

Scrum is about teams & that means we ultimately need to think about what WE as teams are trying to accomplish. Team goals should be the most important thing in any Scrum team.

That’s what makes Scrum so powerful, you got this disciplined timebox with a specific focus, a goal, which a team work together to deliver.

When we focus on our individual goals over the team goal the Sprint goal suffers.

Delivering the message

When I saw the QA bottlenecks, I asked at the stand-up:

Looking at the board this morning, we need to ask ourselves that question. What can we possibly get through to Done today?

It was my way of hinting that there is plenty in the QA section available to be tested.

By EVERYONE.

The bread and butter of any optimised approach to delivery is focusing on whats in progress to increase throughput.

Something that Kanban principles push hard.

So we can ask the team to focus on getting ‘In Progress’ cards delivered first before picking up new Sprint backlog items.

Developers can QA each others work, so checkout the QA section first to bring down that bottleneck & get stuff into Done.

But we can still reinforce this message to create the right behaviour!

How to visually bring the message home

Change your board.

Remove your QA section.

Here’s one I prepared earlier:

Now when a developers done with his user story, he/she can push it just a notch to the right which means the story is STILL ‘In Progress’.

That is a subtle but powerful visual representation which says “Hey just cause we have done our part developing stories, the stories are still In ‘Progress’.

‘There is only …

‘There is only one boss, the customer. And he can fire everybody in the company from the chairman on down, simply by spending his money somewhere else’

Sam Walton

Expose your “Go to guy”

So you’re in a team, you’re trying to get on with your day to day work  and you’re constantly being disturbed.

Disturbed by issues, queries, concerns, ideas – you know just that stuff development teams have to deal with .

Now it’s common that if you’re the most experienced member of the team – you might become known as the ‘Go to guy”. It kinda makes sense, you’ve been around the longest so you’re most familiar with the issue or  requests, and since you know where to look and how to resolve things faster than your peers – it’s just makes sense that you deal with it.

Right?

Mm-mm,not if you’re a SCRUM team it’s not.

In my humble experience I’ve seen the “Go to guy” mindset in new SCRUM (& some old!) teams & I can tell you, on my many levels it has many draw-backs.

Let’s check those out…..

Reduced SCRUM Capability, Whilst it naturally feels good to be respected & trusted – you know, to feel  like the business come to you because you get things sorted fast – how long will it take before your day to day work , the stories you are aiming to complete for the sprint is seriously impacted because of support issues? If one team member is constantly disturbed with support issues then that effects the capability of the SCRUM team. SCRUM capability is all about how much value , as a team you can bring. Now if one team member is overloaded with support issues, that effects the teams capability to deliver.

Key man risk, when that “go to guy” is  out of office and an issue surfaces that only “he”  deals with – it might take twice as long for other developers to pull together to decipher the code, documentation or what ever means of knowledge available to figure out what needs to be done. SCRUM teams need to actively share knowledge to develop  a healthy team ability to deal with requests.

Reduced autonomy, having a “go to guy” for issues in support cases also means that when new stories are reviewed, not all developers can pick up and complete that piece of work.  SCRUM is all about creating an autonomous team, so that each team member has the ability to complete stories without any dependencies to complete that work –  or as few possible..

Deflated morale, maybe the most significant point. When one individual is loaded, there is  an uneven distribution of responsibility among the a SCRUM (or any !) team. The ” Why do I have to do everything around here” syndrome will surface.  A deflated morale not only effects an individuals performance but can also impact the entire teams morale. Low morale means reduced team productivity.

So what can we do?

When I join new SCRUM teams & see the “Go to guy” – I usually introduce something called “Exposure”.

You can now wipe that grin off of your face, one does not need to remove any attire. Ahem.

Here’s how ‘Exposure’ works.

Every morning during the stand up,  a different developer is ‘Exposed’.

You can use a rota or have team members volunteer but whoever is ‘Exposed’ that is the individual responsible for dealing with all queries & requests from the business for that day.

I know what you’re thinking.

“What happens when a developer picks up an issue that he/she has no idea about?”

That’s the opportunity to learn.

That exposed developer will find the existing ‘expert’ & understand what needs to be done. This is knowledge sharing.

“Yes but what happens to ‘that’ developer’s productivity levels, he’s  being pulled away from his work and so we are losing velocity ?”

In the short run, yes. But what happens when an issue arises that only the “go to guy” (who is out of the office) can answer? The team now lose significant productivity trying to figure out what needs to be done & even worse, it cant be figured out & must be resolved when the “go to guy” comes back. Also, when the team knowledge share grows that will increase productivity – increased knowledge allows team members to pick up work which they couldn’t before: for support and sprint work.

” I am a developer & I think it makes senses that I  just answer the query quickly to help the business – I can’t say no to a senior business guy”

If the CEO approaches you needing critical information there and then – no problem, grab the person who is exposed and sit down with that individual whilst you explain to the CEO what needs to be done. A certain level of expedience exists but you need to proactively do what you can to adhere to this practice to grow knowledge among the team.

In Conclusion

For a well balanced SCRUM team to take form, an investment needs to be made.

An investment in learning from one another & one way of doing that is through the ‘Exposure’ rule.

Try it today & remind one another that the benefits of reduced key man risk, increased autonomy & an even spread of work responsibility can only be a good thing!

Nope, it’s not ALWAYS people over process.

Did I, a passionate believer in all things Agile just commit the biggest,most unforgivable, cardinal sin – ever?

“Its not always people over process”.

Speaking out against the Agile Manifesto?

For all those who use the Agile approach, whether it be through SCRUM, XP, DSDM – the principles behind these Agile frameworks come from the Agile Manifesto. So this might seem like some blasphemous act disagreeing with a part of the holy grail that is the Agile Manifesto, but before you shun me & point to your screen shouting impostor! closet waterfallist ! Let me throw some context around my bold statement 🙂

It was last week that I rolled down to a rare & brilliant Q&A session with two of the most respected chaps in the Agile community. Dan North,the guy who created BDD & Ward Cunningham, he just happened to be one of the people back in 2001 putting the Agile Manifesto together.

10 minutes into the evening, a question from one audience member prompted this reply from Dan North:

“I find that sometimes we (Agile practitioners) can become a little dogmatic – remember the first principle of the Agile manifesto? People over process”.

As a ScrumMaster who helps organisations adopt SCRUM – I didn’t agree.

Here’s why.

SCRUM is an empirical process.

Now what makes an empirical process work are the 2 pillars that help it stand up: Transparency & Adaptation.

If you negotiate the pillars of Transparency & adaption  – SCRUM does not work.

 

Let me give you an example.

A new team is trying to take on SCRUM. The expert user from the business has been trained to become the new Product Owner (PO). “These every day stand up meetings are taking too much time, let’s just have a once a week meeting”. So the team place people over process, remove the daily stand up and meet every Friday for there update meeting. The SCRUM team now run through progress in their new once a week meeting.

Here’s the latest:

* 2 of the stories are stuck in a blocked status they require Ops to take action to move the story into QA

* 1 story is in progress but now requires the Front End developer to do his bit to complete the story

* 2 of the stories are in QA

The once a week meeting which has replaced the daily stand up does still provide information- but a significant amount of time has been lost.  For example, those 2 stories which were blocked could have been in QA by now – Ops would have attended the stand up and taken the necessary action to move the story along. The story sitting in Progress? The daily stand up would have made it explicitly clear to the Front End dev to pick up the story.

So much can change in one day that it is vital to have the Daily Standup to create Transparency, for information to surface & dialogue to be exchanged between team members so that the SCRUM team is able to effectively respond and if necessary adapt.

We placed a person (the PO’s request) over the process(SCRUM)  and it impacted the effectiveness of the team to deliver.

I should add that of course, team members should be communicating daily anyway: the de-fuzz when stories are picked up, pair programming, knowledge share and just proactively reaching out to one another.

In Conclusion

I thought that Dan was applying the Agile Manifesto‘s “people over process” principle out of context.

I think the Agile Manifesto’s principal of “people and interactions over processes & tools” is a reference to engaging and collaborating with one another. Creating a more ‘human’ environment where developers are not isolated to a cubicle with their headphones on coding away, or Product Owners sending in new user stories through an email – but actually getting up & engaging the  devs to understand what is required.

So no, I don’t think you can place people over process IF you are talking about doing SCRUM.

There are less prescriptive frameworks and approaches out there than SCRUM – but if you are doing SCRUM, you need stick to the empirical process if you want it to work.