Posted in Games

Ultimate Agile Games List

"Adults shouldn't play games at work."

It would be easy to think that playing games together is something that we should have stopped doing when we became adults and took on jobs and responsibilities. Games are important for children as they teach social, communication, and tactile skills, as well as many others. But as adults we should learn skills through PowerPoint presentations and reading documentation, right?

I mean, you can do if you want to.

But how many times have you daydreamed your way through a training session, or skim read some documentation because it doesn’t interest you?

There must be a better way!!

I'm a big fan of games.

Why not use games in our every day work? Games have all sorts of benefits for teams, and individual growth.

Many classic games are designed to teach us new skills in a way that is more engaging and allows us to immediately apply these skills to a simulated situation. These are key games in any Scrum Master’s toolbox.

Some games are ways of helping our brains process, sort, and act upon information. Retrospectives are chock-full of games (or exercises if you will) that allow us to understand the previous sprint and collaboratively figure out a way to move forward.

Others are all about fun. It may look like an excuse to mess around and not do work for a bit but I have seen teams gain insights, skills, and camaraderie from playing them. Laughter is a powerful tool at removing hierarchy, promoting safety, and boosting morale, all of which are key to a great Scrum team.

But what are these games?

This blog article is to introduce you to the ULTIMATE AGILE GAMES LIST which is essentially my list of all the games I have used or want to use in a google spreadsheet. (Note: I just used the title ‘Ultimate’ to sound cool, I have no accreditation to prove it is).

I am in no way creative enough to have imagined all these games for myself but as many people working in agile also love games there are so many to choose from. Lucky me! I often find myself spending hours browsing through websites and books looking for new ones to try out or ones that fit a specific purpose.

In respect of these wonderful people who create these games I have only included a summary in the spreadsheet and the link so that you can visit their site and show them some love for the game. For books, I have included the title.

Tell me more about this list!

The spreadsheet is a couple of tabs; the first being the full list of games, the second being retrospective focused.

I have added some filters into the spreadsheet to help find the right game for the context. The retrospective tab divides them into the steps that Esther Derby and Diana Larsen wrote about in their book in the same way that the phenomenal tool Retromat does. (I just wanted a space to hold my notes and which I could add to.)

And that’s something I believe you can do too with this spreadsheet! Copy and paste the spreadsheet into your own Google Drive and add your own notes.

There's a game missing!

There are so many amazing games out there. Please put in the comments below any games you want added to the list. I would love nothing more than to try out some new ones!

ULTIMATE AGILE GAMES LIST

Posted in Scrum Add-ons

BDD and Three Amigos

Overview

Towards the end of 2018 I went to a workshop at Agile Leicester on Behaviour Driven Development (BDD) and Three Amigos. This article gives some references about where you can learn more about these techniques and then continues through the introduction of this technique to a team and the results that were achieved. I gave a talk back to the Agile Leicester community on this subject in early 2019 and the picture above is of that talk.

 

Motivation

The stories we were using were closer to contracts than stories

 

Research

I went to a workshop about BDD and Three Amigos at Agile Leicester given by Stuart Day.

Articles that summarise the practices:

Refresh on what stories actually are:

  • User Story Mapping – Jeff Patton
  • User Stories Applied – Mike Cohn

Jeff_Patton_Slide

Starting Point

  • We were keen on using the brilliant minds of all the team members to create the vision and to be a part of creating the solution rather than developing exactly what was written.
  • Our stories had lengthy acceptance criteria that weren’t focused on the user needs and stipulated exactly what the solution should be leaving no space for creativity.
  • There was not enough room to question, influence, and negotiate in the stories.

 

Experiment Hypotheses

