I love building teams! I cannot lie…I have always had a passion for this and something I take great enjoyment in. It can be any team ranging from a guild, a chapter, leadership to development teams.  To me these are all little eco systems that have to be shaped to achieve the goals of the people and organisation. Kicking off teams correctly forms relationships and set the working agreements to help shape us.

Earlier this week I told you that I was hosting an ADM away day. Well I used this opportunity to run the canvas exercise once again.

What is the Canvas?

So how did I run this session?

So my thinking has really evolved in the last 6 months and I now run it completely different, but hey that’s evolution! I started off the team thinking about their individual values through  the Real Deal exercise I blogged about earlier in the week.

I then got them to think about what they bring to the team or super powers as I like to call it. Also what their aspirations are and who they most admire.  To make this easier for them I created a handy little template.

I gave them a few moments to have a think about content and then I give them a time box to go around as many people in the group and share this knowledge.  This part gets really noisy and is super fun!

So by this point in the session they now know a good chunk of information about their fellow collaborators and have really started or deepened the team cohesion.

From here I used to take them to the purpose statement, but I found even the best teams struggled to do this straight away,  and so instead I ask the to brainstorm the values they want within the team.  Now …they will come up with many and so use techniques such as dot voting to pick the ones that are most pertinent.  I usually create this into a word cloud and include in the write up.

Next we brainstorm all of the goals we want to achieve. Simple brainstorming and de-duplication works well here. Remember they are goals and so the team needs to be able to measure them.

Then the purpose By now they understand who they are, who the team are and what we want to achieve.  I find the old classic diverge and merge works well. I literally gave the 5 minutes per group per round.  Amazing what you can achieve in such a short time.

After a bit of final word shuffling..we had our purpose! Success!

Finally we moved onto the way we want to work.  You can facilitate this in a number of different ways but I have been favouring a good ole user story of late.  Let them know the problem statements and who we are serving and then let them decide for themselves how they want to work. Then set the terms of the experiment and give it a go!

All in all I can typically get teams to define this in 90 mins max. Usually 60 minutes if they are an existing group.

After this we then write up and make really visible to absolutely everyone. Sadly I cannot post a fully completed one, but here is the style I usually use to make it fun and engaging.

I typically get large posters of these printed  (£10) and get everyone in the same room together. If I am distributed I find the tool Miro works the best.  In fact, Miro is awesome for retros too! #notsponsored

With anything, as a group you will need to evolve this overtime.

So I hope this has given you another tool to put in your box. Go out and experiment! If you can think of any other cools techniques to facilitate this session. Drop me a line.

Enjoy

x

72 Days till Christmas! My favourite time of the year

Last week I was helping my current client organise an away day for the ADM community. This was really important to me as it was the first time we had come together for a such thing. We finished off the event with some Axe throwing… which was epic!  I can really recommend it as a team building activity. Here are a few photos of the fun.

I wanted to share with you a kick of exercise I completed. The history of this exercise dates from when I was working at AVIVA. It was one of those things I remember doing wondering what the hell was going on! It was not until many years later I realised the powerful value of this to teams. I have done this at many clients now and always get positive feedback and learn a little something along the way.

The exercise is called the Real Deal. It comprises of a deck of cards which each contains a word. You lay these cards out and ask each team member to pick 4 cards that represent things that are important to them at work. Card examples include things such as trust, autonomy, rewards etc.

You then ask them to each pick a deal breaker. This card represents the one thing that is most important to them and that if this thing is broken, then they effectively checkout.

Let me give you an example of mine:

• Autonomy – I like the freedom to be able to innovate and get on with my work. I don’t need to be controlled or monitored. When I am no longer delivering value, I don’t hang out my contracts I leave. This is closely linked to my second choice.
• Integrity – I have strong values in myself and my approach to work. I can only be myself.
• Respect – For myself and others.
• Learning – I like to continue to learn. If I am doing the same ole things over and over again, then I will lose interest.

My deal breaker has to be:

