I have been getting very involved with the Business Analysis community at my current client ASOS (Mega large fashion retailer). In the absence of a true Product Owner role here, the job they do is absolutely key.

Over the last month I have been running a series of lunch and learn sessions to compliment some education they have been doing with the BCS Business Analysis course. One of those was user story mapping.

I wrote a 1.5 hour lunch and learn for them and a complimenting guide with all my top tips in.  I wrote this with my good friend Richard Arpino, who works as a ScrumMaster at ASOS. The aim of this guide is so that they can continue to run these sessions once I have left them. Whilst it is not as good and as comprehensive as the book ‘User Story Mapping’ by Geoff Patton. It’s enough to spark creativity and a pull for them to know more about this technique.   …

I was quite pleased with my output and so I thought I would share it in a blog.

Remember it’s part Lunch and Learn and top tips at the same time

Story Mapping Workshop

Learning Objective

This session will give you an idea on how to facilitate a user story mapping workshop. Over time you will develop your own techniques and we encourage you to share these as a community’.

This hand-out will detail running a mock session and where you see the numbered bullets, these are top tips!

Scheduling the Workshop

Once you have an understanding and vision for your work, you are ready to start with user story mapping. These sessions are one of the first things you want to do. There is no need to produce separate requirements documents; this is the start of building your Product Backlog. If you do not have a vision, then this is something you can create in this session also.

We value face to face collaboration and so workshops should be booked to include all business and IT teams involved.

1. Ensure that you have a room with plenty of wall space.
2. It’s ok to only invite a sub-set of the IT team. However, rotate people to allow everyone to have a chance to attend. They then have the responsibility to take this information back to the teams.
3. Don’t panic if you need to have 20 people in the room to cover everything. We can cater for this, but we will need to think about how we run it logistically.
4. Consider how long people can focus for. Working for one day or short bursts over multiple days keep people focussed. With 2 or 3 day workshops, people will get tired and lose energy.

Pre-Workshop Preparation

It is important as a facilitator that you prepare for this session. You will need to:

• Print and add the Vision to the wall – We will need to ensure that we are working to this at all time.
• Print and make visible anything that is definitely out of the scope – We might want to add to this or challenge it.
• Capture Issues, Risks and Actions - Create a flip chart on the wall for each of these. It is a good idea to seek help from someone who can ensure these are all captured and owned. As a facilitator consider yourself as the conductor of the orchestra. You do not want to slow the session down and so having someone else to support with these means you can keep the session moving.
• Create straw man User Roles – You do not have to do this, but the chances are the people in the room have never ever done user story mapping in their life. This means you might have many blank faces looking back at you. My advice is to prepare a sample of these to give people some context. You do not have to have all of them and they do not even have to be correct. People find it easier to review and amend then create from fresh. If you have a fully experience group, then this can be done in the session.
• Create straw man User Journeys – The same principle of straw man user roles.
• Prepare how you are going to explain what user story mapping is in a simplistic, jargon free language. I sometimes practice this with my mother!
• Create & print a simple user story example for the wall
• Create a template to assist in the collection of user stories and data (See Appendix)
• Have plenty of post it notes and sharpies!

Let’s Run an Example Workshop

1. Take photos of everything! It’s a great reminder of what you have achieved once you have completed. It also helps you to show others when you are explaining the technique in the future.
2. Time boxes shown vary from workshop to workshop. You will need to have a think about this about this before each workshop.

The Vision

“Our research has revealed that users want a simple email experience. It should be super simple to use and not require a manual or training of any sort. People only want the basics and hate fussy screens with lots of buttons. They want this on their mobile, tablet and computer with a similar experience in each.”

• Be prepared that everyone might not have the same view of the project. This is a great opportunity to get everyone aligned.

Organise into groups

Split up into groups of 3-4 users. Each of these groups will work together from this point forward as a team. You have 1 minute!

1. Ensure that the teams are mixed in their skills; you can pre-set these before the session if it helps you.

Explain what User Story Mapping is

Many of your audience will not have completed this exercise before. You will need to explain what they are going to be doing. We can use the straw man examples to bring this to life.

Discover the Users (10 minutes)

In your groups, write a list of types of user that you envisage will use your email app. You have 10 minutes to collaborate in coming up with a list of user personas.

1. You can either the straw man or do from scratch depending on the experience of the attendees.
2. Get people to brainstorm as many as possible. It doesn’t matter if they have duplicates.
3. Walk around the groups giving support if questions arise.
4. Sense the energy and the state of completeness of the exercise. Don’t be afraid to end or extend the time box if needed.

Merge the User Personas

Each team gets to introduce one persona at a time. The other teams discard that persona if they came up with it or they can challenge the description if they think theirs is better. If none of the teams has a specific persona, everyone can discuss if this persona is useful and decide if they want to add it to the list.

Decide on the most dominant user persona – the one which describes the largest number of users for your app. This is the one we will start to create the story map for.

1. Consider using different colours for internal and external users.
2. Rationalise the names to a common list and agree that this is how you are going to refer to them from this point.
3. We use the process of diverge and merge throughout this exercise. It can be seen as duplication, but you will find that each group gets the opportunity to discuss and each group will bring out different ideas. It highlights consensus and edge case we need to consider.

Discover the User Journey (10 minutes)