By using BDD and three amigos we would:

  1. Focus our communications on the value to a user of a feature and the behaviours that would help us ultimately achieve that value
    1. This would support us in negotiating and sharing solution ideas, moving away from it being pre-decided
  2. Spread the understanding of the story through the team and enable empowerment
    1. This would allow the team to make decisions on the solution with the Product Owner
  3. In depth behaviour discussions would enable pragmatic approach to MVPe
    1. This would allow us to deliver smaller increments of working software to allow feedback

 

Method

To achieve our hypotheses we had to change how we worked.

BDD_and_Three_Amigos_Method

Story Writing

  • First thing to change was how we wrote stories. I worked with our Product Owner to refocus the stories back on what the User wanted and only that. No more design specifications, no more interaction specifications that a user doesn’t need to gain the value. We stripped them right back to CARD and CONFIRMATION all from the user’s point of view. (see Ron Jeffries explain CARD, CONFIRMATION, and CONVERSATION here -> https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/)

Three Amigos

  • We changed how we talked through stories as a team. We previously had backlog refinement where the Product Owner would present to the team the stories and then we would move on when everyone understood.
  • We started with four hour-long Three Amigos sessions per sprint to refine the stories ready for the next sprint.
  • The team would decide who turned up from each specialty (i.e. who for the QA amigo and who for the Developer amigo) and the Product Owner would always be there, sometimes with a stakeholder if it made sense.

BDD

  • We used the acceptance criteria as a guide to writing the scenarios as Stuart demonstrated in his talk. We talked through each user-driven acceptance criteria and created all the behaviour scenarios that supported that confirmation.

 

Results

1 Focus our communications on the value to a user of a feature and the behaviours that would help us ultimately achieve that value

  • Changing how we wrote the stories brought the focus back to WHY we were developing the story in the first place and the unnecessary words were removed
  • Our Product Owner has felt that these discussions help to marry the user need and the technical depth behind the behaviours
    • Originally this did take up more time for her as instead of just writing her story and presenting it out to the team she had to spend time creating it with the team
    • But previously a change to a story would be very time-consuming and this made it more tempting to resist the change. Now change happened naturally
    • Overall, time was saved

 

2 Spread the understanding of the story through the team and enable empowerment

  • Collaboration with people of all different disciplines shone a light on different options and things that previously may not have been thought of
    • For example a QA amigo may think about all broader scenarios like ‘what should the behaviour be if…’
    • A developer amigo might be able to see that a solution is going to be slow and take a lot of power to achieve
  • Existing behaviour was talked through to share knowledge of the product in general
    • When we started using BDD we only talked through the behaviour that would change with this story
    • We learned that omitting existing behaviour from our discussions was not the best approach as the team members who hadn’t touched that part of the product before didn’t know how this new story would impact what was already there
    • If we felt that the existing behaviour was something we needed to consider as part of the story then we created scenarios
  • Talking through the language in the scenarios all together boosted our shared understanding
    • We had plenty of conversations about what certain words meant to make sure we were all using common language
    • We used our user roles to make the scenarios relatable, defined terms, and debated grammar
    • Some of this was too far admittedly and one of the things we learnt is to not waste time straying from the goal of three amigos on a quest for perfection

 

3 In depth behaviour discussions would enable pragmatic approach to MVPe

  • By splitting stories into scenarios we could see a bit clearer on their size
    • For example if we found one had a lot of scenarios we could group them together and there our story was split by functionality just as simple as that.
    • Or we could cut some out that maybe weren’t vital to the user. These scenarios could come later.
  • We did also learn that BDD scenarios don’t work for all types of features for example one with a specific, non-negotiable set of rules set by a regulator. Scenarios are good for in general what happens if a rule is followed or broken but not needed for the actual rules.

Close

All in all using BDD and Three Amigos achieved the three hypotheses that we set out to achieve. There are many more benefits cited from using this technique, including improvements to quality and documentation, but as we weren’t measuring ourselves against them I haven’t included it in this article.

It also goes to prove that Agile community events are wonderful places to learn and I am extremely grateful for them (hence the cheesy slide of my thanks in the header picture).

Extensions

