Release Wednesdays

This Wednesday, one of the teams I work with shipped a new version of their product – the DLM Dashboard – for the 10th Wednesday in a row. That’s 10 releases in the 10 weeks we’ve had of 2015 so far. Which is pretty cool.

One of the notable things about that release record is that we haven’t shipped on any other occasion in 2015. That’s because we made a working agreement to release only on Wednesdays. Imaginatively, we call this initiative Release Wednesdays. Yes, it’s a thing.

As a result of putting Release Wednesdays at the heart of how we develop and deliver software, we’ve optimised our projects, processes and practices so that we can to release frequently and deliver new features incrementally. Interestingly, in addition to increased pace of delivery and user feedback the weekly cadence gives us, we’ve found many of these optimisations to be beneficial in their own right.

Before I highlight some of those optimisations, here’s a quick synopsis of ‘why’ we have Release Wednesdays:

We release every week because:

  • We want to give our users valuable enhancements as quickly as possible and get timely feedback on the direction we are taking the product.
  • We believe in keeping the delta between releases small and the risk associated with an individual release low.
  • We think practice makes perfect and that the more often you release the less frightening it is to do so.

We only release on Wednesdays because:

  • We want to have a ‘deliberate’ release process, not an ‘opportunist’ one.  An opportunist release process results in an irregular release rhythm; sometimes there might be three releases in a week, sometimes one a month. You release when you can. A deliberate approach to frequent releases means a regular, sustainable rhythm.
  • It keeps us honest. In order to achieve our goal, we need to be able to keep our build ready for release continually.
  • We don’t have to think about when to release. An opportunist release process means that you need to continually agonise over whether ‘now’ is a good time to do a release or not. That decision can take time, effort and (possibly) a great deal of thought. Agreeing to release every Wednesday means that our ‘when should we release?’ problem is solved.
  • We don’t want to drown our users in updates. We think that one release a week is frequent enough for users to get their hands on the latest work we’ve done and give us timely feedback, without the update notification becoming irritating.

How we’ve optimised our approach for Release Wednesdays:

  • The team are responsible for the releases – they decide when things are shipped. In parrallel, I’ve encouraged them to buy into a weekly release cadence and do my best to coach them when they discover obstacles to delivering stories. Without the team being behind this initiative, it was not going to work. Once the team had tried it and liked the momentum we achieved, the approach was here to stay. Now, getting then current story done in time for next Wednesday is hugely motivation for the group.
  • We’ve streamlining our release process – automating everything we can and simplifying everything else. For example, we rely on automated testing to prove builds and, thanks to an internal tool, we can deploy to Production with the click of a button. See my post from 2013 about the benefits of automated deployments.
  • We break our work up into small, incrementally valuable user stories. This is so that they can be integrated into our weekly cadence – each story should be around a week to two week’s work for the team. This is obviously a bit of a black art, so we’ve had to think a lot more deeply about the scope of our user stories and their relative value. We have found that we have a much more ‘agile’ backlog and a good feel for what we can achieve in a week.
  • We keep the product code in a continually releasable state. This is a working agreement and has pushed us to use separate branches for each feature, user story or bug fix, so that the root of our source control repository only has work that is fit for immediate release. An additional benefit of this is that any parallel streams of work (e.g. a new feature and a big fix) are isolated from one another and so can be shipped independently.
  • We apply the Agile Release Train technique, which has brought it’s own benefits – #NoEstimates, Team-driven scope management and clear planning horizons. See my recent post on the Release Train for more details.

Just to be clear, almost all of these optimsations have caused us problems from time to time. For example, we sometimes find it difficult to keep within the bounds of our small stories and the pressure of always want to get something finished for the next Wednesday can feel relentless if we are not mindful of it. It’s also fair to say it’s not going to work in every environment, with every kind of software development project. However, we build a COTS product which is installed on hundreds of client machines across the world and it works well for us. I really beleive the benefits of a deliberate, weekly release cadence far outweigh the disadvantages.

I’d encourage other teams to experiment with Release Wednesdays – well, to try deliberate releases on a day of your choice at a fixed cadence (weekly, fortnightly, even monthly). We probably shouldn’t all choose Wednesday. If the enitre world released their software on the same day, it might be a bit wierd.

5 benefits of the Agile Release Train for a single team

