This Agile game is based on The Penny Game.  I’ve seen it in various incarnations, but this is based on the original concept.  Instead of simply showing how batch size affects throughput, this game has been heavily modified to give several additional lessons.  Attendees can expect to learn about Agile’s roots in Lean manufacturing, batch size theory, single piece flow, being adaptive to change, quick feedback and communication.

Each round after the first is essentially optional, you can choose exactly which lessons you wish to deliver.  This may be all of them for more experienced teams, or fewer for those new to Agile.

Timing: 20 – 60 minutes depending on team size and number of rounds.


  • 20 x pennies
  • 10 x larger denomination coins
  • Whiteboard / Blackboard / Flipchart
  • 1 x stopwatch per team
  • Post-Its
  • Pens for Post-Its and board


This game will be run over several rounds, with each round introducing a new concept.


  • Split your group into equal teams of at least 4, ideally not more than 6.
  • Choose one person from each team to be the timer.
  • If there are people left after this split, they can take charge of recording the results.
  • Each team should form a line, sitting down along the edge of some work surface, like a table length.
  • Ensure the timer for each team has a stopwatch.
  • Give each team an equal amount of pennies (around 8 – 15 is good).
  • You should now have equal teams with an identical set of coins in front of the first person in each team. As below.

Penny Flow Setup

  • Draw a large grid that will hold the scores for the completed rounds.  Something like:



Round 1 – Batch Size:

Explain to the group that they each form a different team.  Each team will complete the same work, which in this case is the flipping of coins.  Each team member will need to complete the work in batches, before passing the batch to the next person.  People are only allowed to use 1 hand, and the batch must be stacked in a tower before they can pass it to the next person.

Give each person a job title to model a real project.  Commonly, this would be some subset of ‘Analyst’, ‘Designer’, ‘Programmer’, ‘Tester’ and perhaps something like ‘Acceptance’ if needed.

Tell the teams that you are the client, and that when the batch reaches you, they have delivered that value.  Tell each timer that they must record the time it took for the first and last batches to be processed.

Finally, tell each team that they will be working with a different batch size.  For 2 teams, use a full batch (the amount of pennies each team has) and 1 for the sizes.  This will result in 1 team processing pennies individually before passing them, and another processing the whole batch at each station.  With more teams, use intermediate numbers; so for 3 you would use 1, 5 and 10 perhaps.

  1. Get each team to stack their coins in the required batch sizes.  Teams working on a single coin can simply use a heap.
  2. Start the teams working with a countdown.
  3. Ensure players only use 1 hand and that the work is completed according to their batch size.
  4. Ensure the time taken for the first and last coins for each team is recorded.
  5. Stop timers when all work is completed.
  6. Record scores in the appropriate sections of your grid.
  7. Asks teams to discuss what they noticed.
  • The conversation will often be limited with more experienced teams here, so it’s unwise to linger on lessons that are already known.
  • People should note that smaller batch sizes allowed other people to start working earlier.
  • Indicate that even if the final times were very close for both teams, the teams with smaller batches were delivering value almost immediately. Reference the Agile Manifesto with regard to early and continuous value.
  • The team working with a single batch size have been using single piece flow, first pioneered in the Toyota Production System.  It is largely this process that helped fuel the Lean movement, later translated to software by Tom and Mary Poppendieck
Round 2 – Reactive to Change:
Tell everyone that you will be doing the same game, but with some additional coins.  The timers will complete the same role as they previously did.  All other aspects of the game will be the same.
  1. Evenly distribute the other coins through the batched stacks of the teams.
  2. Start the teams working with a countdown.
  3. Around halfway through, announce that you have changed your mind and now only want the pennies.
  4. Allow the game to finish and record the scores.
  5. Ask the teams to discuss how the exercise went.
  • Teams should see that with large batch sizes, there was a lot more wasted effort that went into processing and stacking unneeded coins.
  • Teams should see that larger batch sizes made it more difficult to separate the required from the extraneous work.
  • It should be noted that smaller batch teams were able to ignore the other coins once the change came in, reducing the wasted effort.
Round 3 – Quick Feedback:
The teams will now continue to use all of the coins, but change requests will no longer play a part.
  1. Give each ‘Tester’ (Or simply choose one of the latter work centres in the chain) in your team a note that says the following: “We need all coins to be face down, reject entire batch back to Developer.  You can say why.”.  It is vital that this secret message is not shared with other teams or anyone else on their team until the first defective batch has reached them.  The aim is for the ‘Tester’ of each team to reject the first faulty batch, explain to the rest of the team why it was rejected, have it ‘reworked’, and then successfully complete the remaining batches.
  2. Allow the game to finish as normal.
  3. Ask the teams what they noticed.
  • Teams should note that with larger batch sizes, the amount of work wasted was much higher.
  • Note that smaller batches allowed for significantly quicker feedback to the team, reducing waste.
  • Watch for teams repeatedly failing batches because the message wasn’t passed all the way back.