In your groups, you need to think of your dominant user persona’s experience of your software. Write down a series of words that describe how they interact with your software in the order they do so, describing their journey through the software. You have 10 minutes to come up with a list in the order that best describes your user’s journey through the software.

1. Use the straw man you have available or create from scratch depending on experience.
2. Think verbs. This these are doing words at a high level e.g. Browsing, Searching, Buying.
3. Typically you will see about 10 in a user journey. Any more than this might be a signal that they have gone into too lower level detail.
4. These are not cast in stone and can change anytime. Sometimes these merge at a later stage.

Merge the User Journey (5 minutes per team)

Each team gets to introduce their journey. Each team can either place their section under and existing one or insert it between existing sections. The whole team can decide which sections have the best descriptions to create a single merged user journey.

1. Keep it fun!
2. You can either the straw man or do from scratch depending on the experience of the attendees.

This is the story journey or spine, and will allow you to organise your software features in these sections. Once the team has decided on the best descriptions and order of the journey, all of the others are discarded.

Summarise

At this point, talk about what we have achieved so far.

You will now need to introduce Epics, Features & User stories as a concept. During the next stage we are looking for breadth, not depth and so it is acceptable to collect meaningful titles.

1. You will need to consider as a facilitator where you insert the natural breaks. The next part of the exercise is intensive and you might want a break before this. Again energy of the room will be your friend.

Create the features (10 minutes)

For each section, each team takes 10 minutes to write down features they would need to create to satisfy the dominant users journey.

1. We found creating a template (See Appendix) helpful because it set the expectation of format, but we could also collect other information that would help us manage dependencies and teams impacted. This will help you at a later stage. These can be re-formatted each time you want to collet something different.
2. Get them to focus on one section at a time, rather than everything.

Merge the features

Each team introduces the features for the section that we have been working on and introduces them to the rest of the teams. If other teams have the same or similar feature they collectively decide which one to keep and the rest are discarded.

If there are features that only one team has come up with, everyone gets to decide if this is relevant and keep it if it is.

1. It is key that they own this process and so keep them active by getting them up out of their chairs and presenting back.
2. Remember you are facilitating from the back of the room. Use your domain knowledge to stop people going into too much detail. Consider If that conversation needs to be banked as part of Issues, Risks and Actions.
3. It doesn’t matter how important the person is, if they need to be moved on, move them on!

Repeat for all sections

The teams repeat the exercise for each part of the user journey until complete.

1. If you have many workshops I ensure that I gather feedback from the end of each day. If there is something we can do better, why wouldn’t we.

Repeat for all personas

Now you need to repeat this exercise for each of the other different User Personas you have starting with the next most dominant .If you are lucky, then these will fit into the existing journey. If not, then you might have to review the journey or even create a new one if the journey would be significantly different.

• It is not unusual to find many personas, but only a few have active roles within the journey. As long as you check these, then all is good.

Summarise

Take the opportunity to play back to the group what we have achieved so far. We have now got the breadth of what we need to achieve.

• Stories will get added and removed. This is all part of the process

Prioritisation

Prioritisation and slicing helps us to focus on the stories that need to be broken down first. There is no point in getting going deep on details for all the stories if they are not being delivered for several months or could get removed altogether. We want to remove as much wastefulness as possible.

You have a couple of option here

• Each team takes a column and prioritises the features underneath it. The features at the top should be the ones that we absolutely need, the ones at the bottom should be the ones we could potentially live without. Teams than then swap columns and reprioritise if necessary – any items that are repetitively moved are taken to one side for a wider group discussion. This is a good technique for large groups.
• Ask them to all gather around and do this together. Another spin on this is to them to do this silently.

By the end you will have columns of priority.

Slicing

The whole team then look at the map and discuss what could be delivered and what the minimum would look like. They use lining tape to draw a line around the stories in show a slice of functionality. The first of these would be the minimum viable product. The following slices would be increments of functionality.

At this stage we do not know how big these slices are, but it gives us areas to focus on first.

Get everyone to agree that to the best of their knowledge this is ‘it’ for now.

Closing the Workshop

This workshop is only just the start of it; I would always close the work shop with

• Consensus that everyone is happy
• A playback of all the Issues, Risks and Actions and how these will be progressed
• What the needs to be done next to achieve the lower level story information.

Further workshop might need to be booked to get lower level information or we might have enough knowledge, information and contacts to be able to draft these as Business Analysts and then gain consensus from them during the usual refinement process.

Appendix

Example template

Example template

Tweet.

I once asked a friend of mine ‘What would be the one thing you would change about Scrum?’ He pondered with that question for a short time and then responded. ‘I would change the name of the Sprint Review’.

This intrigued me and followed a conversation that reminded me of a few core principles that I had pushed to one side in my mind.

Quite often I hear teams refer to these sessions as a ‘Show and tell’ or a ‘Demo’. I had never felt passionately about a name before until I had spoken to my friend. I thought back to the sessions that I had been seeing recently and wondered, were they just a demo or were we truly collecting feedback?

The Sprint Review is actually a form of retrospective.

It is about:

• The Product Owner telling the stakeholders what it is we have achieved against the Sprint Goal
• The Product Owner advising of any key decisions that have been made in the Sprint
• The team facilitating what changes have been made to the product
• The stakeholders asking questions and providing feedback. With the team and Product Owner filtering changes back through the Product Backlog
• Confirmation of when the Stories will be shipped
• Any discussion on the future strategy of the Product
• The Product Owner closing down the session and advising the candidate stories for the next sprint

