Agile Forest

Find your path to agility with Renee Troughton

In a recent tweet,

If you must do some pre-project prep, so be it. Please don’t name it “Sprint 0″ that makes it seem valuable. It isn’t.

Delving further into the tweet I learned that “many use Sprint 0 to enable bad habits” (don’t disagree), that it maybe should be called “project chartering” instead and that a more common definition of a Sprint is “a time-box for delivering a Product Increment”.

So what is the common goal of a Sprint 0?

Starting-Line-300x200The Sprint goal (by my definition) behind a Sprint 0 is “being ready and able to deliver business value that is usable and potentially releasable”. If you are ready to deliver business value then Sprint 0 is officially done.

Do all projects need a Sprint 0?

I say projects here quite deliberately as a team that is already functioning and already delivering are highly unlikely to need a Sprint 0 unless a specific set of features coming up dramatically impacts the ability to deliver business value inside of the Sprint.

If your organisation is onboard the DevOps train and XP practices are well established then you may not need a Sprint 0. If environments can be created and built upon in a day, if standards and frameworks are well understood then you may be ready to start delivery business value straight away.

This ultimately is highly dependent on your organisational capabilities.

Where does story elaboration fit in with respect to Sprint 0?

Teams quite commonly use the time whilst in Sprint 0 to also elaborate further the User Stories for the first value delivering Sprint.

You don’t have to have elaboration one Sprint ahead, but it can potentially help reduce carry overs, reduce time spent in Sprint Planning and ensure that task cards (if you use them) are well defined.

In an ideal world User Stories would be small enough and complexity low enough that carry overs are minimal and elaboration can occur within the Sprint.

What cadence activities should occur in Sprint 0?

Sprint 0 should be, from a process perspective, exactly the same as any other Sprint. It should be planned upfront through Sprint Planning, work should be broken down into items that are achievable within (ideally) 1-3 days, it should be slapped up onto a story wall/task board and tracked, Daily Scrums should talk about what everyone is doing and enable collaboration and sharing. At the end of the Sprint you should demonstrate what you have achieved within the Sprint Review, “Hey take a look at this box, this is the box that builds our code and automatically deploys it. Here look at it compiling and this is the result (good and bad) that it generates”. The Product Owner may not care but I can assure you the rest of the team will. Additionally it is a great opportunity to start reflecting about how you have worked together as a team and see what can be improved.

Just as per other Sprints the work that is done in Sprint 0 should be prioritised. If it doesn’t enable you to deliver software in a Sprint then it probably isn’t high in priority.

So in essence, all the standard, normal Sprint activities that occur when business value is delivered should also occur in Sprint 0.

How long should Sprint 0 be?

Just like value delivering Sprints, Sprint 0 should be timeboxed. The ideal value to set this timebox to is the same duration of your value delivering Sprints. When you do this it is a great test to see if the Sprint length works for you and also a great test of your planning process – were you able to achieve what you had planned?

The trouble with this is that in almost all cases the team’s velocity has not been established and consequently the likelihood of not delivering to expectations is high. If you are going to fail on estimation versus delivery (which I can safely say you will) then this is the time that it first shows itself. This then sets the team on a slippery slope as already from the first Sprint you are behind expectations. How will management react to this message? How long will it take for pressure to be pushed onto the team?

For low DevOp maturity organisations it is entirely possible that the time it takes to get ready to deliver value is longer than a Sprint. This is where the concept of “Sprint 0″ as a term fails and you see people then try to fix it through using “Sprint -1″, etc. This slippery slope further erodes management trust.

I fail to see a magic bullet for this particular problem other than having good planning upfront and always asking “do we really need to do this to begin delivering value?”

What if the team is able to deliver value earlier than then when the Sprint will end?

Then start delivering value. If it is a week earlier, you might want to re-organise the Sprint start and end dates. If it is a few days then it is probably a good idea just to let the Sprint run its course and ignore the velocity for the Sprint.

What if the team is unable to deliver value by the end of the Sprint?

If there are just a few outstanding items then start the first business value delivering Sprint, being cogniscent that it will impact your velocity a little. If there are considerable outstanding items then this should be discussed in detail at your retrospective. Why did this happen? Was it because impediments were not removed? Should an additional Sprint be added? If another Sprint is added then does it affect the ROI of the project? Should we just call it quits now?

How long after Sprint 0 is finished should you wait to start doing Sprints?

Don’t wait. Get started delivering that value!

Where does team onboarding fit in?