To some the Scaled Agile Framework seems like agile with it’s heart removed and the process turned up to 11; a set of guidelines and practices designed by consultancies to sell “Agile” to organisations undertaking large software development programmes. They believe it’s promises to synchronise, homogenise and constrain a legion of development teams are irresistible to companies that want to partake of the Agile Kool-Aid but don’t want to embrace its spirit. Despite all that bad press, our single, small development team has found one of the tools the framework advocates incredibly useful – The Agile Release Train.

As I detailed in my last post, my team use a train visualisation to help plan and deliver Redgate’s latest product, SQL Lighthouse. We don’t work in a multiple team programme that would require the Scaled Agile Framework (and if we did, we’d probably shy away from its prescriptive nature), but we’ve found that the train metaphor it prescribes unlocks the potential of our existing regular, frequent release cadence.

Release Train visualisation

Release Train visualisation

Aside from the obvious product planning benefit of the visualisation, we’ve found that there are significant other advantages of using an Agile Release Train. Here are my top five side-benefits:

1.  Small, independent user stories

To be able ship a valuable piece of functionality every week (or two) and assemble a train which makes use of each available release, you need to break the functionality to be delivered down into the smallest units possible. Although this has always been a characteristic of good backlog management, regular weekly releases makes this mandatory. Additionally, to be able to make the most of the opportunity to reprioritise and shuffle a release train plan based on new information (user feedback or slower/quicker progress), making these stories independent is also very useful. Without having to be particularly deliberate about this, our user stories have ended up valuable, small and discrete.

2.  #NoEstimates

As a consequence of the Release Train encouraging teams to break functionality down into the smallest possible valuable blocks, these blocks tend to be a similar size. Over time, the team has developed a good sense for how long one of these blocks will take to complete and this is surfaced by the team predicting which release a piece of functionality will be ready by (“yeah, we can do that for next week”, “nope, we’ll miss the next release with that one”). Although the granularity of these hunches is simply the length of time between releases, we’ve found these to be accurate enough to allow us to plan, track and respond according, which (in a sane world) is the point of estimates. We’ve found no need to break out the Planning Poker cards, Ideal day estimates, t-shirt sizes or a ouija board so far.

3.  Team-driven scope management

As the team was central to the assembly of the release train, predicting when functionality will be delivered and building up a chain of releases to meet a goal, they can easily appreciate the knock-on effects of an overrunning story or blocked release. With the wrong team, this could be a problem – encouraging people to relax their quality principles in order to expedite some work and keep the train on schedule. With the right team – one that understands that the release train is not a formal schedule to be obeyed but a prediction that helps us make decisions –  this foresight encourages the team to ask the right questions to control scope throughout the project.

My team are aware of the effect decisions in the present will have on our future success and as a result are very sensitive to scope-creep, gold-plating and ‘lone wolf’ developers. This doesn’t stop us from going the extra mile to make a piece of work awesome, but when we do we are aware of the consequences and make those decisions prudently.

4.  Clear planning horizons

Many agile teams I’ve worked with in the past have struggled with the question of how much preparation to do ‘up-front’ for each piece of work. Ideally, user stories at the top of a backlog (earmarked to be worked on soon) should be well understood (with acceptance criteria, notes on what is out of scope and even a story points size). Stories halfway down the backlog might be represented by a single sentence – “As a user, I want … so that I can …”.  Pieces of work at the bottom of the backlog are epics – mega user stories that cover a large undertaking and will eventually break down in many individual stories.

This is great, but this can sometime leave the medium-term plan for a project somewhat opaque or unfocussed – with only a hazy idea of what work ‘may’ be tackled in the future. Also, because agile teams can change direction quickly, Product Owners have been known to pull work into the next sprint from the middle or end of the backlog in response to customer feedback. As a result, teams can find that a poorly understood user story is suddenly something they need to start ‘right now’.

Applying the Release Train has encouraged us to think about the wider objective we want to achieve with a chain of releases – for instance, to improve user retention or support a new use case. Our 2015 planning activities have involved queuing-up a number of release trains each with a distinct objective. When we near the time earmarked for a new train to start, we go about assigning the chunks of work we feel are necessary to achieve the train’s objective. As I mentioned above, those chunks are broken down into the smallest, valuable pieces we can envisage. The acceptance criteria that help judge whether a piece of work is complete, tend to be established as a side effect of the process.

