Growing Agile: A Coach’s Guide to Training Scrum

Please go and check out my new book!

leanpub.com/trainingscrum

I’ve moved :)

I’ve tried to keep this site up to date – but blogging is a full time business and so I’ve decided to only blog on the Growing Agile site. That is my company, started with my good friend Karen Greaves. We love all things agile and will continue to blog there together – so MORE really awesome cool blog posts 🙂

I have moved a few popular posts to the Growing Agile site. If there is a post you love on this site that hasn’t moved, leave a comment and I can move it to Growing Agile.

Bye bye!

Evaluate yourself : Scrum Master Shu Ha Ri Test

This post is the last in a series on the Growth Path of a scrum master:

(1) The Growth Path of a Scrum Master

(2) The SHU scrum master

(3) The HA scrum master

(4) The RI scrum master

(5) Evaluate yourself : Scrum Master Shu Ha Ri Test

A few weeks ago we did a survey on Growing Agile and used the classic Jnr, Int, Snr classifications for a scrum master.

We defined them as follows:

• Junior – need mentoring
• Intermediate – comfortable in role
• Senior – coaching other scrum masters

These definitions above exclude time (years in role) and age. I still prefer Shu – Ha – Ri as people leap to fewer conclusions – in my opinion anyway.

Here are a set of statements to get you thinking about where you are. Perhaps in some areas you are the master? And you may still be needing assistance in others. (PS: Thats normal!)

(The numbering means nothing – its just to allow comments to be easier.)

1. You have read a few Scrum specific books.
2. You have read a few books on other agile topics – Kanban, Lean, Facilitation etc
3. You regularly read blog posts and tweets related to agile topics.
4. You partake in conversations (in person or online) debating certain aspects of scrum/agile with colleagues.
5. You partake in conversations (in person or online) debating certain aspects of scrum/agile with strangers.
6. You partake in conversations (in person or online) debating certain aspects of scrum/agile with friends/family
7. You ask other scrum masters what/how they do things.
8. You observe other scrum masters and offer them feedback.
9. You invite others to observe you and give you feedback.
10. The task board, burndown and other “wall artifacts”  are up to date.
11. All meetings for the sprint boundary are setup.
12. You prepare for each retrospective for a couple of hours.
13. Your grooming is a team conversation with business.
14. Your team works as a unit, not as mini silos (analysis,dev,test,qa)
15. The team pulls their work
16. You attend coaching circles to improve your skills
17. You meet with other SMs from other companies to learn to be better
18. You attend conferences and course to improve your skills
19. You have conversations with team members individually to build your relationship
20. You have conversations with your Product Owner to build your relationship
21. You have conversations with Management to build your relationship
22. You have conversations with team members and product owners not on your scrum team  to build your relationship with them
23. You encourage small failure and the learning behind it
24. You practise what you preach
25. You have stories to tell on success and failures

These statements are off the top of my head … there are thousands more – please add yours to the comments and I will update the post (and give you credit!).

The things I mentioned above might come as a surprise to you. Since when is reading and relationship building part of your job description as a scrum master? Well – it is – if you want to be a good one. We try and teach these and other topics in our course Growing Agile Scrum Masters.  These are the keys to becoming great! Content includes: Coaching Self Assessment, Trust, Giving and Receiving Feedback, Listening Skills, Facilitation Skills, Detachment, Self Improvement, Team Assessment, Building Relationships, Scrum Training, Impediments, Motivation, Retrospectives.

Recipe – Omelet Loaf

Note: makes enough for 6 servings

INGREDIENTS:

• 6 eggs
• 250g cooked bacon bits
• 1 cup diced vegetables (courgettes, carrots, red pepper, spring onion)
• some salt and pepper
• 3 tbsp mayonnaise
• 3 tbsp water
• 3 tbsp red pesto sauce (or any other spicy sauce for flavour)

DIRECTIONS:

1. Preheat oven to 160C. Lightly grease silicon loaf tray (I use macadamia oil).
2. In a bowl, beat the eggs. Add meat, vegetables, salt, ground pepper, and any other ingredients and stir to combine.
3. Bake for around 30-40 minutes until a knife inserted into the center of loaf comes out almost clean.
4. I usually cool, cut into 6 slices, then wrap in foil and leave in the fridge for easy munching in the morning.

The story of a themed release backlog

This blog post has moved – you can read it here: http://growingagile.co.za/2012/12/theme-release-backlog/

Coaching Circle – Team Maturity

 