The day you start Sprint 0 is the day all the team should be onboard. Arguably they should have been onboarded earlier when you initially created a Product Backlog through Inception workshops.

What are the common pitfalls of Sprint 0?

The obvious one is that teams never get started delivering business value. They stay in this mode of never being ready and there is no drive or motivation to move out of it. Sometimes this is for very valid reasons, for example, developers don’t have PCs or an environment to work in; but often it can be just rats and mice outstanding.

This is why it is important to have Sprint 0 considered a Sprint because the Scrum Master should be driving the team to the goal of delivering value in a predictable manner.

So what is the Scrum Guide definition of a Sprint?

The Scrum Guide defines a Sprint as:

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable,
and potentially releasable product Increment is created. Sprints have consistent durations
throughout a development effort. A new Sprint starts immediately after the conclusion of the
previous Sprint.

So by the above definition it is wrong to call everything that I have said above a “Sprint” because it doesn’t result in a potentially releasable product.

But the Scrum Guide goes on to say:

Sprints contain and consist of the Sprint Planning Meeting, Daily Scrums, the development work,
the Sprint Review, and the Sprint Retrospective.

which aligns with the above activities that should occur as you prepare to deliver business value. Not surprisingly the Scrum Guide does not say anything about Sprint 0, mostly because anything that is before Sprints fails to exist as a process step or activity (the initial backlog creation being a great example).

What’s in a term?

If you should have for Sprint 0 a Sprint Planning Meeting, Daily Scrums, dev work, Sprint Review and Sprint Retrospective why would you not have a term for this special case that does reflect the word “Sprint” in it, after all, three of the cadence activities in them have the word “Sprint” in them.

If you want to use a different term, lets say “Project Chartering” then you are still having a Sprint Planning, Sprint Review and Sprint Retrospective… but not in a “Sprint”. This seems a little odd and misleading to me.

I feel that the messaging to people starting Agile should be clear and simple and removing the word “Sprint” does not align logically with that. I feel that the word “Sprint” is incredibly applicable and that the definition of “Sprint” in the Scrum Guide needs some common sense flexing of interpretation. I don’t expect the Scrum Guide to change, but do expect some guidance somewhere about how this pre-Sprint is a special exclusion from the delivering of value component in the guideline.

You could always just change the name of all the cadence activities but I think that goes back to not having a simple message.

So what would I call it? I agree that the ‘0’ in ‘Sprint 0′ is misleading. I would call it something like ‘Delivery Enabling Sprint’. Make the implicit explicit.

purposeSometimes there are moment in life when like a bolt out of the sky you have a major self realisation. I had one of those moments recently when I realised that for a majority of my coaching life I have been pushed and prodded by my leaders/managers to behave as a Purpose Driven Agile Coach.

What is a Purpose Driven Agile Coach?

It is a coach that is asked/told that when they implement Agile that there needs to be a plan to improve capability. Targets are set and tracked weekly. An example could be, “Improve stand-ups within the month”, it is still very open ended but the practice it is linked to and the time frame is set.

I would imagine that this is quite common in organisations with low Agile maturity and very strong old school management mentality. In these cases, organisations want to predict and understand the value that Agile Coaching provides. Often this is linked to definable metrics, before and after of Agile capability in teams, but I often felt that this capability was shallow. I would be pulled and moved onto another team before I had a chance to really embed the change and ensure that behaviours didn’t regress. I was often only given the time to teach the ‘shu’ basics and never the time to allow for trancendence to ‘ha’ (and certainly not ‘ri’).

But lately I have been less pressure bound from a coaching perspective (I still have pressure, it is just different). This release of pressure to not plan has resulted in me using a different model – Opportunistic Agile Coaching.

What is an Opportunistic Agile Coach? 

It is a coach that only course corrects or teaches based upon the moment, taking into account both team and individuals mental model readiness, change value and change fatigue. Let’s break this statement down some more.

Mental model readiness is about whether the team or individual is in an intellectual state of readiness to receive the coaching advise/support/inception reflection idea. For example, I might personally believe that the benefits of estimation are limited, but the team may have given the concept little thought. Mental model readiness is about whether they have been asking the same questions themselves or whether I have introduced the inception reflection idea. I say ‘inception reflection idea’ because it really is like the movie Inception – you want to seed the idea or consideration in the team as to whether the practice is worthwhile or not and give them time to reflect on it.