What we’ve ended up with is a string of well understood, fully-planned pieces of work that are very likely to be undertaken soon. Future Release Trains are not broken down into stories until we near the end of the previous train. This approach has given us clear, sustainable planning horizons and ensured we only spend time discussing the minutiae of work that will be started imminently.

5.  Intrinsic release cadence

Delivering a product using a Release Train has meant that our weekly release cadence is now metronomic and fundamental to our approach to software development. The dream of agile development – getting valuable functionality into users’ hands as often as possible and receiving feedback that helps modify our plans, hopefully delivering a better end-result – is now second nature. It would be almost impossible to stop doing “Continuous Delivery”.

Our development practices are tuned to be able to release at the drop of a hat, our automated tests are reliable (if it’s red, it’s broke), we split our work into week-sized chunks and we plan in the knowledge that we’ll be incrementally delivering features to our users. There’s none of this ‘potentially shippable product’ rubbish at the end of a sprint, just shipped product.

The end of the line

So, even if the thought of applying the Scaled Agile Framework makes you burn with agile indignation, consider giving the Release Train metaphor a go with your team to unlock the potential of your frequent releases.

Laying the track as we go: New product development and the Agile Release Train

The ‘Agile Release Train’ has been popularised as part of the Scaled Agile Framework – a set of guidelines aimed to bring agile software development to the enterprise and programme delivery. In the framework, the train metaphor is used to describe a series of iterative releases set to a strict schedule that multiple teams must abide by in order to synchronise and ship their work.

Laying the track as you go

Laying the track as you go

We use the “train” metaphor to communicate a few key concepts.

  • The train departs the station and arrives at the next destination on a reliable schedule (fixed cadence; standard velocity, predictable releases)
  • It delivers its cargo to customers (Release) or is used for internal evaluation and proof of incremental system robustness and quality (PSI/Release).
  • If an Agile Team wants its “cargo” (code, documentation, etc.) to go, it has to put it there on time. The train will not come to them nor wait to get their content.


I’m fortunate enough to work at Redgate – a software house based in Cambridge, UK. At the moment we don’t have a need for the Scaled Agile Framework and all it’s rigourous, and potentially overbearing, process and procedure. I predominantly work with a small software development team (5 to 10 people) focused on a single product, with relatively little need to share work across multiple teams (certainly when compared to a large enterprise-y development programme). This could well change in the future, as we’ll be pushing to synchronise efforts across teams much more regularly. But at the moment, scaling agile is not something on our todo list.

Release Wednesdays

In the last few years, the teams I’ve lead have decided they like to to release their products every week. Every Wednesday, to be precise. Why? Well, I’m a bit torn on how to answer that. The project manager part of me says it’s because we believe in releasing frequently to give our users valuable enhancements as quickly as possible and to get timely feedback on the direction we are taking the product. The developer part of me says its because we get a kick out of putting the stuff we’ve created into the hands of people who’ll enjoy using it as soon and as often as we can.

In any case, by releasing every Wednesday we’ve proved that releasing frequently is best practice, as we extoll the virtues of keeping the delta between releases small and the risk associated with an individual release low. We’ve also found that practice makes (almost) perfect and that the more often we release the easier and less distressing it has become.

We choo-choose the Release Train

Although, I’d used the term ‘Release Train’ with the team for most of the time Release Wednesdays has been a thing, it’s only in the last few months that I have explicitly used the concept to help the team plan, visualise and track their work. I don’t think it’s an exaggeration to say that doing this has been transformational.

The SQL Lighthouse Beta Release Train

The SQL Lighthouse Beta Release Train

The catalyst for a more formal adoption of a Release Train was a realisation that my current project, SQL Lighthouse, had a significant deadline looming that we had no clear plan for how to meet. To be more specific – the team, as a group, realised that for SQL Lighthouse to be a success this year, it was paramount that we had a public beta of the tool ready for a Redgate’s annual London conference.

Once the target was agreed, the team set about deciding what needed to be delivered in order for this to be achieved. We decided on a single, valuable use case we would support with the Beta release and broke the required functionality down into the smallest possible chunks (we used User Stories for this). We then looked to our weekly release cadence to help us decide if this was, in fact, an impossible task.

We wrote up the dates of the 6 weekly releases that would happen before the deadline and placed cards detailing each chunk of functionality under those dates. We were then able to quickly arrange, prioritise, and re-arrange the chunks into a reasonable plan. The entire team gathered around the wall discussing, pontificating and worrying about the plan for the upcoming work – it was the most engaging planning activity I’ve experienced.