What do you think of when I say team maturity? Do you immediately categorize whether you team is or isn’t? Do you start justifying? And who is in that team? Just developers, maybe a tester? What about your scrum master’s maturity? And your product owners maturity? How do all these various maturity levels affect one another?

 
At our coaching circle we delved into this little dark corner a bit more…
Everyone was given homework to do a week before and bring their answers in. This worked very well – it ensured everyone was in the right frame of mind and had already formed some thoughts and opinions on the topic.

—-HOMEWORK—-
If I say there are 3 levels of team maturity:        [1] immature –> [2] learning –> [3] mature

• What characteristics would you expect to see in each of these teams?
• What would they be doing?
• Who would the team comprise of? dev only? PO? SM? Team lead?
• What responsibilities would you expect these teams to have?

 

–starting off–

We started the session with a quick “get to know someone better” exercise.

Pair up and ask your partner 5 questions (I stuck up questions) then report back to the group the one more interesting thing you learnt about that person.
–gathering data–

Here we started with “Immature” and i asked everyone to scribble down their homework thoughts on stickies and hand them to me, I read them out and stuck them on the board as they came up.  After that we did “Learning” and “Mature”.

I then showed some research I had found on team and maturity and read through the findings … it was nice to see the correlation with what we had done and what the research I found showed.

I then asked – “What about scrum master maturity?” What are the characteristics of an immature vs learning vs mature scrum master?We very quickly came up with some interesting observations, and had a discussion about “Situational Leadership”  that someone had studied.

Moving along swiftly to “What about Product Owner maturity?”A lot more data came out here.

 

–generating insights–

Next up was to see where our greater teams were with respect to maturity. For each team on a sticky write down T (team), S (scrum master), P (product owner) and grade each 1(immature), 2 (learning), 3 (mature).

 

I stuck these up and we discussed what we noticed…. The biggest eye opener was that the Product Owner maturity was lower for all of us – clearly a sign that the role is a difficult one – and perhaps not focussed on enough.

 

–closing–

We wrapped up by selecting our topic for the next circle and thanks to the first exercise where someone bragged about their Tiramisu – they were volunteered in to facilitate and thus bring their Tiramisu! All in all it was a lovely circle with a lot of thought provocation and ideas. The most amazing part of the circles is the conversations that happen around and about the topic – I always learn something new – thanks all 🙂

I do think there might be value in writing up our opinions on maturity …

 

Pre-Mortem Exercise

This is a guest post by Cara Turner – Thanks Cara!

This exercise came from the “Gamestorming” book, and is useful for identifying the issues and concerns surrounding a project that generally stay in the back of people’s minds until they become real problems (the proverbial “Elephants in the Room”).  The method followed is also known as “Remember the Future” (thanks Karen Greaves) – which you can find out more about here: Remember the Future and Remember The Future @ Munich Scrum Gathering.

I recently tried it with a team who were about to start a focused performance enhancement sprint on their product, where there was a lot of pressure on the team, and a lot of concern about whether this sprint would resolve the problems with the product.

We did this exercise in the Sprint Retrospective, and I introduced it as a slightly different retrospective activity, looking backward as if we were already in the future, imagining that we’ve come to the end of the project, and it had all gone horribly wrong – it’s become one of those projects no-one wants to be on or talk about except to say “ooh, at least it’s not the (x) project”.

Usually at the end of one of these projects, there is a ‘Lessons Learned’ exercise, which lists the things that went wrong – and usually, there are a bunch of people saying “I said that would happen – but nobody listened”.  (And, as Lyssa Adkins points out, usually nothing is really learnt from a ‘Lessons Learned’ exercise).

So this is a chance to listen at the start of the story, and get those opinions and fears out early when they can add value to the planning, instead of going down the predictable-failure route.

To make sure that we kept the value of the exercise without changing the format into an impersonal spreadsheet that no-one ever looks at, I modified the Impediment Backlog concept to cater for things that could go wrong but haven’t yet, and stuck the issues & their correlated actions onto this.

 

Thought: since this was part of a retrospective, we first did a Check-in exercise reviewing the previous sprint – I recommend some kind of check-in to get the team’s focus in the room before launching into this, as it requires a lot of imagining…

Introduction to the team:

This is a slightly different retrospective activity, that looks forward not back, but as if we’re looking backward. We’re going to pretend we’ve come to the end of the next sprint, and it’s been a miserable failure – everything that could have gone wrong did.

At this point the team flinched a bit – I had to emphasise that the idea is to find out what went wrong, so not to focus on the feeling so much as the causes.

 

Then the team reviewed the upcoming stories, asking the questions: What could possibly go wrong ?

(at the start of a release, you’d probably be looking at the story map, rather than stories).

“What if” Questions – 5 mins

Ask the team to think of a “What If” question – something that could go wrong. Explain that they’re not going to resolve the issue now, just thinking up questions.