To keep working with and improving. Will update with any new challenges or tips. Let me know how you have found using BDD and Three Amigos in the comments below.

Posted in Games

Murder Mystery meets Rock Paper Scissors

Motivation

Workshop fun game to get everyone warmed up and talking

 

Research

As far as I am aware I made this one up.

But obviously based on the beloved Cluedo board game and Rock, Paper, Scissors.

 

Method

Each person has a piece of card folded in half

  • They have their own chart on the back to complete to solve the crime
  • And their own weapon, room, or person on the inside of the folded card

Murder Mystery Grid

Everyone goes around the room playing rock, paper, scissors

  • If you lose, you show the inside of your card to the other person and don’t get to see theirs
  • If you win, you get shown the inside of the other persons card and keep yours secret
  • If you draw you both show each other

Keep meeting people, playing the game until you have solved the crime and then shout CLUEDO!!

 

Results

  • First time I played this I only put one of each type of weapon, person, and room into the game room so you would have to play with each person
    • This didn’t work as if you lost to someone, there was no value in them playing with you again and so you were scuppered!
  • For the second time I put three of each in the room
  • This game took quite a lot of preparation for what is a 5 minute game
  • Everyone was warmed up and had to talk to people they didn’t know but they didn’t really find out anything about each other so not so useful for a room who don’t know each other

 

Improvements

  • Possibly changing the rock, paper, scissors part to be something a little more physical and engaging. Not sure what just yet…
Posted in Scrum Add-ons

FedEx Day

Motivation

To encourage creativity and ownership from the team in the product

 

Research

White paper and benefit of having a FedEx Day:

https://www.scrum.org/resources/fedex-day-lighting-corporate-passion

http://www.theenterprisearchitect.eu/blog/2013/07/23/10-reasons-organize-fedex-day/

 

Facebook have regular hackathons and some of their biggest features have come from them:

https://www.businessinsider.com/hackathon-project-facebook-features-2013-1?r=US&IR=T

 

Method

Agreed a time frame in between two sprints (we timed this with an awkward dates for having a planning session I think because a bank holiday had offset us)

Agreed a review session to show each other what had been worked on

Rules were

  • it couldn’t be something we were already planning to do and had to be new
  • There had to be something to show at the end (i.e. the FedEx delivery must arrive on time)

 

Results

  • Enjoyment from the team members on getting to work on something they either enjoyed or were passionate about
  • The team separated into a few smaller teams to work on their projects – mostly by time zone for ease
  • Everyone had something to show for the review
  • The business appreciated the ideas that had been created and put them on the backlog for further investment, or for further investigation where a new product was involved
  • After this event there were more creative questions on the solutions and the features and more suggestions
  • The business and the team asked for this to become regular

 

Improvements

The team learned that for people who have specialist skill sets in the team it may be harder to join in. This is something to be discussed more at the start of any new FedEx day when ideas are being talked through.

 

Extensions to try

Just to do this more often and to have it scheduled in to our regular sprints!

Posted in Thoughts

What I learned from children that has changed the way I work with adults

This post is based on a lightening talk I gave at Agile Nottingham in 2018.

The talk I gave focused on what I learned from working with the children in previous jobs. Children are honest, sometimes brutally so, which taught me a lot about interactions and ways to try getting the most out of people, even when they are having a strop.

 

My Background

During and after leaving University I worked as a Theatre Technician specialising in sound engineering but also working with props, set, lighting, and stage management. I worked with children as young as ten in schools up to professional theatre groups.

 

The importance of ‘why’

Children will tell you when they don’t want to do something. I’m sure we all remember when we were at school being told to do something merely ‘because I said so’ and then overexaggerating our body language to really tell you that I don’t want to do it. Maybe drag your feet, make a big point of rolling your eyes which apparently meant the need to roll your whole head and folding your arms tightly, and then putting the minimal amount of effort in to get the teacher to stop asking.