Although we’d managed to get each chunk of work down to a small, reasonably independent unit, it was clear that they wouldn’t all take a week or less to complete. We didn’t spend too much time worrying about an exact (or even relative) size, as a group we took a guess at when it could be shipped and moved on. So, if the team believed it would probably take two weeks to complete a particular chunk, it was quickly assigned to the subsequent release. A key point here is that the team realised they were making a informal guess and trusted ‘management’ not to hold them to their hunches.

In the end, we fashioned a release plan made up of 6 weekly, iterative releases. Vital functionality was front-loaded into the early releases and nice-to-haves had settled at the end. As each release was scheduled for a Wednesday, and any functionality that was not ready for that day would have to wait for the following Wednesday – we had an Agile Release Train (see below, cut-out train and carriage wheels were an optional but metaphor anchoring extra).

The SQL Lighthouse Beta Release Train

“Plans are useless, but planning is indispensable”, Dwight D. Eisenhower

Of course, as soon as we’d drawn up the plan it was out of date. If Agile has taught us nothing else, it’s taught us to expect change. So, during the next six weeks we kept the Release Train up-to-date and relevant. It reflected functionality we had shipped, the proposed contents of the next release and any realisations that we just couldn’t get something done for when we’d hoped we would.

Importantly, the whole team took part in analysing the knock-on effects when a piece of functionality (or cargo, to keep with the analogy) missed a release we had earmarked it for. This prompted releases (carriages) to be re-arranged, functionality (cargo) to be juggled and scope-creep (baggage) to be jettisoned. We were all engaged in the process of project planning.

As I detailed in a previous post, the plan and the planning worked – the team met their goal of releasing by the important trade show and in the process transformed the product from a proof-of-concept alpha into a genuinely useful tool. As a direct result of that success, the Release Train was here to stay; we’ve applied the metaphor to every step we’ve taken with SQL Lighthouse since.

The next Release Train: Get 250 users onto the Beta

More than just a release plan

As I reflect on how we do software development on the SQL Lighthouse team now, it’s interesting to note the side-benefits that the Release Train has brought; including small user stories, #NoEstimates, collaborative planning and implicit scope management. This has turned into a long post, so I’ll cover those in my next one – 5 benefits of the Agile Release Train for a single team.

Down with the annual appraisal!

Applying agile to people management

As we near the end of the year, people managers across the world will be aware of the looming, ominous shadow of a well-known nemesis – the annual appraisal process. In a vain attempt to avoid identification, this sinister entity also goes by the name ‘end of year review’. In either case, tackling this foe is a thankless task, requiring managers to succinctly sum-up the performance of their line reports while simultaneously developing, motivating and realigning their people. Worst of all, this has to be delivered via a single formal meeting and/or tightly regulated document. Joy.

At Red Gate (my employer), we don’t do annual appraisals. As far as I’m concerned this is a good thing for two main reasons:

1. Annual appraisals don’t work. Certainly as far as them being an effective method of developing people, recognising good performance and identifying opportunities for improvement. They are destined to fail for many of the same reasons that Waterfall software development projects are destined to fail:

  • They involve up-front requirements specification (a.k.a. annual objectives) which fail to respond to the changes that happen throughout the year and don’t encourage people to take advantage of any unforeseen opportunities that may arise.
  • All parties/functions involved in the process work separately on the same project and pass documentation to each other as a means of communication. This leads to misinterpretation and misalignment.
  • They are Big Bang; involving a single, high-value release (appraisal document) that is often unsatisfactory to both parties and contains unexpected content.

2. Annual appraisals are a massive overhead; they take an age to put together. Everyone involved struggles to remember anything beyond the last few months. Additionally, setting meaningful objectives for the whole year is nigh on impossible and time-consuming.

So, at Red Gate we don’t do Annual appraisals, because they’re clearly broken. Instead, we take a more agile approach.

Agile people management

At least once a month, each employee has a “one-to-one” session with their line manager; just the two of them, catching-up, for 30 minutes to an hour. Each monthly meeting is treated like a mini-review, with the employee leading the discussion on what has gone well and what hasn’t gone well in the last few weeks (amongst other things). At the end of the session the two participants agree short term goals, changes and actions for the next month. They’ll review these at the next monthly meeting.