Change fatigue should be fairly simple – how much change is the team or individual currently dealing with? If they are completely new to Agile or are mentally still coming to grips with some concepts of Agile then I am less inclined to make drastic changes. For example, if they are familiar with Scrum terms such as PBI and Sprints, where as I am more comfortable with saying Stories and Iterations, I will just go with their flow and not introduce name conflicts for the sake of it.

Change value is about whether the team or individual will get much (if any) improvements from the change. By improvements I mean faster client feedback, improved customer value, improved personal engagement, etc.

Regardless of which Agile Coaching method, I have always started by mentally creating my own backlog. It is easy for me to see what practices need to be improved and where. Sometimes if there are a lot of issues or the complexity is significant I will write it down as a real backlog and estimate it. To some extent, I have always done coaching with opportunistic elements – ie I gauge priority by change value and do take into account mental model readiness, but when there is no set plan, then it is really very liberating.

As a problem or situation crops up I can assess it against where the item fits in my mental backlog. If it was bubbling up closer to the top then I will use the opportunity there and then to address it. I might let certain opportunities pass as they are still very low on the list, but what might have been tackled four weeks later in a planned approach is addressed on the spot, with immediate context and relevance.

Relevance to revolution vs evolution in Agile models

My realisation of the existance of two Agile Coaching approaches, purpose vs opportunistic, made me then immediately think of the revolution versus evolutionary debate in the Agile community. A purpose based approach is more closely aligned with a revolutionary approach where mass transformation is expected/desired and cookie cutter conformance is achievable due to standardised but complicated teams. A opportunistic approach is more closely aligned with a evolutionary approach where incremental change is made based on team readiness and self-realisation – there is no cookie cutter conformance and there is a realisation that there is no such thing as standard teams, or that teams that are dealing with complex problems.


I know we would all like to think of ourselves as opportunistic coaches, but how many of you are really doing purpose based Agile Coaching and is there a right/wrong way?


Version One have released their annual State of Agile Development Survey for 2012. Co-inciding with this they also released a blog titled the ‘Top 10 Things the State of Agile Development Survey Won’t Tell You’ which I excitedly opened only to find it was a joke blog post. This was slightly disappointing as I love the effort and professionalism that Version One goes through to produce their survey and felt the blog cheapened it. I had hoped that the blog would outline the known deficiencies in the survey, but alas no. So I decided to write what I felt the  blog post may have covered if it took the topic seriously, so here it is – the Top 10 (okay maybe 13) Things the State of Agile Development Survey REALLY Won’t Tell You:

  1.  What the co-relation between those with Agile Development Practice Experience and their role as an Agile Practitioner. I suspect that the 19% of Agile Coaches/Consultants/Trainers would make up a high portion of the 25% group that have 5+ years experience (It would be very scary if it wasn’t true). 
  2. Why is it that 60% of respondents were managers/leaders or consultants – are these the only people that have time to fill in surveys?
  3. Who knows what about Agile? Asking the ‘most knowledgeable’ is a good question, but it only tells a portion of the tale. What we really need to know is the extent of knowledge that each role has in general. Whilst the Product Owner might be considered the most knowledgeable in 1% of teams, overall what is their Agile knowledge – poor, sound, good, excellent? How do we know as a community where we might need to focus improvement without knowing each role’s understanding?
  4. What is the business’s role in all this? A lot of the questions are focused at an IT layer and don’t allow answering and splitting responses based upon business versus IT – for example, are any of the Agile Champions actually from the business?
  5. Where does Lean Startup fit into the Agile Methodology used? I know of a number of teams going down this path and whilst you could argue it isn’t a methodology (nor are most of the options officially), it would be worthwhile having this approach added in.
  6. Where is ‘name your technique’ in the list of those employed? I still have no idea what ‘Integrated Dev/QA’ means – I am guessing it is eluding to a cross-functional team, but why not have the BA’s too? I don’t get Agile Games either. There is no practice or technique called Agile Games, games are a way we learn, it is a learning technique and has no direct relationship with Agile. Then we have the missing techniques – two fundamental ones beings skipped: Product Demonstrations/Showcase as part of Sprint Reviews and Backlog Refinement (formally known as Backlog Grooming). I wouldn’t put Burndown and Team-Based Estimation together either as they are two different things to me. It would be lovely to see Release vs Sprint Burndown split too.
  7. Where is ‘Cost:Benefit ratio no longer being acceptable’ as the major cause of Agile Project failures? Most Agile projects that I know get canned do so because the assumptions that were made at the start of the project no longer stack up and consequently it is no longer worthwhile to continue the project resulting in the project being cancelled. It seems to me that the ‘Leading causes of failed agile projects’ is actually talking about ‘Leading causes of failed Agile Transformations’.
  8. Where are the Kanban practices/techniques? Cycle time is there, what about limiting work in progress, pulling work, visualise and  manage flow, making policies explicit?
  9. Where are distributed teams as an organisational issue? I see this commonly as one of the biggest issues – is ‘failure to integrate people’ the same thing?
  10. How many Scrum Masters also have a ‘Project Manager’ title or responsibilities?  How many Scrum Masters also actually help the team to deliver? I would love to know the answers to these questions.
  11. How effective is the role of the Product Owner? There don’t seem to be any questions around this and I am curious as to whether Product Owners out there are answering questions in a timely manner, with the right information and how many are proxies?
  12. What is the difference in people’s minds between a Bug Tracker, a Taskboard and a Kanban board? To me they have always been one and the same. Where do portfolio management tools fit? What about retrospective tools? How many people are using a physical board vs a virtual (or both)?
  13. How many people are doing Agile versus being Agile? This is the question that I would love answered dearest of all.