In preparation of the review the team would have completed the Sprint to the Definition of Done and spent no more than an hour or two preparing for the Sprint Review (depending on length of sprint). These are informal sessions and there is no expectation to create flashy power points.

Work that is NOT DONE is NOT SHOWN…..

As with all ceremonies, they should be a regular heartbeat and the customers know when to expect them. The same time and the same place every 2 weeks is the dream, but sometimes tough to achieve.

As a ScrumMaster I would expect the team to self-organise over the Sprint Review. I might add a task to the Sprint Backlog during planning as a reminder to the team that this needs to be prepared for.

I have once let my team fail here. In one company I got fed up of reminding them to prepare for the Sprint Reviews and so one day, I just didn’t. Let’s just say that didn’t happen again

When running large reviews, it is critical to be prepared. Often I book the meeting room 15 minutes before the allotted time so the team can go in, set up the machines and open any tabs that they might need. I am always conscious that we have lots of people and so avoiding time spent on waiting is something we can always do with removing.

If you find that you are not getting people attending the Sprint Review , then think about your advertising. As a ScrumMaster I have put up posters, gone to visit stakeholders 121, sent mails around the office, floor walked inviting people that might have an interest or dependency.

In larger organisations where multiple teams rely on the same people, then you need to collaborate and find out what would work best for your attendees. You might need to experiment with this.

Ultimately, I do what it takes to get people to the Sprint Review.

Once the team have shown the fruits of their labour, we then need to do the most important part. The part that is always forgotten……collecting the feedback.

In an organisation recently I experimented with giving them post it notes and the format

• What did we like about these features?
• What didn’t we like about these Features?
• Great ideas to improve?

They did look at me a little crazy as this was something radical to them, but it ultimately got them to think about what we had just shown and enabled the Product Owner to get valuable feedback on where to head next.

How do you collect feedback in your Sprint Reviews?

At the end of the meeting the Product Owner should then give the attendees a view of the candidate stories for the next Sprint. I impress the word ‘Candidate’ on you because they are not confirmed until you have completed Sprint Planning.

Remember, the Sprint Review should not be the first time your Product Owner has seen the work. They should be looking at this regularly during the sprint, as with bringing in stakeholders to get early sight. Nothing in a Sprint Review should be a surprise!

I am often asked ‘What do we show, if there is nothing to show?’

This is an interesting question and a great one to exercise the 5 whys on:

• Why do you have nothing to show?
     - Because the testing was not completed
  
• Why was the testing not completed?
     - Because the developers did not get the work to us until the last day (hopefully you spotted the dysfunction there!)
  
• Why did the developer not complete the work until the last day?
    - Because we did not get everything we need from the PO (Dysfunction)
    - Because the story was too big (Dysfunction)
    - Because the PO changed their mind mid Sprint (Dysfunction)

You get the picture. Remember what I about the ScrumMaster remorsefully looking to establish and remove dysfunctions of the team? There are visual and verbal clues over everything you do.

Other things to watch out for is where teams are not vertically slicing and so just delivering component parts. I also had this at an organisation recently. The question I ask them is ‘If I pulled the plug on your feature right now, what value have I got for my money?’ Because if I was truly being iterative and incremental, I would have still got something I could sell…right??

If I pulled your Sprint right now, do you have something that could still be used?

On the odd occasion there is a small config or non-client facing change, then assume your attendees don’t want to see physical code. Remember they are likely to be from the business. In this instance it is perfectly acceptable to just explain in plain English the change you have made and move on.

Another beautiful technique I saw a team do was story cards. One of the developers created it and used it to explain to clients complicated technical code changes that sat deep in a system. It was his way of articulating what they had done.

See the blog here for more details: http://tlaalt.blogspot.co.uk/2015/07/describing-value-using-situation-cards.html

Other tips

• Consider if your stakeholders are distributed having two way video so you can see what they are doing and reactions to the product.
• Consider actually getting some interaction from your stakeholders. Invite them to play with the product in real time.
• You do not need to tell your stakeholders how many story points you completed.
• You don’t have to justify why stuff was not done.
• As ScrumMasters we can help this practice to be clear, transparent and engaging to the attendees. Use the walls and visualisation to help the session.
• If the Product Owner cannot facilitate the Sprint Review as they are out of the office. Ask for a volunteer to do this the same as any other the session.
• NEVER CANCEL! I have only ever cancelled 3 in eight years and 1 of those was because it was Christmas.  If you are cancelling these, its probably because you are hiding something.

If you take one thing from this blog, then that should be.

‘The Sprint Review is more than a demo, it’s about gathering feedback, inspecting and adapting’

My friend suggestion for renaming was ‘Sprint Product Retrospective’

My friend, is the funniest man in Agile….Nigel Baker

Finally….

I asked Paul Goddard for a tip of the week. He said ‘Listen with your eyes closed, you hear much more!’

Did you know that in original Scrum books by Ken Schwaber he talks about one of the roles of a ScrumMaster was to get enough chairs for the Daily stand up?  The first pilot company also used to take significantly longer than 15 minutes also. Oh how we have evolved

