Posted in Scrum

Scrum Implementation Examples

Scrum in Software Development

FBI (1)

Starting point
  • FBI had paper based document storage systems in 2010 (1, page 2 – 18) 
  • 3 paper copies were needed for everything; one for approval, one to be stored locally, and one to be hand indexed for input into the database

“This method was so antiquated and porous that it was blamed in part for the Bureau’s failure to “connect the dots” that showed various Al Qaeda activists entering the country in the weeks and months before 9/11″

Previous Attempts
  • The Virtual Case File (VCF) system had $170 million and 3 years spent on it but didn’t work and was never used 
  • A further attempt was called Sentinel which was budgeted at $451 million and 4 year timeline
    • One year late $405 million had been spent and it was estimated to need another $350 million and 6-8 years to finish
  • Way people were working for these previous attempts was wrong (waterfall was being used)
Scrum success
  • A proposal was then made to finish the most challenging half of the Sentinel project in a fifth of the time with a tenth of the budget, bringing development in house and reducing the number of developers from 220 to 40
  • The 1,100 requirements were prioritised so that the most valuable would be done first
  • It took 18 months to get the database system deployed, and a further 2 months to deploy it to entire FBI

Scrum not in Software Development

EduScrum (1, page 204-211)

  • Used in a school in the Netherlands, specifically a Chemistry class
  • Students in the class are divided into teams which all have the same goal of learning a new topic
  • The class pull out a Scrum board at the beginning of each lesson with their backlog
  • Each team selects the story pointed tasks it thinks it can get done in that lesson, based on velocity
  • They have a definition of done (and fun) which includes everyone in the team understanding the topic, so they must work as a team regardless of how easy they find the topic
  • Each sprint is 5 lessons, at the end of which there is a test on the topic 
  • They have a retrospective at the end of each lesson to learn how to work better
  • The students are totally self-organising, including setting themselves homework
  • Teacher helps when he spots a blocker, and tests the team randomly if they move something to done that everyone understands
  • By using Scrum not only do the students learn the topic, but also how to work together as a team and use each other’s strengths 
  • The curriculum results for this chemistry teacher have jumped more than 10% in a year by using Scrum and his students track above average for their grades


New United Motor Manufacturing Inc (NUMMI) vs Toyota (1)

  • The NUMMI Plant was closed in 1982 and GM management thought it had the worst workforce in America
  • People drank on the job, didn’t show up
  • People sabotaged the cars (e.g. putting a coke bottle in the door to rattle and annoy customers)
  • Toyota reopened the plant 2 years later with the same workforce and was almost immediately producing high quality cars like they were in Japan
  • Don’t hate the player, hate the game


Car Manufacturing (1, page 98 – 99)

  • From The Machine That Changed the World by Dr James Womack
  • Toyota, Honda, and Nissan (Japanese) spent an average of 16.8 hours making a luxury car with 34 defects per 100 cars
  • Mercedes-Benz, Audi, BMW (Europe) spent an average of 57 hours to make a car and they had 78.7 defects per 100 vehicles
  • Toyota used Andon cord – when a problem was spotted the production line was halted and the problem fixed so that it wouldn’t occur on any more vehicles
  • Europe had quality checkers at the end to fix the problems

“the German plant was expending more effort to fix the problems it had just created than the Japanese plant required to make a nearly perfect car the first time”


  1. Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

Posted in Library

‘Scrum: The Art of Doing Twice the Work in Half the Time’ Review

Holiday Read

This is an easy read about the origins and principles of Scrum, with no complex theory to focus on. There are also some interesting stories of Scrum being used in non-software development environments. 

This book is one that should be on the must read list for all involved in Scrum. It isn’t expensive, it isn’t taxing, and how better to fully understand Scrum than to read from one of the co-creators about how they came about creating Scrum. 

Not just Scrum!

That being said, this book does not stick to the explicit content of the Scrum guide and does talk about complimentary practices, for example story points. My version of this book was published in 2015 and there have been updates to the Scrum Guide in terms of wording as well as opinions on complementary practices that could spark a lively debate with what is written in this book. So even though this book is written by the co-creator of Scrum you may find yourself pausing at certain points to think and maybe disagree. 

Should I read it?

If you are looking to just pass the PSM I because you have been told you have to but you don’t care about Scrum, this book won’t help you pass. If you are new to Scrum and want to learn a bit more about the why and how it can bring value, read it. If you are an old hand at Scrum and have the Scrum pillars tattooed on your heart but haven’t read this book, this is a great refresher to help take a step back and see Scrum at its fundamentals and most importantly, why Scrum. 


Posted in Scrum

Scrum Theory

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. (2)

Definition of Scrum

  • Framework not Methodology (1)
  • Servant Process not Commanding Process (1)
  • Goal = to optimise and control the creation of valuable software (1)