Since these questions are generally going around in people’s minds anyway, but only spoken between friends in informal setting, it really helps to give an example question here  – kind of opens the flow for the team.

Taking it in turns around the room, each person asks a What If question.

for example: What if: the client can’t access the new UAT environment?

Hint: Don’t write down these suggestions: In the session I wrote them down as the team spoke, but this just dried up the flow of ideas for the next phase, as they started reading and thinking about the existing questions. When I wiped the board clean and asked them instead to write their suggestions onto the squared paper, they were off like a shot.

 

What could go wrong? – 15 mins

Building on the “What If” questions, each person has 7 minutes to write down three or more things that could go wrong in this sprint (as many as they can think of, no less than three).

• Each one on a separate paper
• Write as large as you can, so we can read from a distance

Prompting questions: (I read through this twice, first at the start & then when ideas dried up a bit)

• What do you know about right now that you might find frustrating?
• What did you have to wait for?
• What didn’t you have enough time for?
• What hidden issues were exposed by the changes?
• Where did external dependencies affect the work?
• What assumptions were made that turned out to be wrong?
• What might have affected testing?
• What frequent interruptions did you have?
• How did process get in the way?
• What could have been discussed more?
• What integration / inter-system impacts occurred?

 

I encouraged the team to think as widely as possible, and to write down the silly and highly improbable things as well as their current genuine concerns.

Stick each note on the white board, and then group into categories / themes.

 

What’s outside of the team’s control? – 5 mins

Add a large orange dot to the categories that the team has no control over. Move these to the side of the board, to look at separately.

Where we weren’t sure, we added a question mark on the dots, and also addressed these under actions.

 

So what can we do? Actions – 20 mins

Per category group, we asked the following questions:

• What can be done to avoid this happening? (Action)
• Where is someone else involved?
• How will we know that it’s happening?
• What can be done to address it if it happens? (Action)
• How can other people help?

For each item outside the team’s control:

• What would you like to see done as a solution to the issues raised?
• Who should do this?

It’s up to the Scrum Master or Product Owner to make sure these issues are raised in the appropriate forum.

Discuss each group & write at least one action for each on a sticky, and post it up with the groups.

 

Hint: we wrote the actions onto the board next to each group, but then found that we needed the action separately when we added them to the impediment backlog. I’m coming to love stickies more and more for their reusability!

 

Prioritising:

Once we had a response in place for all items raised, we needed to identify which ones were of highest priority to the team. Here I asked the team to vote for items that were:

• Highest areas of concern
• Will add the most value

Each person had 4 red dots to vote; which could all be used on one category, or as they liked over the different categories.

 

 

The Impediment Backlog

At the time I didn’t have a home for these issues in the team room, but didn’t want to lose track of them either, so a couple of days and some research later I drew up a modified Impediment Backlog with the statuses:

– CURRENT Impediments – these are affecting us right now (and SM must action)

– POTENTIAL Impediments – ranked according to their likelihood of occurring as indicated by the team (you could also rank this according to priority)

and added the issue & it’s action to the product backlog.

 

 

What I found interesting was that some of the issues with multiple red dots (high concern to the team) had a low likelihood of occurring; and of them only two were considered significant enough to schedule their actions into future sprints; but the team is comfortable that if any of the others do occur, they know how they will respond.

Also since this was a retrospective, some of the issues didn’t make it to the board, as some retrospective feedback will always remain private – although I suspect this may also be the case in normal workshop format too.

 

And then what?

We review the Impediment Backlog as part of the Daily Standup, removing items that have been resolved, moving ‘potential’ to ‘Current’ if it becomes a real impediment affecting sprint work, and adding new ones.

The Impediment Backlog is a new tool in the organisation, so I think it will take a while before it’s working in the way I’d like to see – a resting place for the team’s unspoken concerns, and an indicator that all stakeholders can access, giving them a better context to understand the issues impacting the success of the product / release / project.

 

The Value of Courage

I have been doing a lot of reading about fear and failure, which has lead me to learn more about shame and courage. Its been a facinating journey  – one which I was totaly unprepared for 🙂

I expected to read and learn about these emotions and then reflect on how they exist in agile environments and how we can use them. This has happened, but how these learning have crept into my personal life was a bit of a surprise. What was meant to be mostly theoretical exercise has turned into a personal journey of discovery.

And its been a bit of a roller coaster ride 🙂

This post is about Courage.

Its one of the Scrum Values and also one of the XP values. When ever I think about courage I cant help but think of the yellow brick road and the cowardly lion 🙂