If I said to you ‘The Daily Stand Up’ what words immediately pop up in your mind?

The words or phrase that pop into my mind are:

• Synchronization
• Swarming to release value

It is so easy to forget what the key outcomes of a Daily Stand Up meeting is and get caught up in the mechanics of it.

In a nutshell we want:

• Team members to talk to each other and collaborate on the work that has been committed to.
• To understand what problems are impacting us and what any potential upcoming risks are.
• What value we need to unlock from the board.
• Whether we can complete everything still we set out too. If not, there are expectations to be managed.

Did you know your most valuable pieces of work are actually the items that are waiting to be tested and deployed?  This is because we are only potentially a short stop away from benefits realisation or important feedback.  As teams we need to be focusing on ‘Finishing’ things, rather than starting new work. This might even mean that developers have to test!.  So a key outcome for me as an ScrumMaster is about teams swarming on getting whole items across the board and releasing the value early. 

There are a number of different ways to run them.  If you are in the early stages of Scrum you are quite possibly using the three questions:

• What did you do yesterday?
• What are you doing today ?
• What stands in your way?

Over time I expect teams will alter this for their needs rather than slavishly following rules.

I vary the technique depending what traits I see the team exhibiting.

1. I alter the three questions to just be.
   - What is everyone working on today?
   - What impediments or risks have we?
   - Can we still meet our commitment?  Handy to have your burn down on the board to aid this conversation.
   
   I tend to drop the ‘What did you do yesterday?’ questions as I trust that people come to work to do their best and that they are talking as a team where dependencies arise.  They do not need to justify to me what they did.  People shouldn’t feel as if they have to account for every minute of the day.
   
2. Walking the board is also a great technique and useful when you have non-technical people wanting to know when their stuff is going to be done.  This technique really helps with swarming.  This is the practice that Kanban teaches. Typically we work from right to left looking at what it is going to take to complete this work. It is an opportunity for the team to pair together to get items over the line.
   
3. If I have a team with lots of blockers, then I might just get the team to talk about these key items to see what we can do as a team to keep things moving.

I might vary running these meetings in different styles on a daily basis to get different information shared. You don’t have to do the same style every day. 

In whatever technique you run a key thing I see happening time and time again is ScrumMasters being reported to or ‘Running the meeting’

We need to think about how we can stop this from happening, They are not there to report to you!

Top Tips

• Did you know that the ScrumMaster doesn’t even need to be at the Daily Stand ups?  The team should be able to facilitate this for themselves and manage their impediments.  Pop off for a cuppa and see if you team springs into action!
  
• Don’t stand in front of the board.  We should be as standard facilitating from the back of the room and so the focus is not on us.  If you have not heard of facilitating from the back of the room….find out!
  
• Don’t call out the name of the person who you want to speak.  Use ‘Who’s next?’
  
• Use a prop such as a ball to get the teams to throw around and speak.  This helps them to decide who they want next to speak.  No one is looking at you either, because they are focusing on the person with the ball, and then not dropping it.
  
• Rotate the role of facilitator around the team, let them all have a go.  I used to play ‘Spin the pen’ and if it lands on you, then you are facilitating for the day.  If some people are nervous of this, then it’s a perfect coaching opportunity for you.  Always ensure that you give the facilitator positive and improvement feedback.

The meetings should be in a regular heartbeat and so teams know the time and the place of the meeting as standard.  The time to update the board is NOT during the meeting.  People should be doing this on a regular basis throughout the day and not just saving it up.  This will help you to keep it to the recommended 15 minutes per day.

Did you know you don’t have to run these in the morning?  Teams can actually choose whatever time is best for them.  You can even have more than one a day if you are working on critical tasks. Some teams even have them last thing in the evening so that they are set up for the day to come in and get cracking. The key is whatever ever you do the team is getting value from these sessions.

A technique that I adopt to validate this, is to ask the team members to raise their hand of they feel they are not getting value, because maybe the conversation has diverged into problem solving.  This is a sure fire way to make sure that you keep things on track.

We keep the sessions to 15 minutes to promote valuable synchronization. The chances are if they are taking longer, it’s because you are problem solving or not talking about relevant items.  One team I had used to take 20 minutes to complete their stand up.  This was fine, because the value they got was worth the time they spent together.  Try and avoid extending it out much further

If you do have lots of problem solving, then maybe your need to book 15 minutes after the Daily Stand up so the team can then brainstorm what they need to, but have a clean finish to the previous meeting.

The most powerful tools we have as ScrumMasters is observation and facilitation.  Observe what you are seeing and always challenge whether we can improve the way that we work.  Use your facilitation to guide the team and to help them decide and achieve for themselves what needs to be.

We are there as ScrumMasters to grease the wheels of the teams, reduce lead times, protect the values, principles and practices and to ensure that we continuously improve ways of working.  Quality is also at the heart of everything we do.

So reflecting on your daily stand up meeting today, what could  you do differently.

I want to thank: Nigel Baker, Geoff Watts, Bazil Arden and Alex Gooding.   I asked them all what their lesser known top tips or facts were in preparation of this article and they provided their input.

Tweet.

I have been working with a new client over the last 3 months. This has been really fun as it has meant that I get to explore Whitstable, meet new people and of course kick starting the teams on the right path to agility. If I am being honest, working with teams is a real passion of mine and the one thing I miss being an Agile Coach.