Origins in New New Product Development Game

  • Demonstrated complex product success
  • By self-organising team
  • The team were given objectives, not tasks (tasks make teams blinkered) (1)

Origins of the name

“The term comes from the game of rugby, and it refers to the way a team works together to move the ball down the field. Careful alignment, unity of purpose, and clarity of goal come together. It is the perfect metaphor for what I want teams to do” (5, page 8)

House of Scrum


created by Gunther Verheyen (1)

  • The walls are the main activities of Scrum (inspect and adapt)
  • The foundation for the activities is transparency
  • The roof keeps the house safe (the increment) from the unpredictable from outside the house
  • Inside the house is the space to create (including the principles, rules, roles)


Inspect (2)

  • Frequent inspection of artefacts and progress toward Sprint Goal
  • To see if there is variance between where we are and where we want to be
  • Not too frequent to get in the way of work
  • Performed by skilled team members at the point of work

Adapt (2)

Transparency (2)

  • Artefacts of the product must be visible to all people responsible for the product
  • Common understanding
  • Example is the definition of done

“if there is more truth in hallways than in meetings, you have a problem”

4, page 317


Empiricism: "Empiricism asserts that knowledge comes from experience and making decisions based on what is known." (2)

Empirical Process Control (1)

Closed Loop System
Closed Loop System (Empirical Process)
  • Actual outcome is regularly compared with desired outcome to diminish undesired variance
  • Creates transparency
  • The Sprint and Daily Scrum are examples
  • Self-correction is applied (no need to know the details up front)
  • Complexity means steps and tasks are not predictable as they are not repeatable
Open Loop System
Open Loop System (For reference)



Sketch notes above by ‘Sketching Maniacs’ from the Wikipedia page


Scrum Improvements Exercises

Scrum Elements Team Exercise (3)

  1. Write each element of the Scrum Framework on a separate sticky
  2. Write complementary practices the team uses on a different coloured sticky (e.g. story points)
  3. Score each sticky from 1 (not doing this) to 5 (mastered this)
  4. Discuss how the team can get each Scrum element to 5. Are the complementary practices getting in the way?

Scrum Across the Organisation (3)

  • Gather the Scrum Masters together
  • Use the liberating structure, 15% Solutions to answer the below question
    • ‘What’s within my control that I can change to get our organisation 15% closer to where it needs to be?’


  1. Scrum Pocket Guide by Gunther Verheyen
  2. The Scrum Guide
  3. Fixing Your Scrum by Ryan Ripley and Todd Miller
  4. Creativity Inc. by Ed Catmull
  5. Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

Explore more Scrum

SprintScrum ValuesScrum MasterIncrementDefinition of Done
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!


Posted in Scrum Add-ons

BDD and Three Amigos

Using the practice of Behaviour Driven Development with a subset of the team representing all skill sets to refine user stories


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.


The stories we were using were closer to contracts than stories


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

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


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


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)

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.


  • 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.


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.


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).


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 Scrum Add-ons

FedEx Day

Delivery in 24 hours


To encourage creativity and ownership from the team in the product


Articles on benefits

  • Rob van Lanen’s paper on unlocking intrinsic motivation through FedEx Days
  • Johan den Haan’s 10 reasons why you should organise a FedEx Day
  • Facebook’s features that have resulted from Hackathons


Preparation for the day

  1. Agree a time frame with the team and management
    1. 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)
  2. Organise a review session to show each other our innovations
    1. Ensure someone from seniority was present to see the innovations
    2. Structured similar to the first half of the Sprint Review
  3. Establish rules
    1. it couldn’t be something we were already planning to do and had to be new
    2. There had to be something to show at the end (i.e. the FedEx delivery must arrive on time)

On the FedEx Day

  1. Meet at the start of the day to refresh the purpose
  2. Participants self-organised into teams
  3. Teams each agreed a direction


Creativity and Innovation Boost

  • Enjoyment from the team members on getting to work on something they either enjoyed or were passionate about
  • 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

Team Cohesion

  • The team separated into a few smaller teams to work on their projects – mostly by time zone for ease
  • The team learned that for people who have specialist skill sets in the team it may be harder to join in, so this needs special attention

Delivering Incrementally for Fast Feedback

  • Everyone had something to show for the review
  • The business and the team asked for this to become regular
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.

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.


Posted in Scrum Add-ons

Sprint Review ‘Science Fair’ style

Interactive increment demonstrations


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.



  • There is a similar idea to this but demonstrating by feature developed rather than by team in the Nexus Framework (1, pg 67)
  • Quick summary is here

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


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.


  1. Nexus Framework by Kurt Bittner

Read more

Posted in Scrum Add-ons

Velocity Forecasting with Monte Carlo

Using simulated Sprints to forecast velocity


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



  • I found this article on that introduced me to Monte Carlo forecasting.
  • Further research here and spreadsheet to use

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.


  • 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


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

Explore more


Definition of Done