Courage: Have the courage to commit, to act, to be open, and to expect respect (Schwaber and Beedle 2001).

Courage: Have the courage it takes to develop good software, which may mean throwing away code and changing direction, even late in development. What’s to say that you won’t ever develop yourself into a corner? Courage (Beck and Andres 2004).

Courage seems to be best thought of as the ability to take action in spite of fear. I dont think its binary: you’re either courageous or not. Rather courage is something you embrace or not at a specific moment. Its a conscious decision that gets made every time you face fear. One day, one moment you can be full of courage, and another time not.

Is it possible to always be courageous? I dont know… are any of you?

Courage is tiny pieces of fear all glued together.  ~Terri Guillemets

Courage is not the absence of fear, but rather the judgment that something else is more important than fear.
– Ambrose Redmoon

Courage is resistance to fear, mastery of fear – not absence of fear.
– Mark Twain

When last did you act with courage? What was the fear you faced head on? What about your friends? Your colleagues? Do you acknowledge your courage? Do they? Do you acknowledge their courage?

I acted with courage yesterday and admitted something to a friend. But I don’t have the courage to do this online 🙂 So maybe courage can also happen in stages. Its easier with people you feel safe enough to be vulnerable with. Much more difficult when that trust doesnt exist.

As a scrum master I need to cultivate courage… courage to be imperfect, courage to set boundaries and courage to allow ourselves to be vulnerable. How do you (or your company) cultivate courage?

Coaching Circle – Sharing, visibility, communication

Last night we had our second Coaching Circle session (you can read about the first one here).

The topic was Sharing/Visibility/Communication of status & progress – what tools & techniques.

Our two facilitators did a great job – though we did all forget to vote on a topic for the next session – too much chatter and banter 🙂

I got a fair amount out of this session. Most of us communicate with our teams just fine. The sprint boards, burndown and velocity is understood and used correctly. All of us struggled with communication to stakeholders, executives and customers.

These 3 groups of people (stakeholders, executives and customers) have different needs from communication and thus shouldn’t be lumped all together – as then you end up with a rather complex report that 1 group appreciates, the other group glances at but doesnt understand and in some cases – no-one even reads!

We are all going to try some new things… but as this is my story – I’ll just tell you what I’m going to try 🙂

1 – continue with my sprint 1 page quick glance summary. But get feedback from consumers: 1 baby step I can make to turn the 1 page into “excellent” for them. (I need to blog about this)

2 – find a way to use the story map board electronically. For us this will aid greatly in communicating with customers overseas the progress of the release.

3 – an un-themed retrospective (this was from a conversation … not really related to the topic!)

Smudge – my smallest dog – was very misbehaved. His barked caused a few people to jump with fright (because its such a high pitch). He also brought his toy to the table for attention and jumped onto the table to steal snacks … *sigh*

Next time I will do something to occupy his little mind so that he is not such a nuisance!

What would you do if you knew you could not fail?

The first step to embracing failure is to notice it. And to notice fear. Fear and failure are very closely coupled.

Make up a list. Write it out in big fat pen on a large sheet of paper. Notice how you feel, how your body reacts, what your thoughts are.

Was this easy? Was it difficult? Where you conscious of who could see what you were writing? Where is the paper now? Hidden? Or out in the open? Have you showed anyone? What were your thoughts? Of success? Or of failure? Did excuses pop up? Did you feel excited?

Pick one item on your list. Write it out in BIG LETTERS on a piece of paper.

What is preventing you from doing this right NOW, this minute? Write down everything on another piece of paper. Keep breaking down all these reasons until you get to something you can do now.

Do that one thing.

Did you fail or succeed?

Congratulations if it was a fail! That means you can now make some informed decisions based on fact rather than letting fear prevent you from even trying.

• Is this something you want to do? If we fail fast and quick then we haven’t wasted unnecessary energy trying to do something we dont want to. You are making an informed decision 🙂
• Do you need smaller steps? Sometimes we fail because the thing we were trying to do is just too big. Break your “one thing” down and go again. Dont give up – you need to make an informed decision.
• Do you need to change direction? Tweak your “one thing” and go again.

The only time you don’t fail is the last time you try anything – and it works.  ~William Strong

Try again.  Fail again.  Fail better.  ~Samuel Beckett

Failure is only the opportunity to begin again more intelligently.  ~Henry Ford

The men who try to do something and fail are infinitely better than those who try to do nothing and succeed.  ~Lloyd Jones

If you succeeded – then keep going! Take bigger, bolder steps. Dont walk, dont jog – SPRINT! When you fall and scrape your knee – momentum will bounce you back up to keep going. Soon you will be showing off your scraped knee and bragging about it 🙂