So what would you like the State of Agile Development Survey tell you that it currently doesn’t?

Firstly I do apologise for the long absence on the blogging scene. This was in part due to my shift from Brisbane to Sydney, lack of internet, lack of technology, but also due to illness. So for my first blog back for the year I would like to implore you – PLEASE if as an adult you haven’t had any form of immunisation then go see a doctor and get some shots!

I was under the mistaken belief that I was fully immunised and didn’t need anything further in my adulthood and have been surprised to find that I was not covered when I got hit with Whooping Cough. Having been out of the country when the big Australian hoopla happened about Whooping Cough I was terribly ignorant of it and didn’t realise just how bad a bacterial infection it was. I am now six weeks into a three month problem and every day is very hard. 


Thankfully I didn’t share it with anyone (but sadly my kids did give it to me as carriers). Anyway, onto the blog at hand.

My preference over the years has always been to work with User Stories as my lowest level of work. I have never really felt like I needed to break stories further down into tasks in the manner in which Scrum does. The reason for this is fourfold:

  1. I like my stories to be no bigger than four days. Ideally they are around the 2-3 day mark to deliver end to end. If they are this small then individuals can still be held accountable for progress on the story.
  2. I have rarely seen teams care about how a Story is being delivered whilst it is in progress. The fact that a team member is working on the unit tests now and then will be going onto the database changes has little consequence to the functioning of the other team members. The ‘aha’ and roadblock moments I see coming out of the Daily Standups very rarely arise from technical implementation at a task layer.
  3. The time it takes to break the user story down could be considered waste. For me the value in estimation is not the number you get, but the conversation of assumptions, dependencies and constraints that you have on the way to get an estimate. You can still have these conversations when planning the iteration.
  4. The extra time that it takes to generate a Burn Down chart. I would rather have a look at the where the stories sit within the flow against the current day of the iteration and see if the team is behind/ahead from that. It isn’t a science like the Burn Down chart, but if you really think two to four hours is going to make a big difference you are probably looking at the wrong things. I find that teams that focus solely on hours being Burned Down only tend to have a lot of carry overs due to a lack of focus on getting the story wholly to done.

So recently I started working with a team that, when I joined them, were already using tasks and hours to track.  I made a conscious decision to not change or influence their desire to use tasks and consequently through myself with gusto into ensuring that all stories within the current iteration were fully broken down into tasks, estimated and tracked via a Burn Up chart (at the time there was too much volatility in the iteration from a change perspective to use a Burn Down).

What I found didn’t really change my dislike for tasks or burning down hours in the iteration but it occurred to me that when I focussed on work at an hour by hour basis rather than a day by day basis that I was becoming a scrum micro-manager. I instantly cringed at the realisation and wondered how empowered or autonomous the team felt from when they were being tracked at this layer.

So I asked them whether they felt that being tracked at a task layer, hour by hour felt like they were being micro-managed – the results? 71% of the team felt that it wasn’t micro-management, leaving 29% to feel the opposite. It would be interesting to see how this co-relates to performance, but I don’t think I will go into that on a personal blog.