The most popular question that children ask you when you request they complete a task which I am sure we’ve all heard is ‘whyyyyyyyyy’ normally said in a drawn out way whilst making big eyes at you to show how hard this task would be at you to get you to give in and do it yourself.

As we get older we seem to get better at doing stuff we don’t want to do without making such a big fuss about it. And most importantly we stop asking why as sometimes it is just easier to get it done without asking. Or we can predict the response from someone senior still of ‘just because’. As adults we still do the bare minimum on a piece of work, just like the kids would do, just to pass the mark and move on, we just don’t make it so obvious that we are dragging our feet.

This vital question of ‘why’ is not one that I think we ask of our own work or what we are doing in our teams nearly enough. Knowing why we are being asked to do something, or why this particular thing is the most important feature to this stakeholder is a really important part of motivating us. And I think we should ask more.

I have in the past for example, and wave at me if you have been through something similar, thought the stand ups I was part of were going well because everyone turned up and said what they needed to say and we stuck within the 15 minutes. But then in the retro someone says ‘what is the point of the stand up?’ and suddenly you realise that every morning is just a show to say that the stand up is by not addressing the ‘why’ we do stand ups, it had absolutely no value whatsoever.

So knowing why is super important. I mean if explaining why can change 100 ten year olds on stage dressed as victorian orphans singing about food into a synchronised, harmonious, and rich scene, rather than 100 ten year olds looking like they are in an assembly and occasionally whacking each other with the wooden spoons out of boredom, I think it’ll be a much better show.

Great book here:

  • Drive by Dan Pink
  • Turn that Ship Around by L. David Marquet

 

Fun and Focus

And the other way that school shows manage to avoid scenes turning into a play ground is probably the best thing I learnt about working with school children. And it is from watching them go from bouncy ten year olds sitting restlessly, whacking each other with spoons, to having fun as a whole production, to getting into the zone and ready to give the performance of their lifetime. They taught me the importance of warming up for every occasion. Ranging from the high pressure pieces of theatre which would decide the results of their exam or when there were scouts in the audience, to just a good old fashioned pantomime with lots of silliness and no pressure whatsoever to get it perfect. Each theatre performance that I was involved in started with a specific set of warm ups.

They would warm up vocally and physically, as you would expect for theatre performers, but then they would always do something fun and freeing as a group. One school I worked with had a tradition of always dancing to ‘Build me up Buttercup’ before every show with their favourite drama teacher leading the moves. The fastest they ever moved to stage was when they heard that music playing! An activity like this helped them to feel a part of a whole, to come together as a team, to all do something a bit silly, and to feel at ease in what could be a very stressful environment for them.

The last thing every cast would do before going on stage would be a focus exercise. A common one was for everyone to stand in a circle holding hands and to pass a pulse around the circle by squeezing the person next to you’s hand. They stood in silence whilst they did this, no laughing, no fidgeting, and just thought about what they were about to do and get themselves in the right frame of mind to give it their all.

I love to start a workshop or a retro with a warm up. I don’t ask people to sing or to stretch funnily enough, but I do get them to do something silly to show that the space is safe and we are all in this together, and I do get them to focus on what we want to achieve and how we can put on our best show in the session.

Great resources here:

Posted in Scrum Add-ons

Sprint Review ‘Science Fair’ style

Motivation

We have multiple teams delivering towards the same business goals. They often weren’t fully aware of what the other teams were achieving and missed the opportunity to ask questions.

 

Research

There is a similar idea to this but demonstrating by feature developed rather than by team in the Nexus Framework book, pg 67

Quick scrum.org summary is here:

https://www.scrum.org/resources/blog/sprint-review-technique-science-fair

 

Starting Point

  • Each team doing their own end of iteration/ release reviews.
  • Unsure approach from teams – especially those who had worked on features they didn’t feel have a ‘wow’ factor
  • Some team members said they felt they had already completed a review of their work for iteration or release and were not confident any further review would be

 