For the line manager, these meetings tend to require a coaching approach rather than a directive one. In any case, regular one-to-ones are an opportunity to recognise great work and give constructive feedback much closer to the actual event than a yearly appraisal allows. Problems don’t get time to grow and fester. New opportunities can be quickly taken advantage of.

Monthly one-to-one sessions work for many of the reasons agile software development works:

  • They focus on repeated, short time periods that can easily fit in your head and be reasonably planned. These iterations can be chained together to deliver a larger  changes.
  • Everyone involved works together on the task, sharing insights and quickly surfacing disagreements.
  • Work is delivered regularly, progress is clear and information is fed back into the process to improve work over the next time period.

Whilst many software development organisations encourage regular one-on-one sessions between managers and their direct reports, they still keep the annual appraisal process as a method of officially measuring performance and developing people. I’d argue they are missing a trick and should start applying the agile techniques they have honed on software projects to their people management processes too.

In a future post, I’ll write in a bit more detail about exactly how I run one-to-ones with my team.

Hello, SQL Lighthouse: Meaningful deadlines FTW

SQL Lighthouse

Last week, my team released a beta version of the product we have been working on for the last six months – SQL Lighthouse.

This week, everyone on the team has been reminded how motivating it is to see an idea you’ve been working on start to gather recognition and, more importantly for us, users. At the time of writing (October 28th), we’ve seen our ‘active users’ figure (installations of the product that have seen some actual usage) surpass our usage target for the end of November by 160%. The product and the team have a long way to go, but we certainly feel we’ve proved that we are on the right track.

What does SQL Lighthouse do?

We built SQL Lighthouse to allow DBAs and database developers to identify and respond to damaging ‘database drift’. Database drift is where the state of a database has moved away from its expected or desired state over time, and it’s usually a bad thing. SQL Lighthouse will track database schemas, continually looking out for changes. It will then notify users of any change and give them valuable information about it. Users will be able to get to the bottom of any unexpected schema change and start making things right.

For more information, please visit the SQL Lighthouse product pages:

The story of the beta release

The run-up to the release of SQL Lighthouse’s beta version was probably the smoothest, most focussed and least stressful significant release phase I’ve experienced in my 15 years in software development. The primary reason for this was the talented team working on the project – no question. However, I’ve worked with great teams before and ‘big’ releases have seldom been delivered in such a controlled way.

The SQL Lighthouse Beta Release Train

The SQL Lighthouse Beta Release Train

The day after the release I spent a little time considering what I thought the success of the release was down to. I decided that three things had made a significant contribution:

1) Our weekly deployment cadence (which I’ve written about before, in relation to my last project) – meant that we could measure our progress in ‘stuff delivered’ and were never far from a shippable build

2) Our ‘release train plan’ – gave us a clear, visible illustration of what we had to deliver each week to meet our goal (image above and a subject I explored further in this post)

3) The team’s belief in the meaningful deadline we had set for ourselves – meant the entire team engaged in scope management and release planning on a daily basis

I find the third point particularly interesting because I’ve generally tried to shield my teams from project deadlines by which they MUST finish their work. The pressure of a deadline can make teams do inexplicable things – like cut corners with quality, ignore risks, work into the night and discard their principles. Plus, deadlines lead to estimates, and estimates are of the Dark Side.

However, today I sat in a retrospective meeting with my team as we considered what we learnt during the beta development phase. We spent time considering what aspects of the way we worked during that period should be kept and what should be jettisoned. Interestingly, the clear consensus in the room was that the three initiatives I called out above should stay. Yes, the team literally asked for deadlines.

Was this turkeys voting for Christmas? I don’t think so think.

The difference between the deadlines the team want, and the deadlines often handed down from ‘senior management’ at employers more domineering than our own, is that they should be meaningful and real. That is, meeting a deadline must clearly be tied to the success of the group and their endeavour. That way the deadline can be adopted by the group, rather than applied from outside the group in an oblique attempt in increase productivity.

You see, six weeks before the eventual beta release date, the team had set themselves the challenging target of releasing a public beta in time for Red Gate’s annual conference in London – SQL in the City. Why? We did this because, as a group we realised that for SQL Lighthouse to be a success this year, it was paramount that we had a public beta of the tool ready for hundreds of Red Gate users to see on the display booths and then go back to their office to download and try for themselves.