Two of the team members did say they didn’t feel it was micro-management but expressed concern at the sheer visual weight of the number of cards on the wall. To put this into context at the moment we are mid iteration and have fourteen stories (consequently rows) in scope and around one hundred task cards flooding through the wall. This is ignoring the cards that are being fleshed out an iteration in advance (let’s ignore this slight scrumfall-ish behaviour), the product owner decision cards and the eighty story cards in the event horizon backlog. I do try to clean up the done work every day so that it looks a little less scary visually but at the start of Iterations I can definitely see it being a concern.

So what do you think – is it micro-management to track to the hour using tasks in Scrum?

It is highly regarded among many in the Agile community that:

  1. One of the most common causes of Agile transformational failure is due to either the lack of focus on or lack of effective change of the middle management layer.
  2. One of the more common successes of Agile transformations is when small, incremental or evolutionary change is encouraged (rather than what I have termed “legion” style transformation which includes massive roll-outs of training and sparse support).

But I wonder if there is a better way, a way that combines these two points together for more successful, albeit slower and less Agile Coaching consultative heavy model –

Rather than trying to teach Agile inside of an organisation day 1, instead work with the middle management layer to re-introduce learning as one of their key practices.


If middle managers spent one to two days a week learning what do you think that would do to the organisation? I think it might kick start the organisation in all sorts of unbelievable ways. I think middle managers, rather than being forced to have these new approaches thrust upon them, would instead be the most passionate advocates for them. They might not choose to try Agile, they may want to try something else, but at least they are experimenting and thinking wider than just the day to day firefighting.

I know some managers already do this, but it is the exception and not the rule. But why is this? Do managers stop learning because they think it ends at university? Do they stop learning because they think it ends when they finally get into a leadership position? Or is it because they no longer have time anymore? Always in meetings or always fighting a fire?

Maybe the only way that managers will have the time to create a learning culture is if they limit their work in progress and begin to trust and empower their staff more? Now if managers start to trust and empower their staff more because they have to limit their work in order to learn, it is sounding like a win-win to me.

What do you think?

A little while ago in a private Agile forum I saw a post by a person who was very frustrated with Agile.

Their main concern was over the manifesto value “Working software over comprehensive documentation”. The scenario that they presented was one, where as a Product Owner, they wanted to understand a few of the business rules that the product had within it. They were informed by the product development team that they would need to create a user story for it, prioritise it against the backlog and when it hit the top of the queue it would get done.

Now the Product Owner chose to put it midway through the queue, but they were still unhappy with the fact that given the team’s backlog it would mean they would get their answer to what they felt was a simple question in two months time.

Why can’t I have just some documentation so that I don’t have to wait two months to get an answer on this? If we were still using waterfall we would have the answer right now.

A few people responded that Agile doesn’t mean no documentation, that there is often the documentation that is needed, but obviously this was one of the rare cases that the needs were greater than normal.

My thoughts on the problem raised were almost completely different:

  1. By not spending time documenting everything the team would have saved time over a prolonged period. If the team had spent time documenting everything to the nth detail then it might have taken a total of two or three months additional effort, for something to only be requested once. Now think about how much extra development work, actual beneficial changes to the customer, that they would have delivered in that time.
  2. The Product Owner chose to prioritise this knowledge below half of the outstanding work. It was always in their power to make it the highest priority item if they wanted to.
  3. There is a bigger issue that is being ingored or overlooked – the fact that the team had a four month backlog. I am not saying that a four month backlog is wrong, I am saying that a four month backlog is worthy of investigation to see why it is so long and whether something can be done about the constraints in the system to lower it. Think about how the team may feel knowing that there is four months of work hanging over their heads. They are unlikely to feel inclined to innovate knowing that there is so much that the product owner still wants delivered.

Do you think if the backlog was only a week long that the original forum poster would have made a comment about the Agile manifesto not working? Of course not, they would have waited only a week to find out that information and the team would have been considered responsive in their eyes.

Seven years ago I was involved in an open debate at an IIBA meet up on the role of Business Analysts within an Agile environment. At the time my opponent contested that Business Analysts were defunct under Agile and were no longer required. I debated that they were still needed but that their role changed somewhat.

My main argument was that they were no longer the provider of lengthy requirements documents written in advance with little to no collaboration in the team. This didn’t mean that Business Analysts were no longer required to write any form of documentation, just the amount of documentation, the collaboration involved to reach a common understanding and the timing of when the documentation is done changed. With this reduced amount of time directly spent writing ‘War and Peace’ requirements they would instead use their time in a new skill set – as facilitators. I saw the role of the Business Analyst as being very compatible with the Scrum Master role, where the Business Analyst could encourage an environment of collaboration and ensure that the ‘promise for a conversation’ occurred. Business Analysts would still need to have skills drilling into the root cause of problems, to understand and analyse and question the business process, but in a good Agile team everyone would also have this skill.