The teams and leadership here have got it in such a short time and they have come so far in the time we have had together. I always jokingly say to them ‘we have all the major impediments of a theme park and a zoo’ to quote Jurassic park, but that’s all part of the journey.  When I start panicking, you start panicking

We have had some pretty major projects going on at the same time as the move to Scrum and naturally this caused some unease about when things are going to get done.

Now I am not a tools person, I actively avoid using them on the basis that people change their behaviours around how the tool works rather than what is in the best interest of the team, but my mind has been changed recently by one particular chart.

For those that know me, know that I am not very good with excel and I always envied coaches like Dan Brown who can whip out a beautiful spread sheet full of charts and useful data. Meanwhile I am trying to work out how to add up three cells (slight exaggeration there!) So what I am about to show you is an absolute pipe dream for me.

I introduce you to…..

The Project Burn up!

Yes I know it’s not new, but it’s something that coaches and ScrumMasters have to craft themselves on spread sheets and export data from old systems…often having to access the deep dark depths that no mortals query can reach. Each person then has their own version with different formulas and there is no consistency.

The boys at ripple rock have been beavering away for the last 6 months building something that plugs into your TFS or Jira installation.

This means my clients, with a flick of a button on VSTS  can now have access to be able to forecast based on data and understand where the optimistic and pessimistic date ranges are.

They can run this on the whole backlog and for specific projects.

This has been revolutionary to them and helped them to make decisions about client interactions and live dates. It is also something they can run repeatedly as and when the backlog changes and the teams complete their work.

Here is an example.

Key points about this chart

• It provide stakeholders with a realistic expectation of when they can expect delivery of a release. It clearly shows that there are two key variables that determine the ‘Landing Zone’ for a project.  The orange bar represents the optimistic and the purple represents the pessimistic landing zones
  
• I can clearly see the scope of the work and the through put rate that we are completing at.
  

As no two teams are the same, I am given the option to change the chart settings.

To name a few things, I can change:

• The date ranges
• Sprint length
• Throughput rate
• The Scope
• Overwrite fields

This is exciting for me and for my clients and it truly is ‘Plug & Play’

So boys, you have converted me with this chart alone….(Waves good bye to excel!)

I also want to say I am proud of what you have all achieved in a short period of time.  

So thank you for creating it and my clients are already loving it.

Looking forward to the next evolution!!

(Images are taken from ‘SenseAdapt’)

I wanted to share with you one of my latest retrospectives.   Well, it’s not that new I just forgot to tell you about it

Continuing my theme of movies from the 80s, I was having a think about other movies that I love and how I could use them to drive continuous improvement in the team. 

Ladies and gentlemen, I want to introduce you to ‘Alien’. A retrospective that looks at the gestation of the creature in comparison to the sprint cycle.  You are probably thinking I am a little crazy,  I like to think its about pushing the boundaries and keeping it fresh.

Typically I print off my images, but I thought I would hand craft this time.  In the name of complete transparency I did not draw the end Alien.   I thank Richard Arpino for this.

I had 5 different stages:

• Laying the eggs – Sprint Preparation
• Sucking on face and putting in the Alien – Planning
• Everythings ok! – Sprinting
• Chest Explosion – Sprint Review
• The final Alient product – Delivery

I asked each member of the team to brainstorm their thoughts around the key themes. I used the following ‘Film relevant’ questions to help them when they got stuck.

We then themed, discussed and agreed on the final actions.  Bonus points were awarded for each film line they managed to get in.

Overall appreciation for the retrospective was high and there was definitely jealousy amongst the floor about my team always getting the best retros.

With all my retrospectives they are fun, people want to join in and we deliver real actions out the end.

Keep you retrospectives fun people!

Do let me know if you create any fun ones for your team 

The joy I get in my job is through seeing other people flourish. This means that coaching is something that I am very passionate about. When I train or mentor ScrumMasters I teach them how they can coach themselves and others for success. The skills I learnt myself and teach have come from years of practice, reading the right books, knowing the right people and going on courses.

Whilst my job title is an Agile Coach and I am there to help an organisation evolve using my experience, a great part of what I actually end up doing is dealing with peoples behaviours. This is something that an Agile method wouldn’t teach you. So where do you get this?

I came across a new book recently as I saw the author speak at The Agile Coaching Exchange. I purchased this book but didn’t immediately read it as I wanted to save it for my holiday  

Coach's Casebook: Mastering The Twelve Traits That Trap Us – Geoff Watts & Kim Morgan

The book takes a look at 12 traits that as coaches we see every day. We most certainly will have some of these ourselves, I know I do!

The structure of the book lends itself to easy reading with each chapter kicking off with a true life dialogue between coach and client. What I love about this book is that you can clearly see the coach is in a learning role themselves, because they too have a coach who they share with and receive feedback from. This to me shows the authors vulnerability and authenticity.

Once the author has established the case study, plus their thought process. They explore different models and methods to help the client, which they later consolidate in fantastic matrix to help you to pull out the right tool for the right situation.

They then conclude with an interview with someone in the public eye, who also displays one or many of the traits and how they have got where they are today.

I literally read this book on my flight back from Croatia because it was an easy read and something that I was engrossed in.

Whilst the book is not agile, the content is most certainly relevant to what we do in our profession. So those that do not get the same opportunities to learn to coach like I have, should consider this a great place for them to get insight and techniques to use.