Round 4 – Bottlenecks:
This time we will model bottlenecks, and show the difference between local and systemic optimisation.  Ask each team to identify their primary bottleneck.  They should identify the first work centre as it is this person who delays the next from starting.  You may see people identifying themselves because they are slow, steer the conversation towards a more general view.
Next, ask the team how they would optimise that bottleneck.  You will generally see people saying that they would use more people.  Use this and say you are going to simulate that by allowing that person to use two hands for the next round.
  1. Tell the first person in each chain that they can now use 2 hands to process their batches.  Each batch passed to the next person MUST be stacked on top of the coins that person is waiting to process.
  2. Start the countdown to begin the game.
  3. Allow the game to complete and record the scores.
  4. Ask the teams what they noticed.
  • The times should be slightly quicker here.
  • You are looking for the teams to mention that work started to build up further along the line as the rest of the team struggled to keep up.  they should identify that resolving their primary bottleneck has given way to another.
  • Note that the work being built up before bottlenecks represents inventory.  Show that this is expensive to store for companies and often increases overall time due to the extra work required in maintaining it (The stacking).  This corresponds to the cost in manufacturing of storing large volumes of parts in warehouses.  By eliminating the need for storage using ‘Just In Time’, companies reduced the cost of maintaining and transporting that stock.  In software, this represents stories being stuck waiting for a person to complete the next step in the chain.  This increases the cycle time of that story, delaying value.
  • Ask what would happen if you continued to optimise your first person.  You would be unlikely to see a decrease in overall time because you were optimising something other than your bottleneck, this is the difference between local and systemic optimisation.
Round 5 – Optional:
You may additionally run the game with a further optimisation on the first player here, just to highlight the point of local vs. systemic optimisation.
Alternatively you could choose to allow all teams to optimise their bottlenecks by using 2 hands for every work centre.  This would allow the teams to finish with their best output.


Concluding Notes:
For me, the benefit of this framework is that there are so many lessons to take from it.  Different people will see different things, don’t be afraid to run your own experiments in additional rounds; even asking your teams if there is something that they would like to model.


Thanks to David Grant, Matt Pearce, Matt Grover, Steffan Liassides and the South Wales Agile Group for their assistance in refining this game.

Risk Management is a part of everyday life, crossing the street or even walking downstairs in the morning carries with it some risk factor.  A project is no different.  When projects were managed by default by using high overhead techniques such as PRINCE2, risk was an integral part of running a project; they were cataloged, monitored and actively mitigated through the use of logs and registers.  Many of us have since abandoned these heavy methods in favour of lighter approaches, such as Scrum or Kanban.  However, amid all of the confusion in the revolution, we appear to have thrown the baby out with the bath water.  Even now, risk is rarely included as an active element in our practice, and rarely done well.  I would propose a new method of managing risk, something lightweight that fits with our de facto practices, but with the rigour of the old guard.

What is Risk?

First, let’s define risk.  The ISO31000 standard defined risk as an uncertain event, which should it occur, will have an effect on the project meeting it’s objectives.  Notice the lack of connotation here, risk isn’t some inherently bad thing, it’s simply a degree of uncertainty.  The message is clear, we should be looking for, and actively managing, all forms of uncertainty.

Risk sits in the middle of cause and effect, some cause may trigger an effect, although we don’t know.

Risk Context

Continue reading

Tracking Agile Projects is about monitoring the project health, and checking adherence to the schedule is a relatively simple exercise.  The amount of work actually completed in an iteration is compared with the amount of work expected to be completed.  Differentials are feed back into the amount of work expected to be completed in the future iterations, which has a self corrected effect on the project schedule.

Monitoring the Release Plan

The easiest way of showing this information is by using a release burndown chart.  This chart displays the amount of work remaining on a release and the teams progress over each iteration.  This diagram is updated at the end of each review.

The following diagram depicts a fictional project.

  • The total number of points for the release is 200
  • The estimated velocity is 20
  • The iteration length is 2 weeks
  • The red line indicates the trend line that should be followed in order to achieve completion on time.
  • The blue line indicates the actual decrease (Or burndown) following each iteration
  • The black line is a trend line for the actual burndown, indicating an estimated completion of 13 iterations.

Release Burndown

From this diagram ,we can immediately derive the following information regarding the release:

  • The average estimated velocity is slightly lower than anticipated and should be corrected accordingly
  • The project will overrun by an estimated 6 weeks
  • In iteration 2, there was actually a “burn up”, where more scope was added to the backlog than was actually completed during the iteration.
  • The significant scope change in iteration, coupled a slightly lower than anticipated velocity appear to account for the overrun.