Furthermore, for the release to be compelling we needed to add three major features (audit, email alerts and set-up validation) and overhaul the look and feel of the entire application.  We discussed the relative priority of these changes, scheduled them to the cadence of our weekly releases, accepted the plan was achievable but tight and went for it. But above all, we all believed that meeting this deadline was vital to our success.

Stay on target

To their great credit, the team met the goal of releasing by SQL in the City and transformed the product from a proof-of-concept alpha into a genuinely useful tool. Before you ask: they didn’t work crazy hours, they didn’t hack code in and they didn’t abandon their principles. They continued to ship a release every week during this period, which helped garner feedback from our alpha users on the new features, gradually improve performance and iron-out issues.

If you want to know more about SQL Lighthouse’s journey from product idea to beta release, read Alex Yates’ (SQL Lighthouse team member and technical sales guy) excellent post The Story Behind SQL Lighthouse.

Retrospective Activity: By The Numbers


I thought I’d share a sprint retrospective activity I came up with recently. As I outlined in a previous post, I like to structure the retrospectives I facilitate in the form popularised by Esther Derby and Diana Larsen in their book Agile Retrospectives. That structure has five sections, each with a specific goal:

  • Set the stage – Goal: Set the tone and direction for the retrospective
  • Gather data – Goal: Create a shared memory; highlight pertinent information and events
  • Generate insights – Goal: Think creatively; look for patterns, themes and connections
  • Decide what to do – Goal: Generate and prioritize valuable, clear actions
  • Close – Goal: Summarize and end the meeting

This activity – “By the numbers” – is an activity for the Gather Data stage.

Retro in progress

Retrospective Activity: By The Numbers


This activity is useful for the Gather Data phase of a retrospective, as it encourages team members to focus on cold facts rather than evaluations or opinions (which are for the Generate Insights stage). Like any good retrospective activity, it leaves room for people to influence the path of the meeting by highlighting events and facts that have significance for them.

Time needed

This is a fairly quick activity that you can tailor to be fifteen to thirty minutes long.


The team generate a list of the facts and figures that describe the current state of the project.


1.  Introduce the activity by saying “the aim of this activity is to create an overall picture of the current state of the project objectively, without evaluations or opinions. We’ll do this by calling-out numbers that illustrate where we are. For instance, we currently have X green tests and there are Y developers in the team.”

2.  Give each person a sheet of paper and a pen. Tell them they have three to five minutes (decide which!) to create a list of the numbers they think are significant for the project. Ask them not to look at each other’s paper and tell them that the numbers can be approximate if they can’t remember them precisely.

If the team are struggling to write much down, try a couple of the following prompts:

  • “Think about what has happened to you over the last sprint. What numbers are involved with those events?”
  • “What are this project’s vital statistics?”
  • “How would you describe the project to someone else only using figures?”
  • “What are the ideal numbers for aspects of the project? Now, what are the actual numbers?”

It’s likely team members will choose figures that help them illustrate an issue or achievement that’s on their mind – like “100 ignored unit tests” or “zero open support tickets”. This is great and will provide good food for thought in the next stage of the retrospective.

3.  When the group have finished making their lists, it is time to share. Ask for a volunteer to start the process by calling out one of their significant numbers. They should not divulge what the number pertains to. Write the number on a whiteboard so the team can all see it.

Ask the rest of the group to call-out and guess what the number relates to. The interaction might go something like this:

  • Volunteer: “37”
  • Team member #1: “Is it – the number of users who had a support query this month?”
  • Volunteer: “Nope”
  • Team member #2: “Is it – the number of days since we went to the pub as a team?”
  • Volunteer: “Nope”
  • Etc, Etc..

When someone guesses correctly or the process has taken longer than a minute or so, write what the number was related to up on the whiteboard.

4.  Go around the group in a round-robin fashion, asking people to share one of their significant numbers and the group guessing what they pertain to, until you have filled the whiteboard or the timebox you set for the activity.

5.  Debrief the activity by asking:

  • Are there any patterns in what is significant to us?
  • Are there any surprises there?
  • What numbers would you like to change and what would you change them to?


If the team is stumped when it comes to generating the numbers or are very worried about precision (e.g. “I don’t know how many unit tests we have, off the top of my head”), invite them to go back to the team area in the office to gather data. Make sure you get agreement on a definite time for them to be back in the meeting.