I have a reading list that my mentees tend to work though, this is most certainly one of them moving forwards.

A great and worthwhile read!

You can find out more about Geoff here http://inspectandadapt.com

Tweet.

One of the questions I am often asked is ‘How do I sell an organisation agile? The answer is I don’t… The business has often decided they need to change because something is no longer working for them, or because their current way of thinking is no longer meeting the needs of the organisation or the customer. As an Agile Coach I do not go into a client with the mind-set of a particular method, more that I need to hear what their motives and their problems are to help them lead them to the right solution. Sometimes that might not even be agile or the method they initially asked for.

Much of the work I do is helping clients change. I am careful not to use the word ‘transformation’ because many companies do already have good practices in place as well as good people. It’s my job to help them to evolve the way they work and think in a more Agile and Lean way.

I never really know what I am going to arrive to find, and each and every organisation is different in the way it runs and is structured. Saying that I still have a thought process that I follow as an Agile Coach and I wanted to give you all a glimpse into what that is.

The easiest way for me to do this is to show you a mind map. I may not do all these items listed, but they serve as a reminder for me to think broadly about what I am trying to achieve.

The mind map that I am sharing is very much based upon a Scrum evolution. I would have different ones for different methods, Kanban for example. My mind map is also based upon my experiences and will naturally have holes.

Evolving organisations is a tough job and involves blood sweat and sometimes tears. It is important like any project you are running to have a vision. That vision will evolve over time and will likely be in stepped increments. You can’t go from zero to a hundred in one swoop. So I have a vision of all the different aspects. A vision to maybe prove that we can run Scrum in their environment, we call this a pathfinder team. The vision might also be to advance the principles and practices of your existing team. I use Evolutionary Stages for this as my vision and end goal.

Whatever change you embark on with an organisation, it is important to make sure that you understand where you want to end up and make small incremental and iterative changes along the way, banking the items you want to maintain and learning from any failure you have.  You will see one of the items on the mind map is how you communicate progress of what you are doing. This is absolutely key and one of the the things people fail at early on.  Good news needs to be published and shared.

So there is lots to think about in the mind map and so over to you. If there is something specific on there you would like me to blog about further. Leave me a comment and I will get on it.

Enjoy!

I was getting my usual taxi to work this morning and I got a driver I didn’t know. We exchanged pleasantries and then he asked me what I do for a living. I normally way up my answers, if I say Agile coach I then have to spend the next 10 minutes explaining what that is and if I say project manager for ease, that is really a lie. Today when he asked me I said ‘I help people change their lives’.

I did not say this for reasons of arrogance, I said this with a sense of pride.

There were two things that happened to me yesterday that has left me a little emotional. I am not usually one to show much emotion, but there are times when I struggle to keep it contained.

Event 1

I have been working with my client for about a year now. I call this ‘Going in deep’. Rightly or wrongly as a coach when I am in deep I form strong emotional bonds with people I coach. This is part me being their mentor, coach and then eventual their friend and peer.

I work closely with these people challenging the way they think about the work they do and how they do it. Most importantly I challenge the beliefs they have about themselves.

My overarching belief about everyone I meet is that they are a bundle of potential that just needs to be released. I will not make assumptions about them and I asked the same about me.

Most of my time my work is about building confidence in them and giving them the knowledge, tools to do their work and support.

I love to champion the wildcard and the underdog, I look for that spark in people that I know I can work with. I can teach you everything you need to know, but you have to want it and work hard for it.

Richard and Doug at my current client are my wildcard and underdog. Richard is the wildcard because he came to me as a developer with partial ScrumMaster experience and Doug as the underdog because he was very vulnerable when I met him.

I am so proud of both of them. I have seen Richard grow so much and there is so much potential there. We certainly have a coach of the future here.

But my story is about Doug, that unsure person who I first met a year go, who did not really know where he was heading or even if he was on the right path. The Doug I know today is knowledgeable, confident and completes his role with ease. Yes he makes mistakes, but so do I!

I have been watching Doug grow now for over a year and I knew it was a matter of time before he is ready to fly the nest and find his new challenge. Sometimes people need to change something to develop confidence further and to extend knowledge in a different environment.

Doug has found a new nest to fly to and I am so proud of him and the journey he has made. It makes me so happy when I see this happen, but it also makes me sad at the same time because I am seeing him go. This is why coaches should not get as attached as me, but it is part of who I am and part of how I teach, coach and mentor.

I know Doug and I will remain friends and I will always be here for him. He doesn’t know this yet, but I am going to ask three things of him.

1) Always be confident in yourself and your abilities

2) Never form beliefs about people

3) One day you will meet someone whose life you can influence. Don’t walk away from that.

My life was influenced by Margaret Morgan, my Agile yoda. Without her I would have not been an Agile Coach and I would probably still be working at Aviva.

Event 2

It was the Kanban Coaching Exchange in London last night and was facilitated by my good friend Dan Brown. I had seen this talk before and so I had one ear open, while quietly working in the background. His talk was about coaching and the comparison to what we do as Agile coaches and what they teach him as a rugby coach. I have to say that 20 minutes in I had to close my laptop and listen because in what he was saying was true nuggets of inspiration mixed with him being humble about his journey and his belief about himself as a coach. He laid himself bare and vulnerable to the audience as he talked about his experiences coaching. So why did this hit an emotional chord with me? Because I had forgotten how much influence coaches have on peoples lives. How our beliefs, behaviours and moods can influence people for the positive or for the worse. To quote a film ‘With great power comes great responsibility’

