Scrum from Hell revisited.

Today was a flashback kind of day.  I was part of a Scrum Master training day and one of the games the group played was “Scrum from Hell”.  It took me back to 2009 when I wrote one of my first Blog Posts about a game I played with one of my teams.  The blog post remains fresh with me as it is still one of the most viewed posts I have written as it still gets a lot of hits per month, even when my site hasn’t been updated as often as I would like.

Playing the game again was awesome and as I have gained more experience since I wrote the original post I looked on it from a different perspective.  Originally when I played the game I was trying to highlight to our team how disruptive one aspect of our teams behaviour was.  We had a few people in the team who loved to talk and would take the meeting off on tangents and no matter how many times the team brought it up at Retrospectives, the usual suspects still persisted.  We put them into the hot seat as Scrum Master and mimicked their behaviour.  They found it frustrating and could see things from the teams point of view and changed their ways.

Today, I saw the game as a great fun tool for highlighting how hard facilitation can be for a new Scrum Master to a new team.  In the beginning the daily standup can see people act in different ways when they come together as a group.  Some of these behaviours can be detrimental to the harmony of a team so it is a great way to highlight these bad behaviours to a team and give them experience of how hard it can be to not only facilitate a standup but any ceremony.


  • Split off into groups of 5 or 6.
  • Select 1 person in each team as Scrum Master and ask them to leave the room
  • Explain to the Scrum Masters that they will be running a Daily Standup.
    • Ask them to explain the format of the Daily Standup to the team.
    • Explain the 3 standard questions.
  • With the Scrum Masters still out of the room explain the rules of the game to the teams.
    • Ask the group to shout out some bad behaviours they have experienced in a meeting (Looking at mobile phones, arriving late, side conversations, talking over people were just a few we used).
  • Allow the Scrum Master to facilitate the meeting for 3-5 minutes.
    • When the Scrum Master starts the meeting the teams should act out the bad behaviour that they have chosen.
    • If the Scrum Master notices the behaviour they should call it out (promoting holding each other to account).
  • Ask the Scrum Masters to reflect on how they felt and what they learned whilst playing the game.

Feel free to check out my Original Post for more ideas on this game.

Big thanks to the team for refreshing me on this.



Distributed Scrum Teams

I was looking for inspiration for my next blog post when I found a notification telling me that I had an article sitting in my drafts section.  Distributed Scrum Teams was the title and it took me back to 4 years previous when this topic came into my head.  I was going to tell you about the successes that I had using distributed teams but I deleted all that.  As I began to edit the post I realised just how far we have come in just a few years and decided to highlight that instead.

When I started out in 2006 there was a lot of chatter about how distributed teams were not Scrum.  If you were using distributed teams, you were breaking the values of Scrum and that was bad.

“Scrum best practices indicate you should be physically near the rest of your team members, actually located in the same area of your work space. How can you effectively apply the tenets of Scrum when working with a distributed team, if you are breaking one of the key best practices? Or deal with the challenges of trying to detail a spec, but keep an agile and open development flow? or Communicate to a remote team the business priorities?” Jessica Johnson.

Fast forward to today and the landscape is so much different in 2018.  A massive change for me has been the way businesses work nowadays.  Businesses have moved with the times by introducing flexible working.  Some have decided to save in business rates by introducing rotas on when different teams can work within the office space to save them the cost of having to buy bigger offices.  This means that teams will be working from home more.  So your colocated team now becomes distributed to an extent.  It may not be possible for businesses to be fully colocated these days.

My previous company had distributed teams that had team members based across all of our UK offices.  Not only that, there were people working from home too.  We had daily standups via Skype where everyone had their camera turned on and one person shared the board to make it visible to everyone.  The team gave their updates just like they would in a physical standup and to facilitate any follow up conversations that occur from  the standup, we had a parking lot after the call where people would would stay to discuss anything that they felt needed discussed.  We used Skype for all of our ceremonies and tried to have the whole team together once a fortnight for planning.  This worked well for us.

I recently worked with a colocated team who were using a digital and physical representation of their Scrum Board.  The main physical wall worked as a big information radiator for the team and anyone else in the department who would take an interest.  The digital board was used to mirror our physical board.  This meant that people could work from home or Flexi time if needed.  The level of collaboration within this team was on par with the level of collaboration within my distributed team.  Each team had found the best way to work for them and improved upon this as they worked together.