• Fun – You spend so much time at work, when did have to be so serious?!? So I like fun, laughter, social events and spending real time with people getting to know them. This helps break down barriers, but can also help you make some friends for life.
  
  

As part of the exercise we discuss:

• How will we know if your deal breaker has been breached? What will we see or hear?
• What can we do to change this situation? What would you like to have happen?

I typically run this exercise with the whole group standing in a circle so we can give each other the full attention we deserve. At the end of each contribution I take the opportunity to thank them for sharing.

I find that this exercise helps to form teams by getting to know each other at a deeper level. Understanding each others core values will show how we are all in fact different and need to be treated and respected differently. Maybe someone needs more praise than others, maybe someone needs to feel more empowered than they currently are. The result being a more close knit and aware group of individuals.

So this is a really simple exercise that can support groups that need to work together for any goal.  You don’t need any fancy decks of cards, you could write these words on post it notes and achieve the same effects.

Surprisingly my values have changed very little over the last 7 years (since I first did this technique).  Fun has always been my deal breaker. Remember this the next time we meet

Why not give this a try and let me know your results.

Enjoy

x

Tweet.

I know, I know..I promised not to leave it so long. Where do the days and months go!?!  Here are a few photos from things I have been up too.

Running Kanban University Train the Trainer Classes

Running Conference sessions at London Lean Kanban Days (Soon to be at Agile Lean Brighton)

Running Public Kanban Training Classes

Coming up with Crazy Retros

Attending more pure coaching Conferences (with my buddies)

Starting an AWESOME new client

And turning 40!!  What happens in Vegas, stays in Vegas…

There is more, but I will spare you my full years history. Other amazing news - You might have seen that I have now achieved my Certified Enterprise Coach license through the Scrum Alliance. This was super exciting for me, but I will not lie and say it was easy. That Barefoot coaching course certainly came in handy there. Finally I made it on to the top 50 shortlist for the ‘Most Influential Woman in UK Tech’ for the third year running. I am honoured I don’t need to win, the fact I am on it is enough for me.

Anyway, that’s enough about me.

A while ago I wrote a blog called ‘Being A ScrumMaster’ and it’s only now I have got round to thinking about ‘Being A Product Owner’!  Most of my blogs are sparked off by someone asking me something in a training class or with a client. This one came about because I was asked to present at a Product Owner Guild the role I thought Product Owners played. I obviously have my views but I wanted to take the opportunity to have a refresh on the Scrum Guide and see what they say. In my opinion it is rather lacking in detail, but understand it is up to the organisation to interpret this and do further study. I did validate my thinking with my good friends Mark Summers and John Barratt. John said he would score me an A- which I thought was a bit harsh!

As I like to share all my thinking with my lovely blog followers,  here is my work. Feel free to use this and share, but also tell me anything you think I am missing.

Happy New Year everyone and apologies for not blogging in such a long time. I don’t know about you, but I have no idea where 2018 went!  It seemed to speed past so quickly..

I have been busy with a relatively new client and was due to be there a couple of days the other week when ‘The Boss’ called up proclaiming  ‘man flu’, and wanted me to support him on his Certified ScrumMaster Class. Now, I don’t really buy into ‘man flu’ but he was a pitiful sight to behold, and so went along to do some of the heavy lifting. It’s been a good few months since I last trained Scrum, but it all came flooding back to me   It was while there that I got the inspiration for this blog. I met a man who was literally starting as a ScrumMaster 9am the day after the course, and he wanted to know what needed to be done in his first few days and weeks.   So I reeled off a few things for him to consider and then wrote him a nice poster with all the details on to take away. 

I have not heard from him since the class, but I am hoping everything has worked out for him!

I thought other people might be interested in this and so here I am blogging about it.  I have taken the liberty to expand on some of the points. I was going to make a mind map, but all the ones I tried would not let you export an image for free  

Stage 1 (First few days and weeks)