The project manager and owner have the following corrective actions available to them:

  • Remove 3 iterations worth (60 points) from the release
  • Accept the new release date
  • Remove some features and accept a slightly later release date

Monitoring the Iteration Plan

Within an iteration, it is often more useful to monitor health at a lower level.  Task boards are the most useful way of portraying this information.  Task boards display the stories to be completed in the current iteration.  These hourly estimated tasks for each story are displayed next to the story across multiple swim lanes to represent what stage if development the task is currently in.

As tasks are started, developed, tested and verified; they will be moved across the representative swim lanes.  When all tasks relating to a story have been verified, the story itself is considered complete.

Tasks are measured in terms of hours, so the remaining estimates within the task board will be given in hours.  This allows developers to see exactly how many ideal hours they have left in the iterations.

The following diagram depicts a task board in progress.  Note that within LexAble, our swim lane for “to Verify” is called “Waiting for Testing” in order to be more explicit.Task Board

Although the task board is excellent at representing the state of the tasks and features within an iteration, it does not give a very clear picture of work left to complete.  For this, we use an iteration burndown chart, similar to the release burndown previous discussed.  Instead of summing the remaining story points, the total remaining hours should be used.

This chart shows that because the actual work completed line is below the expected, the team is ahead of schedule, but generally appears to be following the expected burndown.

Iteration Burndown


Communication within an Agile team should be open, honest and frequent.  The charts given above very clearly denote the health of a project at a variety of scales.  Favour these lightweight diagrams over complicated and unnecessary reports.  As previously discussed, there a few formalised meetings within an Agile lifecycle, these are summarised below.

Release Planning

The first discussion, where themes and larger stories are identified and estimated.  This will output the release plan.

Sprint Planning

Completed at the start of each iteration.  Appropriately sized stories are selected and broken down into hourly estimated tasks.

Sprint Review and Retrospective

The team reviews the iteration, gathering lessons and new risks.  New features are added to the backlog and it is re-prioritised if necessary.  The project health will be reported to the owner, but this information should be freely available throughout the iteration.  Estimations are also adjusted if required.

Release Review and Retrospective

Complete release review, including lessons, risks and process improvements.  Project archival will be completed.

Agile Planning and Estimating covers the activities involved in actually planning how the software being developed is going to be built, splitting up the development into manageable pieces and deciding a schedule for the release.  This part of my Agile development guide is based on the excellent book by Mike Cohn, Agile Estimating and Planning.


The following picture, taken from, provides a clear overview of the activities completed during an agile project.

Scrum Plan

Release Planning

A release plan is the high level plan that is used to identify what needs to be completed and what time frame is required to complete enough before a releasable product is achieved.  The release plan is also the milestone that the team will be working towards over the course of the project and is used in determining overall project health.  With this plan the team has a clear goal of not only the project expectations, but also the expectations of the team; it provides overall goals.

A project must have objectives, this is most often financial but can be evaluated in a number of different ways.  I’ll write another post of producing a business case  to detail the steps that can be taken in evaluating and justifying a project.  Realistically, a project should deliver value in the most efficient way possible.  It may be the case that realising 80% of the total value in only 20% or 50% of the time is far more desireable.  Identifying what themes are required to deliver the desired outcomes is a critical part of this stage.

A project may be feature driven or time driven.  In the former case, the team will derive a time scale by summing the points for all of the selected stories, dividing by the teams velocity (To give the number of required iterations) and then multiplying by the length of the iterations.  This will generate the expected time to completion for the project.

For a time driven project, you should calculate the amount of available story points and then proceed add stories until the allotted time has been filled.  You can determine available story points by dividing the time frame by the iteration length (To give available iterations) and then multiplying by the velocity.

In order for a sponsor to identify what the objectives, constraints and expectations of a project are, the team should have estimated any themes or stories that may have a reasonable chance of being included in the release.

With the completion of these activities, the project will have a justified reason for undertaking it, expectations of various stakeholders and both time and cost estimates.

The final stage is to sketch out at least the first iteration, and possibly an additional 1 or 2.  Planning further than this can be wasted effort as when new knowledge about the product and project is obtained, future priorities will undoubtedly change.  It is often best to simply keep the next iteration planned and ready to go, the following 1 or 2 roughly planned and the remaining stories in the backlog.

Continue reading

All relevant stakeholders should be present at this meeting, including owner, Scrum master, clients and developers.  For a Scrum overview, please see Agile Overview.  This guide is heavily influenced by Mike Cohn’s Agile Planning and Estimation.

Choosing Themes