Both of these events made me take another look at my life and be thankful for what I have. It also makes me think about my behaviours and the influence I have on others.

The best bit about my job is not Agile, it is watching people flourish.

Have a think about how you influence others around you?

PS: Not forgetting my other fledglings: Ben Cooke, Gareth Waterhouse, Chris Houlden and Duncan Smith.

People don’t always understand the role of the ScrumMaster……..What is more shocking is ScrumMasters don’t always understand what their role is!

The Scrum Alliance in its literature and certified course material gives us good guidance.  I guess it’s then up to individuals and organisations to interpret it for what they want.  But all to often I meet mini project managers or people so laissez faire that the team is running rings around them!

People are obviously getting a little lost along the way.    As a coach my belief is ‘I am here to help people and organisations realise their full potential’   I do this by pulling on my experiences and a number of different methods that I practice.  When I meet ScrumMasters my mission is to make them coaches of the future. 

I started thinking about myself as a ScrumMaster and the different parts I play in the team.   I have broken these down to the different ceremonies and wider elements of the role.

I wanted to share this with you.   Naturally this is my interpretation based on my experiences of what being a great  ScrumMaster and a coach of the future is.  I am sure I have missed out many points and feel free to shout them out.

Here goes……

 Change Agency

• Seen as an Agile ambassador for the organisation - the go to guy for coaching and mentoring help on Agile values, principles and practices
• Understands trends across teams and actively looks to remove waste from the whole value stream
• Works at all levels in the organisation to remove organisational impediments
• Works with other ScrumMasters to ensure that organisational changes make sense for all teams
• Develops communities that will grow/share knowledge and skills across the organisation
• Works to grow his/her own skills, knowledge and competence that will benefit the organisation
• Remorselessly eliminates waste
• Coaches the team towards continuous improvement of quality and performance

User Story Creation

• Promotes The 3 C’s (Card, Conversation & Confirmation)
• Promotes INVEST (Independent, Negotiable, Estimate-able, Sizeable and Testable)
• Encourages use of simple language to encourage conversation
• Understands the relationship between Epics, Themes and Lower Level User Stories
• Understands Minimum Viable Products and Minimal Marketable Features
• Facilitates (if required) User story workshops using techniques such as User Story Mapping, including persona gathering techniques
• Supports creation of well written, vertically sliced and valuable stories. Facilitates & teaches how to do this using their understanding of different patterns
• Ensures User Stories are written from a customer view point
• Works with the team to drive well-formed testable acceptance criteria
• Ensures that functional & non-functional are covered
• Understands & can coach the value Behaviour Driven Development
• Looks to identify issues, risks, constraints, assumptions and dependencies from user stories. Uses techniques such as blocker clustering and adding to sprint backlog
• Drives out when a Spike is required and ensures this is a time boxed activity
• Ensures that continuous story refinement happens and that a team has seen a story at least 2 times before it gets accepted into a sprint
• Works with the Product Owner to ensure that the team has 2 or 3 sprints worth of stories ready in advance of Sprint Planning

Story Estimating

• Understands and able to articulate different ways to estimate, such as Story Points, Ideal Days & T-Shirt sizes
• Uses multiple techniques to facilitate estimating activities, such as Planning Poker, Affinity Ordering, Ouji Board estimation
• Drives conversation to deepen knowledge and bring estimate to a consensus
• Looks to establish Calibration Stories with the PO, revisiting these as work changes
• Drives the team to have stories smaller enough to enable rapid flow across the team board
• Understands when User stories need to be re-estimated as new details have emerged or been clarified
• Ensures that estimates are end to end effort – not just development

The Product Backlog & Release Planning

• Makes sure there is a Vision and all work aligns to that vision, encouraging the team to question value
• May facilitate visioning workshops with the Product Owner, stakeholders and teams
• Has techniques for helping stakeholder discuss the value of the work
• Has sight of the Product Backlog and the priority of work, working with the PO to ensure the team has enough work based on their velocity. Aims to have 2 or 3 sprints worth of work prepared at any given time
• Understand and can coach a PO on the creation, value and use of the Product Burn down
• Understands ‘Dark Matter’ and how it effects the Product Backlog growth/forecasting over time
• Collaborates with the PO to create an Agile Release Plan. Regularly feeds into plan to keep it up to date and it is shared with the stakeholders and team

Sprint Planning

• Helps the team and PO to establish the sprint length. Understands the benefits and negative aspects of having between 1-4 week sprints
• Protects the sprint length and understands patterns on why requests would arrive to break these, such as not being able to break work down and so we need a 3 week sprint
• Understands the different ways to facilitate a Sprint Planning session to get the most interactive and collaborative session as possible
• Establishes a team capacity and monitors trends
• Draws out issues and risks, following up on the resolution of these
• Ensure the estimates are agreed within the team and that no task is greater than a day to enable flow
• Ensures the delta between commitment & delivery is at the right tolerance
• Empowers the team to reduce reliance on the ScrumMaster
• Guides on uses of different visualisation techniques to ensure the team board radiates as much information as possible
• Empowers the team to make a reasonable commitment, educating them that they will need slack to be able to deal with uncertainty, as you start to do the work you discover more things