• Meet the team and get to know them and what they want to achieve. Agree regular 121's to keep the conversations flowing.
• If the team is already up and running, spend some time observing.
• Organise a team building event. Encourage team members to get involved in the organisation.
• Has the Team used Scrum or Kanban before? Do they need to have some sort of training?
• Meet the Product Owner. Get to know them, their history and what they want to achieve. Discuss both of your roles and what you expect from each other. Discuss what to do if you do not agree with each other.
• Discuss the product with the Product Owner. Understand the Vision, roadmap, commitments, issues and risks.
• Review the Product Backlog. If it does not exist, we need to help facilitate creating one. Do we need to complete user story mapping?
• Set up regular sessions with the PO to keep collaborating. Encourage them to sit with the team.
• Does the team sit together? If not organise this. Ensure that the team has either a TV or visual board.
• Create an initial board to start putting work on. This can be refactored as you get the team up and running.
• How does the team store information? If some form of wiki, SharePoint or other doesn't exist. Think about creating one (after discussion with the team)
• Facilitate getting a team Definition of Done.
• Set up Sprint or Cadence structure in diaries. Plan for more refinement sessions if the team has to create the backlog from scratch.
• Set up a holiday chart and make visible in the team space.

Stage 2 (Coming weeks and months)

• Understand 'other' teams, people or third parties we might have dependencies with. Meet these people and agree ways of working.
• Create a stakeholder map and plot all of the key people on. Plan how you can meet all of these people.
• Understand Staff Liquidity. Implement knowledge share as needed.
• If using Scrum, think about creating calibration stories for referring to in estimation sessions.
• Set up team metrics (CFD, Burnup, Burndown, Lead time Distribution, Defect ratio, Waste, Work in progress, Net flow, Live status, Bugs, time to deploy, % automation, % fails of automation, build times, ticket age, throughput rates.
• Consider if we need to create 'End of sprint one page' report for stakeholders.
• Refactor the Board. Think about how to visualise: Blockers, Avatars, waiting, dependencies, issues and risks, different types of work, expedites, defects, WIP limits, capacity allocations, abandoned work, external teams collaborating with you (to name a few)
• What engineering practices do we need to consider and implement? Understand what is done now and work with the team to define where we want to be.
• Understand what the release process is, and the frequency of this. If people are involved outside of the team. Become their friend!
• Understand current state of play for : Tooling, environments, levels of automation, CI/CD strategy, testing strategy, Source control, coding standards, online tool such as VSTS or JIRA.
• Work with the Product Owner to create a Release Plan and any metrics they need to help manage flow of stories, value and delivery.
  
  

I am sure there are things missing and so feel free to leave comments for other people to get the benefit of your knowledge as well. I can then add them in for an AWESOME list!

I will try and not leave it as long next time.

To quote Jerry Springer ‘Look after yourself, and each other’

Helen

xxx

Whether you use Scrum or Kanban as a delivery method, as a ScrumMaster you must be able to help the team or organisation understand and use the methods or frameworks.

This involves an element of teaching, coaching and mentoring. I have already looked at one way I have been establishing a coaching stance at my clients in my ‘Coaching Dojo’ blog earlier this week. Now I want to share with you something that Carlo Beschi and I put together for a conference and now subsequently using to help people become better trainers within the same organisation.

I regularly train non certified Scrum Classes and I am also an accredited Kanban trainer for the LKU. In fact, I am also a Train the Trainer for the LKU (ooooooo I hear you say! )

This means I spend lots of time thinking about how to convey messages in a simple and fun way, that everyone gets and can practically take back to their work places and start using.

I am one of the first people to turn off with my three second attention span if you just talk at me. Equally if you want me making random shapes with my body, then you are going to lose me too. For me it’s about getting the right balance of the two and really thinking about who your target audience is and what you want to get across.

I have seen many great trainers over my years and love the Sharon Bowman’s ‘Training from the back of the room’. So when Carlo and I put together this offering it was a blend of all of our years experiences and what we have learnt from our own training and research.

Our strategy was to include as many good and bad practices as we could . If the students could recognise them in us, maybe they could recognise them in themselves. To help facilitate this we created Bingo cards and of all the techniques we were planning on using in the session. As soon as they had a row, we encouraged them to shout ‘Bingo’. Not only was it educational, but it meant they kept focused throughout the session and had a little fun along the way. We rewarded winners with chocolate.

The first half of the deck is sharing different thoughts and practices for running great training sessions. You won’t get this sense from the deck, but throughout the class we were using all the different techniques we were talking about so they could see them and experience them in person. 

The second half is about handing over the reins to the attendees and getting them to put into practice everything that they had learnt over the course of the session.

We gave them a time box to go away and plan a mini training session and we had 2 decks of cards for the topics, normal ones like story points and user stories and then wild cards which are harder topics such as probabilistic forecasting.

You will see in the slides that there is a lot more content around them than just words on a page. Apologies, but without writing a whole book this is hard to convey.

Carlo and I first run this at the Agile Tour and we got some really great feedback from the attendees. Now I have adapted it further and we are going to use it to facilitate a half day session at my client to train people in preparation for a software craftsmanship course, they are planning on running internally. We hope that they also take many practices into the sessions that they are about to write and plan.

Our slides are in the public domain and you can find them on my slide share here: https://www.slideshare.net/helenmeek/effective-teaching-v20

Maybe have a think about how your communities train each other and whether there is any value from any of the practices that we call out. Don’t forget that the practical element of any training is extremely important, and so that’s why we have included it with the provision of valuable feedback to the students.

I know so many great trainers from my peer group who I admire. I took the opportunity to contact a few of them and ask them for some of their top tips. Keep an eye out for these in the deck and thank you to everyone who contributed them.

I wanted to share these slides with you because I feel it’s important to help grow and harness the expertise in our industry. Together we have so much knowledge and by creating a sharing culture we can truly become awesome and transform the world of work.

Thanks again to everyone who was involved in this and special thanks to Carlo Beschi my co creator.

You never know, we might run it again at conference near you

I wanted to share with you a blog by my good friend Doug Idle. It is about a conference session that we created together for London Lean Kanban Days.  I was going to write a blog on this, but I thought his was already perfect. I am very pleased to share it with you. Enjoy x

I recently had the opportunity to attend a two-day course on Kanban (KMP2, for those in the know) taught by the fabulous Helen Meek (Accredited Kanban trainer and all-round Agile Coach). Knowing my love of all things Lego, Helen asked if I’d be interested in working together to find a way to demonstrate the scaling of Kanban and some of the KMP2 curriculum in 90 minutes rather than two days using bricks. We targeted presenting at the London Lean Kanban day in April.

We knew that we couldn’t teach the entire curriculum in 90 minutes (there’s a reason it’s a two-day course) so we decided to concentrate on six of the seven cadences in the session. We wouldn’t cover the Strategy review because it was just to big to fit in to the session and isn’t covered in KMP2 either. What we would cover would be:

• The three delivery cadences — the daily standup, queue replenishment and delivery planning
• The three improvement cadences — the operations review, service delivery review and risk review

… and we’d do it all with Lego!

We asked the group or 30 to self organise into teams. One member of each team would be the Service Delivery Manager who would be responsible for:

• Facilitating key meetings
• Supporting collaborative decision making
• Sequencing and scheduling work
• Helping the service understand its performance
• Working to improve the overall service
• Collecting data using the supplied lead time chart template
  
  

Each team would be responsible for constructing one part of a plane — either the fuselage, undercarriage, wing or tail. Each team was provided with the exact set of parts they needed to build all of their components, Lego style step-by-step instructions, a Kanban board and a set of laminated order cards.

After the teams had been setup and the SDM was ready to go, we kicked off by giving them a one-minute Daily Standup (the first cadence) and then building us one red, one blue and two black planes in four minutes. After the first run and a short retrospective we gave the teams their first opportunity to scale out by introducing dependencies between them. To reflect the dependencies, we gave them a new Kanban board to use.

At this point, we introduced the second cadence: Queue Replenishment. In this cadence, teams decide what to select from the pool of options. By moving work to the ‘Ready’ state they are making a commitment to complete it. Under normal circumstances, the meeting is no more than 30 minutes in length and would include key decision makers and stakeholders. Most teams will run a scheduled queue replenishment meeting — although on demand replenishment is desirable, it is often hard to coordinate. We gave our teams three minutes to run their queue replenishment and coordinate with each other.

After giving the teams another set of orders, we started them on their second run (a daily standup and some building) along with a retrospective afterwards. After the second iteration, it was time to introduce the third cadence — the Service Delivery Review. In this cadence, we look at whether or not we are delivering according to customer expectations. We look at a single Kanban system and include key people from each activity (dev, test, analysis etc.). The group compares current capabilities against fitness criteria metrics and seeks to balance demand and risk. The session is typically 30 minutes in length. After conducting a short Service Delivery Review, we asked the teams to scale out again — this time with all five teams forming a single service. On this occasion we didn’t provide a board since testing of the game had shown that the teams had outgrown anything other than a full scale whiteboard and we weren’t able to carry one around for the session.

During each scaling out session, we asked the teams to consider their policies, review their work in progress (WIP) limits, working together agreements and delivery lead times.

The Delivery Planning meeting was the fourth cadence we introduced. Here, we plan what can be delivered and form a commitment to our customers. Issues about delivery are raised in this session, solved and/or taken to the Risk Review cadence. Key attendees will include anyone who accepts the deliveries or is involved in the logistics of delivery. Specialists are present for their technical knowledge and risk-assessment capabilities. This is a decision making meeting and could be 1–2 hours. We conducted a five-minute delivery planning meeting where we asked the teams to estimate their percentage confidence in the third iteration orders we’d just given them.

For the third iteration, we introduced two new classes of service — a plane which had to be expedited and another which had to be completed by the end of the iteration as well as a fixed date plane, which had to be delivered by the end of the fourth iteration. Once more, the teams had five minutes to build the planes including a one-minute daily standup.

At this point, we introduced the fifth cadence, the Risk Review. In this, we look at problems that put our delivery capability at risk. Anyone with information, experience of recent blockers or managers from dependent services may be in attendance at this meeting. As a result of the session we may review the assigned Class of Service and/or explicit policies. Techniques such as blocker clustering can be used to analyse the work. Sessions can be 1–2 hours in duration.

We then kicked off the fourth and final iteration, asking the teams to build us 12 planes — four of each colour.

After the last iteration, we introduced the Operations Review. This is a ‘Systems of Systems’ level review and would be facilitated by a senior leadership team member. Here, we review the demand and capability for each system with a particular focus on dependencies. Improvement suggestions, actions, decisions or required changes to strategy with designated owners are the key outcomes of this meeting. The duration can vary depending on the number of services. With a large number of attendees, it could last up to two hours.

Although it is no substitute for the KMP2 course, the 90 minute session does give a really good look at six of the seven cadences, as well as giving attendees the opportunity to put them into practice.

After our successful outings at the Kanban Coaching Exchange and the London Lean Kanban Days, Helen and I are looking for opportunities to run the session again — so hit me us if you’re interested.

Doug Idle is a Senior Agile Delivery Manager. When he’s not delivering awesomeness he spends his time listening to Guns ’N’ Roses and rocking stages with his Velvet Revolver tribute band.

Tweet.

One of the key areas of my role I am super passionate about is people! They are the highlight and sometimes the lowlights of each of my days. But ultimately by loving, cherishing and harnessing their awesomeness, we can do great things in communities. I also think about my role sometimes as throwing a pebble into the community pond and the waves and ripples that come out carry on with them.  Deep for a Monday I know!

I wanted to share with you today one of my little pebbles that I kick started with my biggest and oldest client. For those that know me, you can work out who!

The History
Many years ago I hosted a meet up group with Rachel Davies where I saw her run a coaching dojo. I enjoyed it immensely and saw endless possibilities with it.  So, I took this format and experimented with one of my insurance clients at the time and had some great success with this, and I saw how it really helped the ScrumMaster there grow.  This is the same place I met my good friends Richard Arpino and Doug Idle. If you like they were my original lab rats  

Why I am passionate about Coaching Dojos?
I see many role disciplines in my career revert to the old classic of, you tell me your problem and I will solve it for you. We know this is not the optimal way of getting people to think for themselves and ultimately people know the answers deep down, we just need to help them unlock it.
So in the coaching dojos we give people the tools they need to unlock potential and ideas within themselves and each other. I have seen managers become less tell and more coach, which reduces burden and increase the ability for leadership and the coaching of others. I love that ‘A-ha’ moment when my students use it for the first time in 121 or retrospectives,  and they come back beaming from the results. I have run these in many organisations, but often run also at the London Lean Kanban Days conference.

What is a coaching Dojo?

Each dojo has a time box e.g. 10 minutes and we ask people to bring real life situations they need help with. Work or personal is fine and we have strict confidentiality rules.
We introduce different models and give people the opportunity to practice these.

You have three roles:

• The Seeker –  Person needing help
• The Coach – Person to coach
• The Observer – Provider of feedback

At the end of the time box we ask for feedback from the seeker, coach and observer (in that order). By doing this the coach gets the valuable opportunity of feedback and this can really shine a light on some of the bad habits we have or don’t even know we are doing.

What types of habits do you see commonly?
This is not an exhaustive list, but can include:

• Not really listening. Maybe thinking about new questions or solving the problem while the seeker is speaking.
• Butting in when the seeker is speaking
• Trying to give people the answers to their problems
• Using cognitive bias on situations
• Lack of patience or self awareness of what your body is doing

The Coaching Dojo is about teaching you awareness of yourself, different models to use and a coaching mindset/stance. It is a great playground to practice safely in.

So how did you scale this?

Originally with my client we opened coaching dojos up to 65 ScrumMasters, and for at least a year we ran monthly 1 hour sessions where we would introduce different models and practice. However we wanted to make this more of a rolling program and something a little more formal.  We also didn’t want to limit it to just the ScrumMaster community, because developers, testers, product owners, you name them! Can get value from these skills.

So we created a 2 month program and kicked if off with a taster session so people can drop in and see if it’s something they want to do. Each 2 month program is a commitment and so the expectation is that they will commit to 1 hour per week for the duration.

We had lots of learnings along the way:

• Originally I had about 4 sessions a week and it was getting crazy, and so I sought the help from my good buddy Richard Arpino and Chris Toby to help organise. My long term goal was always to hand this over the organisation to continue without me. The real test of success!
• We also had lots of no shows which is very frustrating, but since we changed to a 2 month program we have found this to be so much better.
• People were always very compliant in sessions, rather than difficult as some can be. So when this happen the lead coaches step in with example.
• Keep the groups static as this builds trust in the peer group. You also find they start working closer with each other in the wider business.
• We run small groups of 4 people, this allows one person to miss a session. We keep them small so we can focus on individual growth, rather than sheep dipping.

We have had so many learnings along the way, and this is really about experimenting and finding the right fit for the people.  But something must be working as we have a waiting list now!

So what is the curriculum?

There is now a formalised curriculum and we created a knowledge bank where people can go and see useful information about the models and coaching in general. Plus an internal coaching Facebook page where we put daily words of wisdom and new ideas they can try. We have book recommendations and are encouraging people to practice as much as possible.  The lead coaches can then support and debrief any difficult situations when they take these practices back to the teams.

Our topics:

• Powerful Questions
• GROW Model
• The 5 Whys
• Active listening
• SARA Model
• DESC
• Dealing with difficult people
• CIGAR Model
• Contracting in Coaching
• OSCAR Model
• Clean Language
• Real Options

It does seem a lot, but each program is built from a subset of these and we are adding more all the time. Especially as I am on the Barefoot PG course

Each of these modules have supporting documentation and we may spend more or less on one than others, depending on experience in the group.
We also have different stages of groups. The first 2 month program is level 1 and 2 and so developing.

So what next?

We want to launch a level 3 which looks deeper into the art of coaching people and more practice of course. We are thinking about doing these in larger groups as they have already mastered the basics. We need to work this out and so ideas are welcome.

So we scaled by putting a program in place and by having three people that can run a max of three groups at any time. We could add more lead coaches, but we found scarcity made people invest in this more! I believe we have trained about 100 people from all different role types.

For the last two months I have pretty much handed everything over to Richard and Chris.  I just pop along when they need help or I have some free time. I leave them for pastures new in a week or so, but I know I have left in strong and capable hands. Plus I look forward to seeing how they can advance the program further.

There is so much love for coaching dojos in this organisation and I see how it has made a difference in the communities here. 

I look forward to my next adventure, when I can try something similar/new like this again.

Call to action!

So what are you waiting for? This is something you could set up and try with little investment. If you want some help or advice, please get in contact and I will support you however I can. I look forward to news of your experiment.

If I asked you what feedback loops you used, I could pretty much guarantee that your top answers will include retrospectives and daily stand ups. This isn’t an uncommon set of answers, but there are so many more feedback opportunities out there that you are potentially missing.

I first discovered this whilst running my Kanban classes and I started to have a think about what I could do about this and to get more knowledge out there.

Most days I have lunch with my good friend Richard Arpino and we like brainstorm all of our new ideas. Some are a little wacky!

Richard had never spoken at a conference and so I thought, why don’t we combine our ideas and present something at London Lean Kanban Days (LLKD17 - one of my favourite conferences).

As children we both loved the game top trumps and as soon as we said it, we knew that it had to be the premise of our talk!

Our idea was to brainstorm all the feedback loops we could think of and to create cards that have stars for these categories:

We also wanted to list all the pro and cons so people could make informed decisions on whether this was the right feedback loop for them. We had totally underestimated this task and the cards became a massive focus over the coming months. It’s fair to say that I was cracking the whip with Richard.

So we came up with the following feedback loops for our cards

• Waste Tracking
• Pairing
• 121s
• Retrospectives
• Source Control History
• Build monitors
• Tests
• Performance Tests
• Monitoring
• Daily Stand Up
• Behaviours
• Other Teams
• Bugs/Defects
• Incidents
• Reviews
• Code Reviews
• Customer Feedback
• Visualisation

We could have continued on for many more, but we thought this was a great set to start with!

We want to thank our good friends for helping us create these. Doug Idle for the images and Vlad Mihailescu for organising the printing.

We were very pleased with the result!

We wanted the talk to be a workshop and centred around the people we had in the session. We have created these cards, but it doesn’t mean we are right. It’s just the context that we are both working within at the moment. So the idea of the workshop was that we do a little introduction and then we have big posters of blank top trump cards around the wall. The group would then fill them in and write the pros and cons.  This would get them talking and sharing knowledge, but also validate our thinking and help us update the cards as well.  The power of many brains!

We had a great turn out for our session with around 25 people. We even got a mention for the loudest session of the conference!

You can find the slides from the session here

At the end of the session we gave the audience each a pack of our cards so they could take them away to get inspiration and play the games with their organisations. We have given out all the cards now, but we are already revamping with version two ahead of our slot at Agile in the City in June

If you didn’t manage to get the cards and/or wanted to keep an eye out for updates, or give us more feedback we created a website so you could continue to be in the loop. You can find the website here.

Overall after months of preparation we were very pleased with the result and Richard was a great choice of partner. He rocked his first conference talk!

You can hear even more including our favourite feedback loops on my latest ‘Kan Do Attitude’ podcast

Keep an eye out for us at other conferences and you never know, we might have more cards with us.

Also at LLKD17 I ran a coaching dojo. Here are a few pictures from that.

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!’