In my personal experience it does not make much difference if a team are colocated or distributed these days.  The main barrier is the team themselves.  They must be committed and willing to collaborate with each other to make things work.  Maybe in the past the tools that we have to help us collaborate weren’t as powerful as they are today and I think this may be a huge factor in why it was considered bad practice to have a distributed team.  But now there are so many avenues open to teams to aid collaboration when they are not in the same office.  It is all inspecting and adapting along with your team and continually improving the way that you work together.  It will be hard to begin with but if it was easy, it would be boring 🙂

It was interesting writing this article.  It highlighted to me that not only is out teams constantly changing and improving but the business landscape too.  I wonder if all of those people who were complaining about distributed teams in the past are now embracing the change or even realise that this has happened.


Blogging and I.

I have been maintaining my blog for a while, quite loosely as you will see.  I often found myself having great ideas to post but when I sit down to actually write a blog post, they never seem to fit together well and ultimately they don’t get written.  I really need to practice what I preach and stop starting, start finishing!  I thought to myself.

It wasn’t until I started to listen to Geoff Watts audio book on Product Mastery  that I realised where I was going wrong.  When it comes to blogging, I needed to be more decisive (apparently my wife has been telling me this for years :D).

One sentence that stuck with me was “When things become difficult, it is tempting to put them off, to do a bit more research”.   Then another “The result, nothing of value is actually delivered”.  Both summed up my situation.

It really struck home today when I was sitting down to write a blog post on my first assignment as a contractor.  I had written all of the ideas that I had down on a piece of paper to get some structure before I would begin to type the post.  There were so many ideas in my head that I was getting nowhere fast.  I decided to clear my head and go for a run.

While out on the run I thought about the other things that I had to do today and suddenly it hit me.  I was subconsciously putting off the blog post as it had become too hard to write.  But why was the post so hard to write?  I went through all of the ideas I had and realised that I was trying to fit three blog posts into one and because it wasn’t fitting perfectly the perfectionist in me decided that the post wasn’t a good idea.  I realised that I have done this with so many blog posts in the past and it was something that I needed to fix.

I came back from the run and decided that I had to break the massive post down.  I decided to fact check the two quotes used by Geoff above when I found the tweet below, which summed up my predicament perfectly.


This made me smile as I had already realised that the expectations for my blog post were unrealistic and decided to break the big post down into manageable chunks.  It then led me to write this blog post.  The outcome, I delivered value and have a couple of blog posts that actually make sense to me and will be easy to write.

It is amazing what taking a little time to clear your head can achieve.  I realised a lot about myself today in that when I get an idea for a blog post I try to cram as much into that idea as possible to a point where it becomes too big to actually do anything with.  I have a lot of knowledge, experiences and practices that I try to get across but have a tendency to overdo it which leads me to lose confidence and scrap that idea.  Being decisive about the content you want to appear in your post and not being scared to take things out that just don’t need to be there is key.

Hopefully this results in more blog posts from me in the future 🙂

Cheers Geoff 🙂


The Scrum Guide

I was recently watching a Scrum Webinar where they polled the audience on whether they had read the latest Scrum Guide or any version of the Scrum Guide.  77% said that they had read the guide with the remainder saying that they had not read it.  I decided to post this for anyone looking who has not read it or anyone who is looking to familiarise themselves with it.

Described as “The book of knowledge” by most people and as “The rules of the game” within the guide,  the guide has been written and updated by Ken Schwaber and Jeff Sutherland to give an overview of Scrum and is an important read for anyone currently using or looking to roll out Scrum to their organisation.

It has been updated on a few occasions since it was released in 2010 so it is always best to check the website to make sure you have the latest version.  I started my journey with Scrum in 2008 reading the “Agile Project Management with Scrum” by Ken Schwaber and whilst there was no guide at the time, this was my textbook my source of clarification and checking if I was doing things right or had a clear view of the roles and rules.  The guide is a quick way for people to check that they are on the right track and the beauty is that it will always be the latest version.

“Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.” (

Scrum Guides websites

PDF Version Scrum-Guide-US

Distributed teams and Online Scrum Walls

There has been widespread debate around physical Scrum Walls vs digital Scrum Walls for teams for some time now.  I know that this totally depends on the situation of your teams as to which method you choose.  Personally, having used both physical and digital walls I feel at home using both.  Each has their benefits depending on what type of team you have, whether the team is collocated or distributed and the ease of locating space on a wall big enough to house your board.  As always I would say research both and pick which one is most suitable to your needs and way of working.  If you find that either is not working, don’t be afraid to change!

When I started with Scrum a long time ago now, our Scrum Walls were physical.  Lines drawn out with the iconic blue 3M tape adorned every spare piece of wall in our office.  No wall was safe!  Our development teams were based in one location, our Product Owner was based in another and the task of keeping the Wall up to date was a mammoth task.  It was easy for our developers to physically walk up to the board and move a task to the relevant position on the board once it was completed, but it was hard for our Product Owner to keep abreast of what was happening.  It was dependent on constant communication from the team to the PO to keep him up to date with how work was progressing.  It is easy for a PO based with the team to look at a wall to give any status reports, but it is more of a labored task for a distributed PO to see a physical board and quickly give an update to a stakeholder, so it was important for us to always keep the PO in the loop.  Sometimes the communication would fail and with that work slowed so I needed another solution.

This problem sent me on a quest to find a Scrum Wall that worked alongside our existing physical wall but made this available online without compromising the work of the team.  One that would make the wall available online but deliver notifications if tasks were assigned to the PO.  If you have read my previous blog post about the online Scrum Wall that used QR codes placed on our User Stories and tasks to plot them to an online Scrum Wall, then you will see how highly I rated this at the time (although, my teams didn’t rate it as highly as I did and I put this down to the inner tech geek within me that though QR codes were cool at the time).  It did seem as though it would work well in theory but in practice it was a logistical nightmare as you had to print the cards out, physically write on the cards, use a high definition camera to take a picture of the board and then upload the picture for the system to map out the points and move cards to their new positions by comparing it against the last photograph taken.  If you missed a photo or if sunlight was hitting the board the wrong way the picture would be spoiled and have to be run through again.  Even writing out that process makes me tired.

Eventually we opted for the tried and trusted method of pointing a webcam at the board and carrying out our Daily Standups.  It wasn’t without its problems but it worked for us.  Our teams then moved in house with everyone located in the same building and we concentrated on our physical walls and our efforts to move to digital were put to bed.

When I started with my new company I realised that my teams were distributed again.  But thankfully the days of everyone piling into a small room with a 2 megapixel camera, one microphone and a raft of background noise have passed.  The infrastructure now available for teams to communicate is out of this world compared to a few years ago.  We are currently using Skype for business (Previously Lync) and our systems are equipped with HD webcams and advanced conference phones with webcams to help our teams keep in touch.  This is a lot better than previous methods that I have used and it is a useful tool for distributed teams.

With an improvement in infrastructure, software tools have also come a long way since I started with my first distributed team.  Online Scrum Walls have become a lot more advanced and usable.  The main online Scrum Wall that I use is a tool called Kanbanize.  This is a tool that makes it simple to make online Scrum Wall’s or Kanban boards and allows you to tailor them to your specific team.  The god send for the Scrum Master is the ability to utilize Kanbanize to automatically import Bugs or PBI’s from Team Foundation Server or Jira when an item is created by the team.  When a PBI or Bug is created we have set Kanbanize to import the task to the relevant Scrum wall, complete with PBI/Bug number, description, link back to TFS and which Swimlane the task should reside in.  We then pull the PBI from the backlog to the Sprint backlog when it is needed.  So no more manual input and precious time saved!  It allows you to tailor the columns or swimlanes to match your physical Scrum Wall as shown below.


Tasks can be colour coded and each user can set their own avatar that will appear on each task assigned to them, mirroring our usual physical Scrum Wall.  With alerts being sent when a task is assigned or switches assignee or if a task is blocked it really is a useful tool for helping teams work together when they are not in the same location.  We share our board on screen as part of our daily Standup so it really is like we are meeting in front of our Scrum Wall every morning.

You can check out Kanbanize’s feature list here but it would be interesting to hear your views on Digital Scrum walls, your experiences or oven opinions on other tools that I should consider for a distributed team.

I will admit, I do love a physical Scrum Wall and I have created one in addition to our online Scrum Walls in our office.  You are probably thinking, why does he need this if he has them online?  Well, I find that it is a good information radiator for people working on the project or different projects.  I also find it useful for people randomly walking past and asking what the board is, what its purpose is and generally showing an interest in Scrum.  All of this is beneficial even though it does require a little overhead.  So there you have it, an example of finding what works well for you and making it happen.

Demonstrating Acceptance Criteria

I have found myself reading a lot of Agile books over the years.  I aim to take 2 or 3 pointers, minimum, away from each book to help challenge the way that our teams work with a view to making improvements.  I have found that this has taken me a little time, often rereading chapters to put things into context and then breaking things down into scenarios that I can use to demonstrate what I have learned practically.

I find that acting things out using scenarios is the best way for me to learn things and put things into action with my teams and I bet it is the same for a lot of people too!  There are a few demonstrations that I have encountered in Agile like the ball game that most of us will be familiar with from our CSM training or the Penny Game that Ian Carroll demonstrated at his Kanban talk during Lean Agile Scotland this year.

I find these type of exercises useful as there is always a scenario, an action that someone can take to improve things and a subsequent consequence of implementing the improvement that makes people think about how they do things.  These can then be compared to the way that teams currently work and improvements suggested.  I have always seen these exercises for teams in terms of improving estimation and velocity but had never seen a practical exercise for actual work items.

Tom Reynolds has created a blog post that got me thinking about Acceptance Criteria and how I can promote to my teams the importance of making their Acceptance Criteria meaningful and challenge themselves to push for improvements.  It is a simple method that explores the power of acceptance criteria by drawing a house.  Tom begins by asking everyone to draw a house whilst he draws his own house out of sight of everyone else.  Once everyone has drawn their house he will go around and inspect each house.  He notes that on the first pass everyone has drawn a house that does not meet his expectations as a stakeholder.  He then gives a set of detailed acceptance criteria regarding door placements, number of windows etc that allows each person to then go and redraw the house.

Once each person has redrawn their house he inspects them again, most are identical and some with slight differences but ultimately pass the acceptance criteria set, whereas the ones that are off spec are rejected.  This shows that when given detailed acceptance criteria, the likelihood of delivering what is needed is greatly improved.

In general, if a team are given acceptance criteria that is open to interpretation, the delivered item may not be exactly what is expected to be delivered by the Stakeholder.  We must encourage our teams to review acceptance criteria and challenge it as part of our refinement sessions if there is not enough detail there.  That way we can make sure that we are delivering exactly what is needed consistently.

Scrum Software on the iPhone.

Our Scrum Team recently gained a new member and I came to the stark realization that everyone in our team has an iPhone!  How awesome is that!!  (Yes, the sceptics amongst you who have not converted to the Church of Apple may scorn all you want! but we don’t care :D)

First up is Planning Poker.  Gone are the days of having to sort your Poker Cards into each individual set so that every member of the team has their own set of cards.  Only for someone to shuffle them before you use them (Yep, weve all done it).  There are a few software developers who have taken Planning poker into the future.

James Williams has created a pretty little application for the iPhone to mimic Planning Poker called Agile Poker.  The user is presented with a really easy user interface and coupled with the touch screen on the iPhone it couldn’t be easier to select your estimate.  The nice graphics and slick animation that is shown when a card is selected is pretty cool too. Available Free on iTunes here

Options ScreenCard UI

Card SelectedCard Selected

Next up us Planning Poker from Francois Baronnet.  A similar Planning Poker application but it is a little more bland graphics wise and a little cluttered.  The user interface is a little more complex too with the user having to tap twice on a card to select it.  There are 2 modes to display your chosen card.  Fast, which shows your chosen card instantly or there is the “Flashy” method, which turns the card from face down to face up.  Overall, it is a little complex but it does what it says on the tin. Available Free on iTunes here

Planning PokerWelcome ScreenCard SelectionCard Shown

Agile Poker by Hortis is a silverlight looking application that offers a good help section with some tips on carrying out Planning.  The application its self is different from any other planning application on iTunes.  It has all of the cards in a straight line that the user must scroll through.  The sensitivity of the scrolling mechanism is a little high and selecting a card can be a bit of a chore (you often skip the one you want).  The animation is pretty slick, but the way that the card is displayed really lets the rest of the app down.  It does what it says on the tin though. Available Free on iTunes here

Start Screen

Card Chooser

Help ScreenCard Selected

Planning Poker by Unboxed Consulting is a pretty good Planning Poker Application.  It has a simple layout and easy one touch card selection which triggers a simple but effective animation.  The only thing is that you need to shake the iPhone to cancel your card selection in order to continue (this is a setting that you can switch off tho).  This application also has a configurable timer that allows you to time your planning session.  It is also tailorable to suit different types of planning, from the fibonacci to Binary.  This is a very effective application. Available Free on iTunes here

Home PageCard SelectionTimerOptions

Last but not least for the Agile Planning Poker Apps is an app by Greg Paterson called Agile Planner.  The user selects an estimate from a scrollable list and then clicks hide  This then hides the estimate from view.  The user then has to click flip to show their estimate.  Its pretty basic.  But I don’t see why it couldn’t be used. Available Free on iTunes here

Main PageChosen card

I also found an app from Scrum wall that lets you control your agile project by using Scrum Wall.  I will need to look into how this works and update you all later 🙂  But it is Available on iTunes here if anyone wants to look.

Hopefully I have given you enough insight into making your planning more effective and fun at the same time.  If you don’t have an iPhone.  Go get one!