Every Day Working and Daily Scrums

• Promotes the Agile Manifesto, Values, Principles & Practices at all times
• Practices the use of time boxes to keep activities focused
• Makes sure the team has a Definition of Done that is reviewed at least every three months or when the nature of the work changes
• Call out and makes visible any team working agreements
• Works with the team to ensure they have everything required to complete the sprint
• Understands, resolves or escalates impediment. Impediments to be visible to the whole team and the wider organisation
• Understands and mitigates day to day risks with the team
• Monitors and removes wasteful activity by using a method to categorise, such as 7 categories of waste, waste snake, Kanban categories of waste
• Promotes collaboration and cross learning
• Continually understands if the work in the sprint is achievable using charts to support. Such as the burn down or the cumulative flow diagram
• Encourages swarming as a practice in the team to ensure the team is focussed at all times on delivering the most valuable story first, to the definition of done
• Protecting the team from outside distractions
• Facilitates the Daily Stand up Meeting using the traditional three questions or walk the board style
• Encourages team ownership of the visual board and recognises if flow or blockers are happening across the board
• Understands and can coach when engineering practices can best be used
• Is mindful if the team is creating technical debt. Working to eradicate this and to reduce any existing in the team/organisation
• Understands and monitors the quality of the work.
• Observation is a key tool to understand the dynamics of team
• Coaches and supports the team towards the goal of the Sprint

Reviews

• Creates an environment where the review is a collaboration of all team members
• Enables the space for the team to prepare the session, providing guidance on how effectively they can use the time and make the sessions valuable
• Works with the PO to advertise and promote stakeholder attendance, such as posters, emails, social media, dragging people away from desks to drum up attendance
• Actions and additional stories are capture for consideration and actioning
• Ensure the team receives the required recognition for the work they have achieved
• Drives cross team knowledge sharing by publishing the teams achievements
• Understands root cause analysis of any potential delta between committed and delivered stories and supports the team to put actions in place to reduce this.

Retrospectives

• Keeps the format fresh and provides the appropriate type of retrospective for the situation at hand. Such as deep dive, broad, milestone
• Facilitates the session to include the maximum amount of participation from the group. Get them up and active and gather insight
• Facilitates from the back of the room to utilise reading body language and tone of voice to drive out things left unsaid
• Practices root cause analysis such as the ‘5 Whys’ to help the team drive to what the challenges really are.
• Practices ‘Powerful’ questions to drive out learnings and improvement opportunities
• Drive the team to continuously improve working practices, taking actions from each retrospective to complete in the next working period
• Makes a record of the outputs of the session and ensure that points are not just forgotten, but banked for future retrospectives. Such as creating an improvement backlog or agreeing with the PO to have these in the main backlog
• Works to remove actions that are low hanging fruit to support the team
• Monitors team trends and shares these with other teams to identify organisational trends

You can see there is lots and I am sure I could have kept on writing

Final Thoughts

I want you to thinking about the role you play as ScrumMaster and ask yourself:

• Do you do the majority of these things?
• What can you do differently to maximise your contribution to the team and the organisation?

ScrumMasters need to continuously improve, the same way we expect our teams to. ScrumMastery is a leadership role and we all need to step up to that.

For my sins I love Bon Jovi!  Maybe not so much the recent stuff, but they have some real classics.  I have seen them in concert many times and I have to admit they are a real crowd pleaser and play for about 3 hours.

Whilst thinking about my teams retrospective this week and the fact I like to inflict upon them my sad hobbies and obsessions, I decided to do one on Bon Jovi.

I am going to keep sharing these with you because I want people to experiment and try different ways of helping teams to continuously improve.  They can also be fun if the sprint has been a hard slog.

Here are the headings that I used.  

I rated moral as follows:

I did have the music playing to motivate, but we did have one anti Bon Jovi fan.  I might do AC/DC next as that is his favourite band.

I gave the team extra kudos if they could get song titles in their thoughts and comments.  Ultimately we ended up with a set of actions for us to take forward in the next sprint.

If one was not enough…

I did a second retro this week for a different team.

The team has recently merged together with another team and are still looking to refine their ways of working together, and so I wanted the retrospective to be based upon how they work as a system.

I used a Scrum Image and asked them to use sticky dots to put where they thought the problems lie. They got two green dots and a red dot with signified a major problem. Green dots are still issues in this example, just not as bad as red.

I then got them to give me the headlines of the problems they encountered. An example of this might be ‘User stories are not coming in regularly enough from the clients’.

I got the team to then break into three groups and we used A3 thinking to look at the problem and come up with potential counter measures.  A3 thinking is great because it means we can post them on the team wall and then validate the learning's at the end of the next sprint.  I also wanted to teach them a different technique and really get them thinking about the challenges we have have.  Quite often the problem in front of us is a symptom of a deeper root cause.  Techniques such as the 5 whys can help the team delve down.

All in all I had a great couple of retrospectives this week.    I will need to keep an eye on the teams as sometimes actions do get overlooked, but a little poke every now and again ensures that they keep driving them forwards.

One of my ScrumMasters come across this great website on retrospectives. It is worth checking it out for new idea.

Keep improving people!!