Dont stand tall – just S T A N D – U P!

Too little involved & reserved? Then you’re disengaged, uninterested. Over involved and intense? Now you’re coming across as bossy.

This is the challenge for the ScrumMaster.

How do you, as a facilitator find the right balance of getting a SCRUM team to adhere to SCRUM principles without coming across as a ‘Command & Controller’.

Let’s be very clear here just on that point, the ScrumMaster is not the boss of anyone – he/she is the servant/leader who is there to facilitate the teams productivity &  make sure the team stick to the rules of SCRUM.

As a Scrum Master, you will be involved in all SCRUM events (Stand ups, sprint planning meetings, retrospectives) and you need to have that right level of human intelligence, assertiveness (humour helps!) to facilitate without coming across as ‘the boss’ to the team.

I’m talking specifically about the Stand Ups in this article.

For those less familiar with the term ‘Stand Ups’ – this is an event in a SCRUM team which is there to increase transparency, collaboration and the exchange of information across the team.

Each team member will tell ONE ANOTHER – 3 things.

1.what they’re doing, 2.what they aim to get done & 3.Highlight any impediments

The reason I highlight ‘ONE ANOTHER’ is because the Stand up is NOT  a reporting tool from the team players to the ScrumMaster.


IT IS a forum where team players relay information to one another. The purpose of the stand up is not to micromanage or apply pressure to team players, but to understand what we’re all doing, share knowledge, to see if we’re on course to deliver the stories we’ve committed to and for the ScrumMaster to make sure they’re are no impediments or pains effecting the teams productivity

So how do you get that balance as ScrumMaster without coming across as the ‘manager’?

First of all – accept that this is not something you can master over night.

In the 3 years I’ve been doing this I’ve realised that the key to getting it close to ‘right’ is to learn to take a step back. Allow the team to self-manage and simply observe – only involving yourself when you need to.  Here are some useful points which have helped me as a ScrumMaster be the facilitator and not the manager.

1: Step back & trust your team – allow them to exchange information, speak when necessary.

2: Show the right body language – dont stand in front of the SCRUM this can give off the ‘I’m the manager’ persona. Instead blend in.

3: The right tone & attitude – when something is not working right, approach it with an objective & positive attitude to exude the right intention.

4: Pro actively seek feedback from your team – This is where you have the opportunity to learn about what you need to get right.

5:Show complete humility – There is nothing wrong with being wrong. Take on critique and feedback without taking it personally.

6: Keep deepening your understanding of the SCRUM principles – The better your understanding of the SCRUM framework, the more skilled you will be in applying yourself to get the best out of the SCRUM team.

7: Patience – Like SCRUM itself, it is easy to understand but very challenging to master. The ScrumMaster role is no exception, so keep patient and keep going!

Remember, ScrumMaster’s don’t need to stand tall, they just need to stand up.

Measure the team, not the individual


It is against the Scrum Framework to measure the velocity of each individual team player.

Here is a case study, which I’ve created to help you understand why Scrum says measure the team & not the individual.

 Case Study:

Back ground: Meet John & Mark

  • We have 2 developers, John & Mark
  •  Both are highly skilled in their own area of the code base for the application which they develop
  • The business know the overall team velocity but want to know how many points each individual developer can complete
  • It has been established that on average:
  • John completes 5 points a week
  • Mark completes 10 points a week

Looks are deceiving

On the surface it looks as though Mark is ‘better’ at getting work done then John. But what if John completes a significant amount of work which helps the entire team’s overall velocity by story points?

For example.

John works in a part of the application, which has a far, more challenging code base. In other words when John develops ‘stuff’ he has to re-factor allot of the existing code around the new feature he is implementing to ensure that the application’s health is improved and maintained. This means it will be easier for others to create new code in this challenging code base in the future. But, the time John spends re-factoring the code is not recorded in points. John also needed Mark’s input into part of the code base he is less familiar. Mark (as the ‘highest point scorer’) is more focused on delivering what he needs to deliver and is thus less helpful and less enthusiastic in helping John. John will continue coding with less knowledge and essentially create software, which could compromise quality – the other side effect of course is that measuring individual velocity creates an unhealthy competitiveness between team players.


To summarise, focusing on individual velocity points is:

  • Misleading since there are tasks completed by developers which are not accounted for by the story points
  • There will be LESS QUALITY in the software created because developers will be less concerned with tasks such as re-factoring code & helping those with a knowledge gap because of their own focus to focus to deliver points individually
  • It creates an “everyman” for himself mentality which is against the humanistic fundamentals of the Agile mindset
  • Finally, SCRUM is a framework that is built on a team effort – measuring individual velocity begins to separate the team player mentality

In my humble experience, when the business are  measuring each individual’s velocity it usually comes down to a lack of trust. When the business does not have trust in technology they begin to micromanage and want to know who does what on a day-to-day basis. In their mind, the points achieved by each individual developer are an indicator at how ‘good’ they are at their job. This mindset is oblivious to the non-measured tasks that developers carry out which are fundamental in creating high quality software (helping one another to look at parts of the application a developer is less familiar with, re-factoring etc) , spreading knowledge team players (taking time to engage and spread knowledge with a team player mentality), keeping the application in a healthy state (again taking time to refactor for example)

The irony is, this micro management technique reduces team morale, increases work pressure and ultimately reduces the quality of sofware.

All of the things that Agile & its Scrum framework are not.

If you are concerned that a team player is not pulling his/her weight, trust me a real Scrum team will pick up on this and they will not last very long. Be it the daily stand up, sprint planning meeting or the retrospective. There are many events within a Scrum team that highlight who is pulling their weight and who is not.

Individual velocity management isnt the way to do it.

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.


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.