Time has moved on and most of what I predicted for the Business Analyst role has come to pass within Agile environments. But I believe that it is time to make a new prediction.

We have come a long way towards mastering the art of building the product right, our next journey is to build the right product. After all, according to Lean principles, the biggest waste is the waste of overproduction and this can take the form of producing an unneeded or incorrectly targeted product.

Thus, in today’s ever shifting environment, I see the role of the Business Analyst as that of being at the heart of data. I see the role transforming to focus more on data analytics and the understanding of data associated with the product. Some may say that this is the role of the product owner, to which I probably wouldn’t disagree with and as such I see the Product Owner and the Business Analyst roles merging even closer together but with an incredibly strong focus on data.

So what is all the data that is being analysed about? Four things:

  1. Are we improving the number of customers seeking our product?
  2. Are we retaining our existing customers?
  3. Are customers getting value out of our product?
  4. Is our product revenue model generating net profit?

If the answer is yes to the above questions, founded soundly on data then your product is in a great place. If you cannot answer these questions then you really should start working on it (before you go out of business). For those of you familiar with the Lean Startup model then the above discussion should be something very familiar to you, for I believe the Business Analyst role should be centered around enabling the data gathering to support a Lean Startup approach.

You don’t have to be a start up to gather this data. You don’t have to measure once every three months. You can start measuring your existing product and incrementally improving on the four questions right now and everyday from this point onwards. Armed with this data  you can know whether a change you made today will make a difference to your business tomorrow.

Maybe the role shouldn’t be called “Business Analyst” anymore . Maybe we should start to create “Product Analyst” roles instead?


I am currently in progress of writing my first Agile book. It is basically a beginners Agile book targeted outside of the software development industry with a major twist.


If you would like to participate as a reviewer can you please contact me via twitter with an @AgileRenee mention and then I will send you a direct message to get your email address (if I am not already following you, otherwise just DM me). Alternatively you can email me at




This blog is in response to a number of requests about creating Agile games. I have spent the last two years creating a number of Agile games and whilst I certainly wouldn’t declare myself and expert next to the amazing machinations of @lukehohmann of Gamestorming I do try to make games that are fun, educational, simple and easily repeatable.

In today’s blog I want to describe the journey and thought processes that I took to build a game that I call “Kanuzzle”.

It started about two years ago when Russell Healy first introduced Kanban to me through his amazing getKanban game. Russell spent considerable time, effort and personal expense to produce this high quality, repeatable instructor toolkit. I enjoyed the game and found it quite educational but did have difficulty with the setup time and the time it took to instruct on how to play the game. Taking that aside I felt the participants in the room were able to pickup the concepts embedded within and the competition levels were high which increased the fun factor of the game.

When I returned to Australia I tried to find some interest for Russell’s game but there was a perception that the game costs were too high (for an instructor to purchase). I was personally less concerned with this as I understood the investment Russell had made, but was more concerned about the maintainability of the game once purchased.

As time went on the needs that I had for a Kanban game grew away from getKanban. I needed a game that was less software focused and was easily digestible to business specialists who were using Kanban outside of software development. I also needed a game that was quicker to kickoff and one that could be maintained an enhanced. Production costs were an issue and management ideally wanted games that costed little more than paper and pens.

So given these new constraints I went about building a new game. To overcome the production cost issue the board I created was printed on A3 and laminated. Tokens and any other artifacts went through a similar production method. This resulted in kits that cost a little more than a few dollars. Additionally I wanted to build in more “chance” to the game and brought in a design concept directly off Monopoly  building in “wildcards”. When a wildcard was landed on it represented the real life occurrence of an event that was either positive or negative to the team’s ability to deliver. The set of board steps was also fixed as opposed to getKanban’s varying cost to deliver a story. Using colour themes similar to Monopoly’s “set of hotels” I had colours that represented a number of board steps for a particular non software role.

Teams were given preset WIP limits for their board which was setup to deliberately be dysfunctional. After a few two person practices, I released my new “Kanbanopoly” game for training. The first few sessions resulted in some instructional tweaks but overall the exercise went well – I cut the exercise time down from 2 hrs to a 45 minute game. The game was run in three rounds (split among theory). The first round was the dysfunctional one. The second round the team were able to change their WIP limits as they saw fit against an overall resource constraint, in the third round they could change the WIP limits again. Team’s rarely got the WIP limit right by the second go but always did by the third.