You can also make the activity a group game by breaking the team into two subgroups to come up with the numbers. Then you can make the activity competitive by scoring teams on how many of the opposing team’s numbers they can guess.

To decrease the time needed for the activity, remove the guessing part of the sharing phase – this would be less fun but would gather the same information.

What happened when we tried it?

I’ve run this activity couple of times, most recently today, and it’s worked well. Whenever I’ve used it some team members have taken a little time to warm to the activity, so I’ve needed to reiterate the instructions and encourage them to give it a shot.

Giving examples of the kind of thing you are looking for always helps. Today I gave the following examples, which seemed to unlock the group:

  • 347 people on the our beta mailing list
  • 24 technical debt items on out debt board

After a couple of attempts to guess what other people’s numbers are about, there’s usually good energy in the room. Suggestions can be frivolous and funny or serious and insightful – which is great. By the end, we got a pretty good idea of what people feel is important about the project at the moment.

If you are interested, here’s an image of the whiteboard after we’d done the activity today:

By the numbers

If you give “By the numbers” a go, let me know whether it worked well for you or not!

Agile 2014 attendees, what are you going to do?

If you attended the outstanding Agile 2014 conference in Orlando over the last week, and you are even remotely like me, then you’ll have returned home with a mind bursting with new ideas and techniques gleaned from your time away.

You may well have drawn great inspiration from your time in that hermetically-sealed agilist bubble (a bubble both figuratively and literally, thanks to our gargantuan resort location). Given it’s still the weekend, you’re probably impatient to start delivering on that inspiration and applying what you have learnt.

Copyright Doc List Photography

While I was at the conference I kept a list of the new stuff I’d come across that I wanted to ‘do’, ‘try’, ‘research’ and ‘think about’ when I got back to my real life. Unsurprisingly, it’s a long list. It’s length is a reminder of how worthwhile and thought-proving the event was, but it’s also kind of intimidating. As I look down the list I find myself looking forward to each task and simultaneously wondering how on earth I am going to make the time to do them. Frankly, I’m concerned I won’t get as much value out of my trip as I could. Maybe even as I should.

I suspect I’m not alone; opportunities will be missed to enact lessons and follow-through with ideas across the cohort of Agile 2014 attendees. Even with the best intentions, our busy work routines and packed domestic calendars will spirit away our time, substantially limiting the value we reap from our week in Orlando.

If someone I was coaching said the above to me, my first question to them would be pretty straightforward:

“Given all that, what are you going to do?”

To answer to my own question… Well, I want to make sure I do the most valuable stuff on my list. However, I am going to take my lead from a lady (never caught her name) who stopped me during one of the breaks in the conference to thank me for the retrospective workshop I’d run with Mike Upton (which, as an aside, I really appreciated as she reminded me why I put myself through the stress of running the session in the first place). She said it had taught her that she should vary the activities in her retrospectives, rather than repeatedly running the same one. She said she was going to fix that.

I’m going to follow her lead because, although our session was full of hints and tips, she’d boiled it down to that single action point – she was going to vary her retrospectives in the future. One clear action that, having talked to her briefly, I felt sure she was going to do.

When in ‘coaching mode’, I’ve sometimes asked people who are facing a long list of things they want to get done “Which three things will you feel most disappointed about if you look back in a month and you haven’t done anything?”. I realise that’s needlessly negative, so let’s rephrase:

“When you look back in a month’s time, what three things will you have done since Agile 2014 that have made it an awesome month?”

Here’s my answer:

  1. I’ll have run a Facilitation Patterns and Anti-patterns session (using Doc List’s cards) with my team/coaching colleagues
  2. I’ll have sorted out my project’s backlog and planning projections (based on many #NoEstimates discussions at Agile 2014)
  3. I’ll have started a monthly Lean Coffee at Red Gate (my employer)

Hopefully, I’ll be able to tick more things off my list as well, but I’ll make sure the three tasks above are done before I worry about the rest, because if I do those three it will have been an awesome month.

If you haven’t made a list of stuff during the conference, maybe now is a good time to do that – before memory atrophy kicks-in. If you attended with a number of local colleagues, get together and have a retrospective. That way you can see if any of the things you want to do overlap – and agree to share the effort. In addition, calling out what you are going to do in front of others can be quite motivational (especially, if you plan a follow-up discussion in a few weeks’ time).