At project initiation, the team will meet in order to determine the themes and goals of the project.  In determining these themes, many factors will need to be considered.  These themes will also need to be estimated and prioritised so that the development team knows what to build.  These initial themes will form the general functional requirements for the project and will be expanded upon later on, when more knowledge is gathered about exactly what needs to be done.  The owner will determine the themes, but the developers will aid in this choice.  Developers can help this decision by indicating the risk level or dependencies of each theme.  These themes are often written on Index cards and should be considered at a high level of abstraction, such as:

  • As a user, I require the ability to add new cars so that I can manage my growing stock.
  • As a user, I should be able to buy items using a credit card so that I can process my order quickly and securely.
  • As a user, I want the software to record my high scores so that I can try and beat other scores.

Note that there is no technical specifics here, these are simply general, high level features that the user requires for the product.

Continue reading


Contrary to traditional management methods, an Agile approach considers the team to be a single cooperative unit.  Individuals are not scored on the amount of work completed, but the team is monitored as a whole.  This serves to improve team cohesiveness and ensure that anyone working on a project is dedicated to the success of a project through collaboration.  You are all in this together.

Product Owner

The product owner is the individual responsible for establishing a common vision.  This person is often the sponsor or customer of the project.  The owner must be the lead in identifying features (Stories) and prioritising the workload such that the highest value is being delivered.

Continue reading


When somebody wants to backup either the JIRA or Confluence onDemand databases.


Atlassian onDemand does not currently have any features for automating a backup of either JIRA or Confluence.  To get around this we can trigger a backup from Atlassian and then automatically download the resulting file to a location of our choosing.  We can take this a step further by automating this processes with a cron job on Mac or Unix, or by using Windows Task Scheduler.


These scripts were based on one given for Jira by Marlon Aguiar of Atlassian, the original can be found here.  Some minor modifications were made and a separate script for Confluence was created from the resulting code.

Continue reading

The following is an adaptation of content I wrote to help a new agile team.  It was meant to be a brief skim over the surface of estimation, rather than an exhaustive document.  It generally sticks to the classical agile approach, but has some additional techniques that I have found useful.  The information on which this is based is largely attributable to Mike Cohn, of Mountain Goat Software, perhaps my favourite technical author of all time and, for me, certainly one of the most readable.  I would love to hear peoples opinions on estimation, feel free to drop me a line with any tools and techniques that you use.


Story Points

It is very difficult to provide an off the cuff estimate for something unknown.  We may hazard a guess or try and compare it to something else of similar or relative size.  If asked to estimate the size of a mountain, it would be much easier to estimate it as double the size of another mountain than to specify a weight in kilograms.  There is also significant scientific evidence to support the hypothesis than humans are much better at estimating relatively than absolutely.

Story points are way of estimating effort to complete a feature that decouples that tie to specific units of measurement, such as time.  By estimating effort in relation to other estimates, we can derive a value for time.  Because we have estimated relatively, our final value for time is likely to be more accurate.

A story point is a unit independent measurement of effort required to complete something.  Features are measured in a number of story points.

A useful video by Mike Cohn discussing User Stories can be found here:

Continue reading

I was rummaging around in some old directories and found an implementation of the Sieve of Eratosthenes that I’d thought I’d share.  I thought I’d share it because of the simplicity of the algorithm, it represented a very enjoyable programming exercise and one that I now use as a standard kata when learning a new language. The Sieve of Eratosthenes is an algorithm used to identify prime numbers.

In it’s simplest form, the algorithm states:

set Array to array of size N
set Array to all true
for i from 2 to N
  for each j where i divides j, j from i + 1 to N
    set Array(j) to false

Basically, it trawls an array of “on” bits and “turns off” any index that is cleanly divisible by any number less than the square root of it’s size.

Continue reading

The tag line for the blog is “Lessons from The Code Face”, a reference to the coal face where miners would hack away at the stone in their search for black gold.  This, and the “Mining Code” title, seem to give an unfair assessment of the coding craft.  Comparing coal mining to the intricate art of computer programming?  Preposterous.  However, as I sat down to refute my own title and explain it away as simply an evocative name, I began to see correlations (Which I suspect was easier because I was actively seeking them).

Mining implies hard work, potentially long hours and a subtle skill with the tools, which are all true of coding; it also implies that anyone can just show up and start swinging an axe to get some results, but true mastery takes practice and constant improvement, which is also true in part.  More and more attributes match: a focussed purpose, teamwork and a certain element of risk taking.  Although these are arguably all attributes that constitute a recipe for greatness in any field or purpose, it does highlight that perhaps the correlation between coal mining and code mining isn’t too stretched; therefore justifying, at least partly,  my poor pun.

This blog is a way for me to reflect and codify my own lessons, offer any subjective advice that I may have to others coming into the mine and as a learning opportunity.  I hope that the act of putting these into words may consolidate my own understanding, and offer a forum for others to share their own advice with me.