But a few things concerned me about this variant. Firstly it was still taking too long for people to understand the instructions, especially the Cummulative Flow Diagram. Secondly people were having trouble making the leap between the game and what they were doing on an Agile basis from day to day.

So I did what any good game designer needs to be open to and totally scrapped it. My new requirement was that the game be runable within 30 minutes with similar production costs and a five minute instruction time.

What I wanted was the ability to have a massive wall and for the team to stand at the wall to do the exercise, in this respect it would be more closely aligned to what they were used to. But the problem was that they couldn’t deliver software in the classroom and I didn’t want them to do a manufacturing based game as I wanted to highlight the knowledge work element strongly. So I toyed with the idea of a game within a game and created “Kadoku”, a Kanban Sudoku variant.

Children’s Sudoku puzzles (of varying difficulty) were printed and a value was attached to them. They were then cut up and placed on the wall with a pre-setup WIP limit. Roles were given out and metrics were kept. The WIP limits were setup for success but deliberate defects were put into the puzzles to force certain roles to hit their limit and cause a flow issue. The game went fairly well as far as the lessons learnt. The instruction time was certainly reduced and the costs were even lower. Additionally it felt more familiar and transposable to the participants. But there was a serious issue. Defects took too long to resolve and the Sudoku execution itself was taking longer than expected with each puzzle taking between 8-10 minutes to get out. Simpler puzzles took too short a time being doable in under one minute.

So that variant was re-adjusted. I scrapped the Sudoku puzzles due to their complexity and went with simple kids puzzles that should be achievable by 7-10 years olds. The game was renamed to “Kanuzzle” and re-run. This game has now been running for about eight training sessions without further issues and is now considered final. The cost is about 20 pieces of colour paper and blu-tack. The setup time is about fifteen minutes to cut out the puzzles, blu-tack them and setup the physical board. The instruction time is about 3 minutes and in game running time is about 15 minutes. The design intent from a learning perspective is to get a feel of the Kanban concepts with a particular focus on WIP limits, managing flow, pulling work and handling expedites. People won’t be experts by any stretch, but they will be informed enough to now give it a try and self-adjust.

So lets take a look now at the things that you need to consider when building your own Agile game:

  1. Who is the audience? What will they know? What won’t they know? What terms may be unfamiliar for them?
  2. How much time do they have to play a game?
  3. How much time do you have to run a game in the context of the rest of the training?
  4. How much time will it take for you to preset/reset the game? Is this something that you can afford?
  5. How much time will it take you to instruct in the game? Is this something that can fit into yours and your participants training time?
  6. How much time does the game and any post-retrospective debrief take? Is this something that you can fit into your and your participants training time?
  7. How much do the physical gaming materials cost? Are they re-usable?
  8. Is the game maintainable? Can you adjust it and re-run with adjustment costs being minimal?
  9. What key messages do you want to get across? What agile practice(s), principles or values are you trying to re-enforce?
  10. What would be nice to get across if you had time?
  11. Can participants easily relate this to their work?

Also keep in mind general game building considerations that all games should adhere to (for more information checkout my Gamification and Agile slideshow):

  1. There needs to be clear and defined goals or outcomes that have to be achieved
  2. There must be a set of rules in place to limit how you go about achieving that goal
  3. The environment must provide feedback to tell participants how they are going or whether the game is ended
  4. They must be voluntary

In the case of Kanuzzle the answers to these last four questions are:

  1. Achieve the most value. Two teams compete against each other. By default the puzzles are ordered according to sequence and not value, part of the design intent is to get them to spot that the backlog is not value prioritised and then to re-adjust it.
  2. Limits are enforced by WIP limits on the board and through rules for handling expedites and roles for the game. Roles are loosely set so ideally by the end of the game no one cares about their role, they are just focused on the flow. Additionally by forcing an error into the flow early it forces the team to deal with flow issues and understand what it feels like and the impacts that it has.
  3. Feedback is provided via timing each puzzle and through provision of graph tracking. Instructors also give feedback on game end time.
  4. They must want to learn and participate in training

As part of my back to basics series I wanted to spend some time on the topic of Retrospectives, otherwise known as Introspection or Reflective Improvement sessions.

If the Stand-up is the bread, then the Retrospective is the butter. It is simply just one of the most fundamental elements of doing/being Agile there is. Alike Stand-ups, they are just as easy to be ineffective.