Trial Method

  • Each team having a ‘stall’ at the Science Fair (we had 6 teams in total holding stalls)
  • Stalls set out around the edges of the room with enough space for people to wander about and stand around each stall
  • Inviting all stakeholders from all teams and some in-business users
  • A number of rounds of ten minutes each were set up to allow the teams to also rotate and see each other’s stalls
  • An introduction was created to explain the format and summarise the features delivered in the interval length agreed

 

Results

Notes from Setup

  • We took the idea to schedule these at regular intervals that suited the iteration or release cycle of all of the teams involved as they work to different cadences
  • Setup time in the room was important so that when people entered we were ready to go
  • Talking through the features that were delivered at the start felt like a waste of time as everyone could then talk through them with each team. This took time away from actual conversations so we decided not to keep it in the next one and bring our objectives wall into the room instead for people to refer to if wished.

Stall Activity

  • Each team had someone viewing their demo at almost every ’round’ as we called them
  • Each team felt they got value out of it as they were able to have more in depth conversations and ask more questions about the features from other teams than they usually feel able to in the team specific reviews.
  • The teams who were concerned on repetition of reviews and their stall not having exciting enough features had ample interest, questions, and feedback for us to repeat this Science Review format again
  • Stakeholders and in-business users who would usually only attend the review sessions for specific features broadened their knowledge to the work from other teams

 

Lessons Learned

  • Introduction to the features at the start is unnecessary – this has now been replaced with bringing the feature board into the room
  • Worthwhile start to improving the cross-team knowledge sharing and communication. It did highlight how difficult it is for each team to keep up with and understand the work of 5 other teams whilst also maintaining their own work.
  • Requests were made from all to make the event more ‘jazzy and exciting to attend with an extension to more people included in this. Biscuits have been suggested
  • This review format allowed a different type of conversation to a solo team review which I believe was because there were less people at one time and so questions of more personal interest seemed appropriate. This is why I don’t believe it felt more repetitive
  • There are more interested people in the features than you immediately think of within the business

 

Extensions to try

  • Invite more people and advertise as an event around the business for whoever wants to attend.
  • Consideration on whether making it a competition for best stall would create a brighter atmosphere.
Posted in Scrum Add-ons

Velocity Forecasting with Monte Carlo

Motivation

Communication with stakeholders and confidence in how we forecast was proving difficult

 

Research

I found this article on Scrum.org that introduced me to Monte Carlo forecasting.

https://www.scrum.org/resources/blog/monte-carlo-forecasting-scrum

Further research here and spreadsheet to use:

http://scrumage.com/blog/2015/09/agile-project-forecasting-the-monte-carlo-method/

 

Starting Point

The team that I trialed this with were previously using the method to take the average velocity of the last 3 sprints, catering for anticipated holidays.

 

Method

  • Take it to the team and talk through research
  • Input velocity data from previous sprints
  • Use the predictions it comes out with to change how we forecast our sprints
  • Use the calculations to have a strong goal (one that we could have a better confidence in our forecast) and a stretch goal which we would get to if we could
  • Take it to stakeholders and talk through the trial

 

Results

Communication on our forecasts within the team

  • It enabled conversation over the forecast velocity as we could adjust and see the simulation run rather than be presented with a single number
  • A forecast is as such, a forecast, and using this tool brought us back to metrics being a tool rather than a target number to hit
  • The use of strong goals and stretch goals helped focus on something more realistic to achieve and therefore built confidence within the team

Transparency with Stakeholders

  • As we’d had more conversations as a team we could justify our forecasts when asked and had more confidence
  • The use of strong and stretch goals also helped manage expectations with stakeholders

 

Extension to try

  • Planning for a goal first and then checking how that goal would look in the simulation and what our chances were of achieving the goal
  • Then we could adapt our approach to the goal if it seemed unlikely for us inside a sprint