At its most basic process this is how to run a retrospective:

  1. Get the core team together
  2. Give the core team 10 minutes to brain-storm their thoughts on how the last Sprint/<insert cadence cycle> went in terms of:
    • What is working well?
    • What to do differently?
    • What still puzzles us?
  3. Group like thoughts together
  4. Choose items to focus on and address
  5. Make actions

Let’s break these items down a bit more:

Get the core team together

It doesn’t have to be in a meeting room. It can be in the pub or in a park. In fact, the team don’t even physically have to be together – you can do retrospectives virtually using a tool like LinoIt. What is important here is that the team needs to feel safe to speak freely and that there is an environment where there are no elephants on the room. If you have a Project Manager or a Product Owner that will not be conducive to such an environment then you have a bigger problem here – re-focus the  retro on getting this fixed!

Brainstorm for 10 mintues

There are five points I want to make on this sub-activity:

  1. The duration to reflect on is not important, but framing and frequency is. Retrospecting once every three months is not being Agile. The more frequent you can do this activity the better. Keep in mind, as you increase the frequency you may need to spend less time doing this activity – ie if you choose to retrospect each day then it could be a ten minute activity.
  2. Ensure the brain-stormed items are put on a single post-it note and are clearly legible so that you can take a photo of it later. There is nothing more annoying then spending time capturing/documenting the retrospective. Take a photo of the outcomes and stick the photo on your team’s wiki.
  3. I sometimes like to add a fourth item, “Lessons learned”. I believe that celebrating what we have learnt together as a group is very powerful and enables both sharing of information and a recognition that we aren’t perfect and it is a good thing to always learn.
  4. Sometimes people like the second question to be phrased as a negative and not solution focused question – ie “What isn’t working well?” vs “What to do differently?”. The benefits of the “What isn’t working well” approach is that it doesn’t assume root cause and leads to potentially better solution analysis later within the retrospective. The downside is that for the people that aren’t good with dealing with criticisms this can sometimes be confronting. I don’t think it matters which you choose, just be aware of the risks given the wording and work out which format better suits your team.
  5. The focus on the reflection is not what was produced but how the team worked together to deliver.

Group like thoughts together (affinity mapping)

Notice that I didn’t say how to do this? That is because your mileage may vary based upon your approach. The Scrum Master can do this once everyone has written their thoughts, or the core team can do it themselves – either one at a time or as a collective. You can read them out or get the team to quietly read it themselves, the options are really endless. My personal preference is to get the core team to affinity map themselves and then to verbally skim through the non grouped items and spend more time on the strongly grouped themes. Items under “What still puzzles us” should be answerable on the spot or may become a focus area.

Choose items to focus on and address

Usually I would choose the strongly grouped themes but there is a risk that you miss something important that can significantly improve your ability to deliver as a team. What is important is that the items you choose to focus on are the ones that will result in marked improvements for how the team will work together.

It is a rookie error to focus on ten things within a single retrospective. If you have two weekly Sprints, you ideally don’t want to focus on any thing more than three (five at absolute tops) actions. This is because you want to ensure that you are making changes and if you have too many actions then nothing will change and then you will loose all support from the team for doing this practice in the future.

Who makes the suggestions of the changes? The core team does. It shouldn’t be the Scrum Master who is imposing change on the team, it should be the team embracing an environment of continuous evolutionary improvement.

Make actions

So along with only having three actions you want to ensure that these actions address the root cause of the problem (ie you are not solving the wrong problem), that the actions have clear owners, dates (if possible) and value.

The best actions I have ever seen out of a retrospective are ones that the team writes as stories and then feeds the stories back into the release or sprint backlog – ie they get treated like everything else. Because they are treated like everything else they get a priority and estimate which means that they have to have value as agreed by the whole team in order to work on them in the current Sprint.

If you aren’t going to write them up as stories and add them to your backlog(s) then make sure the first step you do in your subsequent retrospectives is to review previous actions. It is a smell when actions get carried over from retrospective to retrospective – it is symptomatic of items that weren’t perceived as important or that the team feel that continuous improvement is not important.


Software development isn’t simple. The only way that we can improve in the complexity that we are working with on a day to day basis is the reflect and adapt. Sprint Planning and Sprint Reviews are the way in which we reflect and adapt the work we are doing. Retrospectives are the way we reflect and adapt how we are doing our work.


Get every new post delivered to your Inbox.

Join 1,098 other followers