Agile Board design – the theory and practice of swimlanes

In previous articles I have discussed the theory and the practice of choosing vertical columns for an Agile Board to represent the workflow steps that tickets pass through as they move across the board from left-to-right. But a board is a two-dimensional grid, and we now turn to the other, vertical plane. For some reason, rather than the conventional terminology of columns and rows, the jargon in Agile Board World is to talk of columns and swimlanes, so that is our topic here.


Previous articles have argued that using the vertical plane to show priority is a better method than using priority flags, and that one-ticket-wide columns on an Agile Board implement this beneficial principle. You can move a ticket up to show an increase in priority, but other other tickets have to move down to make room – your board is both showing and enforcing a trade-off decision:


This example shows tickets moving within a single swimlane. But what if you have multiple swimlanes, stacked vertically one on top of the other? In this case you must stick by the rule that vertical position is always and only used to show priority, and that means we must set up our boards such that higher swimlanes have a greater priority than lower ones. This restricts the meaning we can give to swimlanes on a board.

Let’s consider the hypothetical board below, which has 14 tickets on it, distributed across three swimlanes. I have used the triangulation method to show the order of tickets. Whatever meanings we give to the red, yellow and green swimlanes, it must be the case that ticket 4 is more important than ticket 5, and ticket 11 is more important than 12.


Very often you will find Agile Boards are set up with swimlanes corresponding to functional areas, and this may conflict with the principle that vertical position shows priority. If it does conflict, you should not use your swimlanes to show functional areas (there are other means of filtering down to the functional level, which I will cover in a future article).

I recently spent some time in a team building an enterprise level identity system, and three of our functional areas were 1) registration, 2) sign-out and 3) user uplift. As it turns out, there was not a clean and strict mapping of priorities onto these functional areas; some registration work was relatively important, and some was not, and the same applied to the other two functional areas. We therefore did not set up a swimlane for each functional area, as the board would have been falsely indicating the priority of some tickets.

So what should you map your swimlanes to, so that you don’t break the vertical position shows priority principle? There are no doubt many possible answers, but I will consider two swimlane patterns below that between them cover a large percentage of cases.

First let’s consider a team that is in control of its own delivery cadence, and either is already doing, or aspires to move in the direction of, Continuous Delivery; in other words, they release work to Live in frequent small batches. What swimlanes might be chosen by such a team?

This team’s board needs to cope with both normal, planned work, and the all-too-common situation that something super-urgent crops up, requiring normal planned work be dropped immediately until the crisis is over. Such emergency situations are typically due to the discovery of a nasty bug in Production.

Since Emergencies are the highest of all possible priorities, they go in the highest lane up the board, with ‘normal work’ sitting below it, as here:


How do these swimlanes get used in practice? We of course want visual representation of work and preferred team behaviour to dovetail neatly and reinforce each other, and this swimlane layout can certainly do so.

Team rules around emergencies are usually something like: 1) verify any claim that new work really deserves ‘emergency’ status, 2) if it does, everybody who can help with the emergency does so immediately and only returns to other tasks when they can do no more on the emergency work.

A top-of-the-board Emergency Lane is admirably suited to this. Any ticket in that lane is above the fold on a computer screen, and is the very first thing any user’s eyes fall on. A new ticket arriving in this lane cannot be missed, and is a clear signal for the appropriate group of people to verify if the ticket is a genuine emergency or not, in which case they move the ticket out of the top lane. For tickets that stay in the Emergency Lane, that is again a strong visual signal that work exists that needs full and immediate attention, with team members resuming other work lower down the board only when the emergency allows.

The disruption caused by emergency tickets is considerable, even worse than normal context switching, since a) there is usually no option to get the prior work to a nice, neat point before dropping it, and b) working on an emergency often leaves you in a frazzled mental and emotional state, not easy to switch back out of. This makes it critically important to ensure the Emergency Lane is treated with proper respect, ie for genuine emergencies only. Such disruption is only merited in extreme cases.

There can be a temptation for people to try to slip tickets into the Emergency Lane just to get stuff done faster, and the team need to be on their guard against any freeloading on this crisis-management process. The very term “Emergency Lane” is helpful; less impactful alternative names such as “Expedite” don’t provoke such an emotional response. Saying you want to “expedite” a ticket is really quite different from looking a colleague in the eye and declaring that your work is a genuine emergency!

This two lane pattern of Emergency Lane and Normal Prio Lane works, without much modification, for the majority of modern software development teams. It also applies to most teams outside the world of software – I have successfully run a marketing and a finance team using this pattern of Agile Board, for example.

However I use a different board pattern in situations where releasing continually is impossible, meaning you cannot avoid having less frequent, big-batch releases, which can be seen queueing one after the other a considerable time in advance. A canonical example would be an iOS team, where the release process has a major bottleneck that cannot be overcome; namely, the submission and approval process of the App Store, which takes around a week, during which time you can make no further changes to the submitted binary without the clock starting again.

Typically iOS teams respond to this constraint by aiming for one or two releases to the App Store a month, and it would be quite normal to have company personnel actively working across perhaps the next three iOS releases. This would be reflected in the structure of swimlanes on the iOS team Agile Board:

Swimlane example - iOS.png

This hypothetical team has version 1.2.1 already out in the App Store, and the main focus of team is currently on the next release, v1.3. As the end of this release approaches, team members who are freed up will gradually shift on to the following release, v1.4. Naturally this is of lower priority (as reflected by the lower position of its swimlane), and if anything comes up in v1.3 people will switch back to that. The position of the swimlanes helps team members make the right decisions – it’s more important to get the v1.3 binary completely finished and into the App Store queue this week than to work on some functionality in v1.4 that isn’t shipping till next month.

And this pattern repeats. Perhaps the planned release after v1.4 is a major new version, v2.0. Some people (perhaps Product, Architects, Designers…) are already starting to put some preliminary work into that one, and that can be neatly shown on the board. But if they were needed to work on v1.3 or v1.4, you would generally expect them to interrupt work on v2.0 to do so, and the board shows that visually – those lanes are higher up, so that work is higher priority. You can use the triangulation method and trust what it tells you.

In summary, these are two practical swimlane patterns that together cover the needs of many teams;  one for small-batch release setups where the version number of your tech product changes frequently, and it is hard to predict ahead of time exactly which version a given piece of work will end up in. The other is for large-batch release setups, where these things are much more likely to be known up front. In both cases the swimlanes respect the rule of using vertical position to show priority, and all the advantages of being able to easily read the board by triangulation are retained.

It is of course always possible that any given team may empirically discover alternative swimlane arrangements that work for them, but to abandon the use of the the vertical plane to show priority is usually a retrograde step, and should be avoided, as with the examples given here.

How to read an Agile Board

In previous articles we have discussed what an Agile Board might look like for a typical software development team, but this will bring no rewards unless we know how to use it properly, for example in a properly conducted stand-up meeting.

A major function – arguably, the prime function – of an Agile Board is to make team priorities absolutely clear, so that all team members can be sure that they are working on What The Team Needs Most. For this to happen, everybody needs to be reading the board in the same consistent way, and that way must be simple, or people will get it wrong.

This article will explain what that simple method is.

Let’s start with some examples. Below is a simplified cut of an Agile Board, with just two tickets showing. Let’s say you are a team member reading this board, and as it happens your skill set and the state of those tickets means you are able to assist on either one of them. Question: which one should you pick to work on first, X or Y?


The correct answer is pick X before Y, because in a properly functioning Agile Board, the vertical plane is reserved to show priority. Higher up means higher priority, and X is higher up, so you work on X first, as below:


There is little controversy here; I have asked this question to real people hundreds of times, and everyone basically gets this right first time.

Now let’s try the same exercise for a different cut of the board. Again, you are a team member reading this board, and you are able to assist on both the tickets that are showing. Which one should you pick first, X or Z?


There is an equally clear answer here, which the great majority of people also get right first time. The answer is to pick Z before X, because Z is further to the right, ie it is closer to being Done, and ‘Done’ is what counts, the thing that delivers value to the organisation. Sadly in life it usually is very easy to start things, but it can be hard to finish them off, so an effective team concentrates on getting stuff finished before new stuff is started, and this desirable behaviour is promoted by reading the board in this way.

ticket-choice-horizontal-plus-answerThe third and final quiz question is a combination of the two above. Again, other things being equal, in which order should someone pick up the following three tickets?


The answer is pick Z before X, and X before Y. This is a simple combination of the two rules above, which leads to reading the board in a kind of triangulation method, from top-right (where you’ll find the most important tickets on a board) to bottom left (where you find the least important):


Now let’s apply this triangulation method to a more realistic board setup. This is exactly what a team is trying to do in every Stand-up meeting, so that it can discuss the tickets in priority order. Applying the triangulation method to this board we can easily label the tickets on it from 1 (the most important) down to the 17, the very least. The ‘Done’ tickets are ignored in this exercise – by definition, if they are Done, there is no work left to do on them.


And how do you apply this rule to a board which has Swimlanes? Since the correct use of Swimlanes (discussed in detail here) maintains the principle of using the vertical plane for priority (i.e. higher up Swimlanes are higher priority than lower swimlanes), it is still easy to apply the triangulation rule and again number every ticket on the board from most important (1) to least (17):


Sometimes, when applying the triangulation method, a team member will voice an objection: what the board is saying is not correct! And indeed in a well-functioning team there is a bi-directional effort going on at all times:

  1. work in the order the board tells you to work
  2. make sure the board is always telling the truth about the order to work on

Any team member must be empowered to challenge the signals the board gives out if there is any doubt. Far better to do so than to slavishly follow what the board says even if it is potentially wrong, or to do what you believe is correct without reflecting that choice on the board, leaving your teammates in the dark as to what you’re doing and why.

So a comment such as the following is an entirely legitimate statement to hear in a good team: “the board is telling me to pick up ticket 512, but surely I should be doing ticket 197 instead, for reasons a,b,c,d… “. If, on examination, reasons a, b, c and d stand up, then as far as possible the board should be amended to reflect the Real Truth, and that team member has done everyone a service. It is everyone’s duty to Make The Board Tell The Truth!

With the whole team taking collective ownership of their Agile Board, ensuring that The Board Always Tells The Truth, that team can jointly and individually use the triangulation rule to work out what to do next, and everyone ends up working on What The Team Needs Most. And the end result of that is a team that is continually aligned and with every chance of delivering effectively, with all the increased motivation to individuals and value to the organisation that such a result entails.

Why priority flags don’t work, and what to use instead

The ability to show the priority of a given piece of work is pretty important, I think all would agree. But what is the best way of recording and showing this information? Unfortunately the most common method, using a priority flag, is far from the best.

Most users of work-managing software will encounter plenty of priority flags, usually set by some kind of dropdown control. There’s no consistency between systems in terms of the vocabulary or number of choices that are offered; sometimes the choices are mere numbers, sometimes words, sometimes a mix. And even within a specific set of users of a single system it is rare to have universal agreement on what a ‘2’ or a ‘Minor’ actually means, or when each should be applied. One man’s Blocker is another man’s P4, it often turns out.


And this vagueness often (always?) leads to a dangerous phenomenon – ‘priority inflation’, analogous to grade inflation, where far too many tickets end up in the the very top priority buckets, rendering your prioritisation system useless.

This phenomenon is easily explained by simple psychology. When you are entering work into a system, it’s usually because you want it to be done. Let’s say you have 5 different priority levels to choose from; you know that a prio 5 ain’t gonna get done before the Heat Death of the Universe, and probably a prio 4 is in the same boat. So really you’re now choosing between prios 1, 2 and 3. But you know that everybody else thinks that way too, so it’s probably safest to make your task at least a 2 just to be safe. Or if there’s the slightest bit of genuine pressure for that piece of work, in which case the temptation to put a 1 is almost overwhelming.

After all, there’s rarely anything in a priority flag system that limits the number of allowed P1s, such as a “one in, one out” rule. So why not chuck it in the top buckets, as everyone else is doing?

Priority buckets.png

And so priority flags lead to priority inflation. In the worst case virtually everything ends up as a P1 – or perhaps there are so many P1s that it’s utterly unclear what really needs to be done first. So the whole system has collapsed.

What is the alternative? It’s simple; instead of a priority flag, you maintain a priority-ordered list of work, with the most important thing at the top. When a new item comes in (or an existing item is reordered), other items have to move to make room for it. In other words, you have to make a trade-off decision – “sure, this thing can go up …but something else has to go down”.


Trade-off decisions are hard. But prioritisation in a world of limited resource is genuinely difficult, and it’s better to face up to reality than to hide from it. Any worthwhile system for representing priority should force decision-makers to confront trade-offs, rather than allowing a pseudo-decision. In priority-ordered lists, there is no such thing as ‘two items that have the same priority’, so the trade-off decision has to be made. In a priority flag system, by contrast, you can have half your total backlog categorised as a P1, and nothing tells you that you have a big problem – until the customer finds that their deadline has passed and their P1 work never got done.

In the world of software development teams, you do often find priority-ordered lists. They exist at the strategic level, ie the product backlog and/or strategic roadmap. They also exist at the tactical level, the Agile Board, as long as each column on the board is only one-ticket wide. In such a setup, a ticket’s increasing priority is shown by moving it up (the yellow ticket), but the board demands that the necessary trade-off decision is faced up to, and displayed for the world to see – the red and green tickets have to go down.


So one of the advantages of representing your work on an Agile Board with one-ticket-wide columns is that you can show priority the good way – every column is a priority-ordered list. This will turn out, as we will see in a future article, to be a key ingredient in reading the entire board correctly, when we don’t just have to worry about one column on its own, but need to be able to prioritise columns of tickets against each another.

Agile board design example – columns part 2 (delivery)

agile-board-complete-workflowIn a previous article we outlined the steps for a hypothetical, generic software development team to get work from its starting state of ‘Idea’ to the key intermediate state, ‘Ready for Dev’ (R4D):

getting tickets ready delivering
Idea Triaging Ticket Prep Hand-shaking R4D bla… Done

This article will examine what steps might follow, all the way to the nirvana that is ‘Done’, which means that code is tested and working in production, in use by real customers of the business, and hopefully generating some value for the organisation.

The next step after R4D is, uncontroversially, ‘In Dev’. Is this just ‘writing the code’? In fact it is that, and more. For this step, as for all steps in the workflow, the team needs to explicitly agree, and then adhere to, their own criteria for what it means to have successfully completed the step. Typically for ‘In Dev’ this includes meeting team rules around coding standards, writing appropriate unit and integration tests, version control usage and so on.

Whatever specifics the team decides on this, the point at which a ticket goes into the ‘In Dev’ state is a critical point in its lifecycle. As a general rule, much more work, and work that is much more difficult and costly to undo, happens during and after this stage than what went before. This matters greatly when, as is inevitable, the prospect arises that the specifications or the priority of a given piece of work should perhaps be amended.

These decisions should be made on the basis of a cost-benefit analysis, and it is precisely at ‘In Dev’ that the cost element rises considerably, raising the bar on giving the go-ahead to such changes. This means that putting a ticket into ‘In Dev’ should never be done frivolously, as it represents a step-change in the team’s commitment of effort. Promoting the right kind of discipline around this is one of the key functions of the pre-R4D states on the board.

getting ready ready delivering
Idea bla… R4D In Dev ? ? ? ? ? Done

What happens after ‘In Dev’? Coding is so important and difficult to get right that it is usually worth rigorously double-checking, and we call that out in our workflow under a separate step, here named ‘Code Review’. How that reviewing happens is again for the team to decide. Sometimes just a quick look from one other person is sufficient, but at other times you might need multiple people to check multiple times before work passes muster. Tools such as Github’s Pull Request review system are often used to make this intra-dev communication easier, and a single PR can end up with dozens of comments from multiple people. It’s usually best practice to summarise the results of that conversation in a more widely-available place, where those unable or unwilling to use Github can see the outcome; the obvious place is the tool used to generate the Agile Board, such as Jira.

Some teams consider that the practice of pair-programming – where two programmers collaborate closely at the same screen/keyboard to write code together – counts as ‘Code Reviewing As You Go’, and therefore any code that results from pairing needs no further checking stage. But it’s a rare team that applies this practice to absolutely every piece of work (I’ve only known one to do so in nearly 20 years in software development), and so it’s a rare team that cannot benefit from a separate ‘Code Review’ step on their Agile Board.

getting ready ready delivering
Idea bla… R4D In Dev Code Review ? ? ? ? Done

When a ticket has passed Code Review, that means the Dev sub-team considers the ticket ‘code complete’; in other words, that their work is done. Sadly this is often ludicrously far from the truth, and people can be delusional about how much work still remains to be done, with multiple steps of getting code merged, tested, approved and deployed. This cartoon puts it well:



In our hypothetical team, after Code Review it is the turn of the QA (Quality Assurance) aka Testing sub-team to do their stuff. Given that the QA team is often overstretched, and is hardly ever able to pick up every ticket the very moment it passes Code Review, we need a buffer state next called ‘Ready for QA’, the inbox for the QA team.

getting ready ready delivering
Idea bla… R4D In Dev Code Review Ready for QA ? ? ? Done

The QA sub-team picks from this ‘Ready for QA’ column, in priority order of course. QA work is often a mix of coding high-level acceptance tests, and manual testing. How much of each depends on what is being tested (front-end and mobile apps need more manual testing than pure server-side code with no UI), the skills of the testing team, and the technical maturity of the team overall.

For this example workflow we will include all of this under a single step, ‘In QA’, though this step can be broken out into separate sub-steps for Automated and Manual QA if required. If a team aspires to a BDD model, some or even all of the Automated Tests might have been written in parallel with, or even before, production code was written at the ‘In Dev’ stage. In my experience few teams manage anything like this BDD ideal in practice, but if a team does this or is determined to try, they would amend their workflow model accordingly, perhaps by having a step for ‘Automated Tests’ after R4D, before ‘In Dev’. But I will stick with a simpler workflow for now in this example, this single step called ‘In QA’.

getting ready ready delivering
Idea bla… R4D In Dev Code Review Ready for QA In QA ? ? Done

What does it mean to finish this step? As ever, each team must develop and follow its own rules, but a common approach is that finishing this step means: code has been validated against its specification by the QA sub-team, that relevant bugs have been raised (as separate-but-linked tickets and/or as part of the ticket being tested), that bugs above some agreed impact threshold have been recoded, retested and are now passing, and that the ticket as whole is therefore considered deployable to the Live environment by both of the technical sub-teams, QA and Dev.

At this point a quick discussion of environments is in order. In these articles I am keeping discussion of technical considerations to a minimum, as they are complex and polemical in their own right. Nevertheless it is pretty much universal that business value is only provided when code is accessible to real users in a Live (or ‘Production’) environment, and that all the pre-steps we have been discussing happen in various lower environments. Quite which environments and what names they go under varies widely, although it is (unsurprisingly) a common pattern that QA steps happen on an environment called ‘Test’, where code from multiple different developers has been merged. The very purpose of both the QA steps and the Test environment is to give us sufficient confidence to deploy the new code to Live without panicking that our users’ world will collapse as a consequence. The dire consequences of not having separate Test and Live environments is the subject of dark humour in the industry:

So, post-QA, are we ready to deploy to Live? In some teams, yes. In others, the Product function prefers a formal Sign-off stage. If everything prior to Sign-off has been performed correctly, this should be a formality, and (like any step) if it is found to generate little value then the team should consider a process simplification, removing that step both from what they do and how they model it on an Agile Board. But sometimes a Sign-off step is required, and it is not prima facie unreasonable for the person who requested the work (ideally that very individual, often a BA or Product Owner) to confirm whether they’ve got what they asked for, neatly completing a request-response loop and avoiding much potential embarrassment from the wrong thing going Live.

getting ready ready delivering
Idea bla… R4D In Dev Code Review Ready for QA In QA Sign-off ? Done

Note that calling out a formal Sign-off step does not have to mean a team is going down a stratified, siloed, somewhat Waterfall way of working. As we have stated in previous articles, a board is necessarily a simplified model of a workflow. One of the most obvious simplifications is that it represents steps in a single, linear flow, with a particular team sub-function usually having the major responsibility for each step. But in well-functioning, well-integrated teams, the reality may be far more fluid; pairs or small groups from different sub-functions can and often should work together at multiple stages of the flow. It is a sign of good teamwork when you hear comments such as “that ticket can go straight to Sign-off from Code Review – Dev X and QA Y have been pairing on it the whole time, so it has already been tested”, or a Product person says “that one can count as signed-off already; I went through it all at QA Z’s desk yesterday when she was testing the last part”. I will never complain when, without cheating, a ticket shoots through some stages of its life on its journey to Done.

Now, after Sign-off, the ticket is indeed Ready for Live. I have known server teams with completely automated continuous deployment pipelines where this step (and several others) are unnecessary; it is an automated script on a CI server that auto-deploys any code whose tests turn a dashboard green on a lower environment, so there’s no human intervention required, insufficient time for them to do so even if they wanted, and therefore no point representing such steps on an Agile Board. But equally there are many teams where the work and process required for a Live deployment is sufficient, and sufficiently separate, to justify a ‘Ready for Live’ column on the board. One we’ve added that, we have a complete workflow from ‘Idea’ to ‘Done’, and the resulting Agile Board looks like this:


Calling something ‘Done’ means there is nothing more for this team to do. Some teams (perhaps with a sub-optimal tech pipeline) in fact do need to do further explicit checks in the Live environment itself, and in this case they may need to add further columns to represent that work, but in this hypothetical team we will take ‘deploying to Live’ as the last thing that this team needs to do.

In fact from the organisational perspective it is rarely true that no more work at all applies to what you have just deployed. Someone should be checking on the take-up amongst real users of that lovely new feature you spent two months building – if it is widely used, perhaps it should be enhanced. If it’s not used at all, perhaps it should be redesigned or removed. This is the Lean Startup Build-Measure-Learn loop, where all of these workflow steps are just the ‘Build’ part.


But the timescales over which the Measure and Learn steps happen are often large, and usually involve relatively few people from the software development team itself, and so while that monitoring and thinking could (and probably should) be modelled on some Agile Board, it is usually not put onto the development team’s board – at least until the loop has completed and new work arrives in the guise of new tickets ideas all the way over on the left of the dev team’s board, and the cycle begins again:build-measure-learn-board-setup

So now our hypothetical dev team has a complete board, the next step is to make sure we use the board in the right way. And that means we need to know how to read it properly, which is the subject of the next article.

Agile board design example – columns part 1 (getting stuff ready)

An Agile Board is a model of a team’s workflow, the series of steps its work goes through from conception to completion. The first thing you have to get right (or rightish; boards will evolve over time) is the columns you use to represent those steps. In a previous article I discussed the background to such decisions, and in this one I will run through a hypothetical example.

One way to conceptualise a software development team is as a machine for converting ideas into fully tested working code in production that benefits real users of the system. That is, the input to this machine is ‘an Idea’ (=the very first step), and the ultimate output is ‘provably working code in production’ (=‘Done’, the very last step). Thus we have bounded the beginning and end of our workflow – now we just need to work out the stuff in the middle.

Idea ? ? ? ? ? ? Done

Somewhere in the middle of this sits a critical state called ‘Ready for Dev’ (or R4D for short). This means that a ticket is fit for coding to begin on it, and it might take a lot of work to get an idea to that point. It neatly divides our total workflow into two; steps prior to R4D are about getting tickets ready, and the steps after that are about delivering that work. For reasons of length, this article will be about that first half, and a separate article will cover the delivery steps.

getting tickets ready delivering
Idea ? ? ? R4D bla bla bla Done

So let’s flesh out the steps between ‘Idea’ and ‘R4D’. What happens after you’ve had an idea? Typically there are vastly more ideas (=potential work) than there is capacity to implement them, which means that the next step after ‘having an idea’ is to pool that idea with all the other candidate ideas and do a ruthless selection of the worthier ones. The less worthy either get filed as ‘maybe do later’ or are thrown away. We need to represent this in our workflow with one or more steps that represent grouping / de-duping / trashing / prioritising the candidate ideas, a sequence that will be familiar to anyone who has organised a brainstorming session.

An Agile Board is a simplified model of reality, and it is possible to represent all these idea-processing activities that lead up to a prioritisation decision in just a single step on the Agile Board. This step might be called ‘Prioritisation’, but I usually call it ‘Triaging’, after the parallel process that happens in medical emergency units. The intricacies of Triaging will be covered in more detail here; for now it is sufficient to note the following:

  • Triaging is synonymous with quick prioritisation
  • you can only prioritise after you’ve done a minimum of grouping and de-duping (if a new ticket is a duplicate of an existing one, you just throw it away)
  • the implementation of a ‘quick prioritisation’ decision in a tech team is to have slotted the new ticket into (roughly) its correct place in the ordered backlog of work for the team. When you’ve done that, you’ve finished Triaging.

The amount of information needed to triage varies massively from from case-to-case; sometimes a single bullet point might be enough, at other times considerable business and/or technical analysis might be required to make even basic judgements about the worthiness of an idea, and you have to put off Triaging until that information has been supplied. But whatever that minimum fleshing out is, in an optimally efficient workflow, that’s all you will have done at this stage.

That is because the result of a triage decision might be to do the work much later (potentially changing the spec considerably), or even not to do it at all, so any work invested up to the triage decision is potentially pure waste, and must therefore be kept to the minimum; limited resources should be focused on work which will definitely not be wasted.

getting tickets ready delivering
Idea Triaging ? ? R4D bla… Done

The timing of the next step depends on how high or low a ticket has been triaged. If fairly high up the backlog, the next step may follow immediately. If low down, it may take a while, or even never happen at all. What is that next step, then? Since triaging often (correctly) happens on the basis of relatively little detail, now we have to flesh out the work in enough detail for efficient delivery. I often call this step ‘Ticket Prep’, and if teams have a role of Business Analyst, this step typically consumes a lot of their time.

How much detail is ‘enough’? Well, it might be adding a second bullet point. Or it might be large amounts of work involving a ton of people. It’s completely contextual, and depends on the team, the work itself, and the project / programme / organisation of which it is part. You can get ‘Ticket Prep’ wrong by adding too much or too little detail. Too much detail, the Waterfall Fault, can be a waste of effort – the future is uncertain and some stuff needs to be figured out in real time as it’s being built. But too little detail, the Agile=chaos fault, can also lead to waste – leaving the downstream people to frantically guess as to what’s the work is really about right in the midst of trying to deliver the bloody thing.

‘Ticket Prep’ is a kind of planning, and the idea that here is a sweet spot of how much of it to do up front applies to all kinds of planning. Mike Cohn popularised a graphical representation of this, the planning curve of diminishing returns. The sweet spot gives you decent reward for a reasonable amount of upfront effort.


Every team must find that sweet spot for themselves by an empirical process of trial and error. There are some tickets in some teams that must be specified up-front in pixel-perfect detail. There are other tickets in other teams at other times where to do so is madness, and the decision is multi-factorial. The easier it is to change the work later, the less crucial it is to specify every detail up front. How the team works together is also relevant; in strict BDD there needs to be a failing acceptance test before production code starts, and that requires quite strict definitions. The more developer-UXer pairs work together at the same screen during delivery, the less you need to specify up front. And so on.

Sometimes this single step called ‘Ticket Prep’ wraps a multi-faceted set of tasks that requires much expertise and many people. Sub-teams such as UX and Architecture may be extensively involved, and the assets they generate (eg architecture diagrams, wireframes, mockups etc) may be considered prerequisites a ticket to be R4D. These assets typically go through their own sub-processes of creation, reviewing and sign-off, and ‘Ticket Prep’ is sometimes broken down into sub-steps to take make this more visible on the Agile Board. But for this example, let’s keep all that under just the one step.

getting tickets ready delivering
Idea Triaging Ticket Prep ? R4D bla… Done

So surely, at the end of ‘Ticket Prep’, a ticket is ‘Ready for Dev’, right?

Well, maybe. You’d certainly hope so. Maybe the BA (or whoever) who wrote the ticket thinks it is. But getting this right is too important to gamble on; a team needs to check that a ticket really is R4D before it is declared such, otherwise you are potentially seriously messing up the delivery phase, and the lives of all your colleagues who will work on the ticket downstream. Every Dev and QA I’ve met has horror stories of the chaos (and probably late nights in the office) that ensued when they were obliged to start work prematurely on poorly-specified tickets.

So to avoid this waste, and to treat our colleagues with some respect, all tickets must be checked with these downstream people (typically Devs and QAs, though perhaps also other roles) in order to be declared R4D. All these groups have to collectively agree, with a real or virtual handshake at the end of a discussion, that a ticket is ‘Ready for Dev’”. Sometimes it might take 60 seconds to get that handshake, sometimes it might take a number of goes and a lot of revision and effort. But it’s less waste in the long-run to have those discussions before coding has started, than to wait till later and all hell has broken loose.

Does this mean every ticket has to go through a massive formal meeting with very single Dev and QA (and possibly others) invited? This is very unlikely to be a good idea, though it is, in fact, what Scrum mandates – Sprint Planning meetings are always whole-team meetings after all, and it’s in those meetings that Scrum tickets are supposedly brought to a ready state. But such uncompromising, universal rules are clumsy and wasteful, and while some tickets might justify the enormous man-hour cost of a big whole-group discussion (where you’ll probably batch up a ton of ticket discussions to try to justify that cost, thus making it a long whole-team meeting), many (most?) tickets certainly do not. Smaller, less formal meetings/chats might be better. Or you might be able to do it in writing – an IM chat, or in a Jira thread. It’s all contextual. Empowered teams decide such matters for themselves.

Exactly who needs to be in such conversations? It’s often enough to have representative(s) of each function that will deliver the ticket. Typically, at a minimum, this is one person from Product (often the one who wrote the ticket), and one each from Dev and QA, a triplet that is known as the ‘Three Amigos’. But perhaps for some tickets there are more than three; maybe UX want to be separately represented, so you have four. The architect has a big say in this ticket? OK, that’s a different mix again. Each team must figure it out for themselves.

So what do we call this step of getting the right people to agree that a ticket is R4D? Since it involves various ‘Amigos’, it might be called ‘Amigoing’. Or since it ends with a handshake, perhaps ‘Handshaking’ is a good name. Either way it is the gateway to R4D, the necessary check that Ticket Prep achieved its goal of putting the correct information into the ticket to allow for effective delivery downstream.

getting tickets ready delivering
Idea Triaging Ticket Prep Hand-shaking R4D bla… Done

So this is where we’ve got to. We know the steps to get tickets from conception to a Ready for Dev state, from where it is safe for the delivery people to pick them up. We’ve made good progress, but have a long way still to go – what happens in Delivery is for another article.

Agile Board design principles – columns

In previous articles I have stressed the importance of Agile Boards to good software development practice, and speculated on methodological reasons why their implementation is often half-hearted / sub-standard. Now is the time to turn to some practical advice for doing them well.

Agile Boards are two dimensional grids. The vertical chunks are (uncontroversially) called ‘columns’, and each usually represents a single step in a team’s workflow (a ‘workflow’ being the set of all the steps the work goes through from conception to finishing). An Agile Board may also have several horizontal rows, which for some reason are called ‘swimlanes’. Swimlanes are covered in a separate article, but columns are conceptually prior, and they are the topic of this article.

So, columns. Let’s start with: how many should you have?

At one level this is a ‘piece of string’ question – you need as many columns as you need, and it’s as bad to have too few as too many. But this alone is not particularly practical advice, so let’s flesh that out and see if we can give some concrete guidelines which will work in real software development environments. After all, while every context (team, time, product, programme, organisation) is somewhat different, it would be odd if there wasn’t a strong common denominator across many (or even most/all) such contexts.

The first thing to understand is that an Agile Board is a model of your real workflow, just as the map you use for navigating is a model of the real physical world. Models can be built on any scale, and by their nature they are designed to stress some details and hide others. The trick is finding the right scale and the right choice of details for your context.

Consider maps; if the challenge you face is navigating your car journey from London to Edinburgh, this particular map would not be detailed enough:


…but over-magnification is not the solution. At the other extreme you could have a 1:1 scale map of Great Britain to get you to Scotland. This would certainly show you every detail, but would not be particularly useful. You’d struggle to get it in your car, for starters.

But even maps of similar scale differ in the details they emphasize. Ordnance Survey maps, designed for walkers, show contour lines prominently, as the precise steepness of hills, valleys and mountains is extremely important in this context. Road maps show much less of this detail, as they focus on drivable roads where the steepness problem has already been successfully confronted by the civil engineers who built the roads in the first place.

How does this apply to Agile Boards? Well the Simplest Board Of All, the lowest of Lowest Common Denominators, which works for literally any kind of work, has just three columns:


While this may be suitable for some simple scenarios, and is better than ‘no board at all’, it is inadequate for professional software development. What will happen is a large number of tickets will spend a large amount of time immobile, stuck in the middle in the ‘Doing’ column, while a great number of discrete activities happen to them. These activities will often represent genuine progress towards ‘Done’, but this progress is not visible on the board due to the lack of detail. Since the fundamental objective of a Board is to show and drive progress towards ‘Done’, this board is set up to fail.

There are in fact occasions where tickets do get stuck in one column for long periods of time. On a well-designed board that fact will generally indicate some kind of problem that likely needs active management. A correct setup will highlight where there is a Stuck Ticket Problem, whereas if your board design itself ensures that multiple tickets are always Stuck, you’ve drowned the signal in the noise and your board is not doing its job.

But too much detail is also unhelpful, as here:agile-board-too-complex

An outbreak of Column Fever will drown people in complexity – it is hard to scan such a board, and to keep on top of all those columns. It is rare in my experience that a single software development team needs >20 columns to adequately represent its workflow, though if you were modelling something more complex (perhaps the workflow of an entire large organisation, of which software development is but a part) this number of columns becomes far more plausible.

In general you find the sweet spot of roughly the right number of columns through a process of trial and error. The foundational principle of Kanban is ‘start with what you do now’, so just put down your current workflow into an Agile Board, monitor it, and tweak as you go. Of course, as with anything in life, the more experience you have setting these things up, the fewer rounds of tweaking you’ll need to get something really good.

In the next article we’ll do a case study, working through the application of these ideas to a hypothetical (and quite generic) software development team to come up with a board design whose columns are fit for purpose.

Scrum, Kanban, and the importance of visualisation

In a series of articles I discuss the importance of visualisation of work using an Agile Board for effective software development. I contend that while most teams attempt this to some extent, relatively few think about it much or do it particularly well. This article considers a possible reason for this state of affairs: the influence of the underlying methodologies used by such teams.

Scrum is unquestionably the dominant organisational methodology in software development today. Probably second in influence is Kanban, a system whose roots are in hardware manufacturing, and whose principal advocate in the world of software is David Anderson, author of the seminal book on the topic. What is the place of visualisation in each of these methodologies, and how does that relate to what we see in the workplace?

We’ll start with Kanban. The very word itself denotes a visual card, originally used to control inventory in a manufacturing production line:


In Anderson’s porting of Kanban into the realm of software, he states its major principles as follows:

  1. Visualize1 the workflow
  2. Limit WIP
  3. Manage Flow
  4. Make Process Policies Explicit
  5. Improve Collaboratively (using models & the scientific method)

In other words the First Commandment Of Kanban, just as the meaning of the word itself, tell you that visualisation is at the heart of the methodology. Since a ‘workflow’ is precisely the series of steps that any piece of work goes through from conception to finish, you are not even doing Kanban if you haven’t structured your world around an Agile Board (also known, not surprisingly, as a Kanban Board). You would therefore expect practitioners of this philosophy to have thought considerably about how best to create and use such boards, and to be somewhat refined and advanced in their practice of it.

But what about the dominant methodology, Scrum? A search through The Scrum Guide 2016 contains not one mention of the words ‘visualize’, ‘workflow’, or ‘board’, so the contrast with Kanban is immediately clear.

Below are some excerpts from the Guide that could be implemented via something like an Agile Board, but they could be implemented in other ways, even ones that are not visual at all.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog

[In] the Sprint Review… the Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

Monitoring Progress Toward a Goal: At any point in time, the total work remaining to reach a goal can be summed…  This information is made transparent to all stakeholders.

At any point of time in a Sprint….the Development Team tracks [the] total work remaining…[to] manage its progress.

More promising is the language used to describe two Scrum ‘artifacts’, the Product and Sprint Backlogs:

The Product Owner [ensures] that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next

The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal. [It] is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint

This is more like it! But before we get too excited, remember that a Backlog is really just an ordered list, and lists are hardly rich visual experiences. This isn’t quite a direct command to use something like an Agile Board.

And finally there is this:

Significant aspects of the process must be visible to those responsible for the outcome.

This is the most promising allusion, but no more is said in the Guide – the very next sentence goes on to talk about agreeing terminology and a definition of done, which (while definitely important) are clearly nothing to do with visualisation.

In summary, there’s nothing in the Scrum Guide that stops you using an Agile Board, but there’s also nothing that requires or particularly promotes it, and so you might expect that teams following this programme may try some form of work visualisation, but might not have developed it particularly far – which is exactly the situation commonly found in most software development teams. Thus there is a plausible cause-effect relationship between the low prominence given to visualisation techniques in the dominant methodology, and the somewhat half-hearted attempts at a fully-functioning Agile Board that we see in many real software teams.

No article comparing Kanban and Scrum would be complete without mentioning the best short guide to the two; Henrik Kniberg’s masterful free booklet, Kanban and Scrum – Making the Most of Both is a must-read for anyone interested in the topic, chock full of insights and wisdom, and highly recommended.

[1] a constant nightmare for Brits writing on this subject is having to switch between UK and dominant US spellings of key words

Agile Boards 101 – why visualisation is critical

Human beings, like all primates, are primarily visual animals. We depend on our eyes far more than our ears or noses to apprehend and understand the world around us.


This means that, to a pretty good first approximation, we are aware of, think about, and respond to (or, in other words, ‘manage’) what we can see, and ignore what we can’t. Since it’s best to work with, not against, the grain of millions of years of evolution if you want to get stuff done, the Prime Directive of effective management is to make your work visual.

By representing your work visually in a unified way across all the group(s) of people involved in that work – those who request it, do it, check it, manage it, pay for it and benefit from it – then all these people will have a verifiably similar understanding of that work: what’s been done, its current status, what’s coming in the near/middle/far future, what milestones have been achieved thus far and what the problems exist. Without such a common understanding of the world and its challenges, these multiple people are not a team in any real sense of the word, and are correspondingly unlikely to make systematic progress together.

It is thus no exaggeration to say that the common understanding of work, that can only be achieved by making work visual, is how you build effective teams, and teams are what allow you to make progress and deliver what the organisation needs. It really is that important. In my experience very few teams have ever given their work visualisation much thought, and as a result not that many do it well, leading to poor coordination and massive waste.

To summarise: in complex fields such as professional software development, if you want to act like a team and manage your work effectively to make any progress, and do not want to risk wasting all your money and time, you must find good ways to make your work visual.

So what kind of visualisation are we talking about? The relevant characteristic of software development is that work passes through a series of discrete steps, moving through many hands as it does so, both between teams, and within teams (the typical sub-teams in software development being: Dev, Test & Product). While this flow of work has some loops and eddies in practice (ie parts of it are iterative), there is still a clear direction of travel, broadly: idea generation and selection – fleshing out – coding – checking – sending live (= done).

Such step-wise work with multiple handovers is best visualised on a two-dimensional grid, where the vertical columns represent the steps that the work flows through, from left to right (or right to left if everyone’s native language is Arabic or Hebrew), and the individual chunks of work are represented by cards or tickets that sit in the columns. Such a board goes under many names, perhaps the most common being Agile Board or Kanban Board. Although the latter is probably the most accurate term, the principle of visualisation is broader than any one methodology, so I will use ‘Agile Board’ by preference.


As always, lousy implementation will ruin even the very best of ideas, so such an Agile Board needs to be set up, maintained and used well, and I will write a series of articles on this topic.

In conclusion; proper work visualisation using Agile Boards is the arguably single most important component of efficient management of software development. Only by leveraging our most important sense, vision, can you effectively create common understanding and a sense of teamwork in complex organisations. Most software teams try to implement it to some extent (especially if they are more influenced by Kanban than Scrum), but few think about it deeply and many attempted implementations are deeply flawed, which goes a long way to explaining the wasted money and poor outcomes of much professional software development.

As an industry, we need to do this better.

Meetings – how to do the damn things properly

It is not for nothing that a large percentage of office humour focuses on… the meeting.

They take up a huge chunk of our time (Scrum meetings can take up to a third of a development team’s working hours, especially if sprints are short), are synchronous and therefore highly disruptive events (unlike IM or email, which are comms channels you can choose to ignore for a while and answer when it suits you), and are often appalling wastes of time and money.

All activities in a delivery pipeline are subject to a cost-benefit analysis. Calculating the cost of a meeting is the easy part – just remember that, as here, the cost is man-hours, not hours. So a one hour meeting of 10 people didn’t cost the business one single hour, it cost 10 man-hours, which is more than a full day for one person. And of course, that’s just the time in the meeting itself; depending on your office’s setup, there was travel time to and from the room as an additional cost, plus the extra time it takes to get back in the zone of whatever you were doing when you are finally back at your desk – multiplied by everyone in the meeting.

The benefit of a meeting is trickier to assess; it’s completely contextual, and must usually be evaluated qualitatively.

We all know that many (most?) of our meetings would not come out well on such a calculation. In principle, any activity with a net cost is waste and should cease. Yet few organisations will respond to such an obvious imperative by simply cancelling wasteful meetings – these events are too culturally ingrained for that, and for many people form the main justification for their salary.

The best response therefore is to outline and follow a set of rules for making meeting times maximally productive. These rules are no secret, and were widely known and taught many, many decades ago – yet it is astonishing how often they are ignored, entirely or in part, and as a result people’s time is tossed straight on the scrapheap. What follows is a quick review of How To Do Meetings Properly.

Every meeting needs an owner. This is the person responsible for making sure all of the other points listed below happen, either by doing them personally, or ensuring that someone else does them. If you’re ever in a meeting and you don’t get a 100% clear answer to the question I often ask first thing – “whose meeting is this?” – that meeting is probably a waste of time and you should consider leaving immediately.

Every meeting needs an agenda. It can be short bullet points. It could even be one bullet point. That agenda tells you what is to be discussed, in what order, and why, and should be put into the meeting invite. Thus every invitee knows right from the start the answers to the questions “what is the objective of this meeting, and why is my presence required?”. I tell my colleagues (who are often technical people who loathe all meetings on principle) that if a meeting doesn’t have an adequate agenda, they don’t have to go. Simples.

The attendee list should be the smallest group of people who can achieve the meeting’s objectives. Sometimes you have to bite the bullet and accept the enormous cost of a large meeting, but very often there are far too many people at meetings. The whole thing becomes a bloated affair, hard to arrange (there aren’t many rooms for a ton of people, or many times they’re all free), hard to run, and often with multiple attendees disengaged and resentful. Scrum makes all this maximally bad, by insisting that the majority of regular meets are whole team meetings, with no latitude or room for experiment or common sense. There is a colossal amount of waste doing things that way.

Someone needs to chair the meeting when it happens (to keep things moving, make it clear where you’ve got to in the agenda, keep time, ensure the right people are talking at the right moments etc), and someone needs to take notes. Both of these are usually done by the meeting owner. If it’s not my meeting, I usually ask right at the start who is chairing and who is taking such notes. It’s a bad day when you don’t get 100% clear answers.

The chair of the meeting needs to start wrapping up before you all get kicked out of the room, and best practice is to review the meeting notes together on a shared screen to check they are correct. This is vital as the meeting notes will become…

…the meeting minutes. This is a written record, as brief as you can make them without losing important information, of who attended, what was discussed, (more importantly) what was agreed, and (most importantly) what the next actions are, and who is responsible for each action. It is (or should be) every Project Manager’s mantra that an action is only an action when it has i) a thing to do and ii) someone to do it – an unowned action is close to worthless. Any follow-up meetings are identified as actions in themselves (since someone has to arrange them).

The minutes are emailed around as soon as possible after the meeting, to the attendees and anyone else relevant. That email should call out a deadline for a response; if no response is received within the time, the minutes are deemed to have been accepted as the true and definitive record of the meeting/decisions/actions.

And that’s it. All of this – the elementary, universal basics of running efficient meetings – should be both completely uncontroversial, and unnecessary to repeat. And yet time and time again I find that many people in organisations of all types and sizes don’t do some – or perhaps even any – of them.

It is a sadly common occurrence to be delving into the root of some problem or confusion and to find that people have entirely different accounts of what happened and what was agreed at a relevant meeting. “Someone send me the minutes of that meeting”, I challenge, all too often it is then sheepishly that there aren’t any. This lack of discipline is simply unacceptable – we are all responsible adults after all.

So now we know – once more, I’m sure we knew it already – what it takes to run a decent meeting. We should still look to reduce their length, frequency, and attendee count to the minimum; after all, the modern office offers many alternatives to the formal meeting – informal chats, email, IM etc. But if you’re going to do meetings (and let’s face it, we are all going to spend a lot of our lives in them), we should at least make an effort to do them well.

I leave the last word on the matter to the true expert, Dilbert.


Stand-ups: the Scrum way is the wrong way

The Daily Stand-up, or Daily Scrum, is a short meeting that almost always takes place in the first half of the morning, usually 10-30 minutes long (the Scrum Guide dictates a quarter-hour).

I like them. They are really important. But any good idea can be messed up by poor implementation, so in this article I will talk about how Scrum says you should do Stand-ups, and some improved variants on that.

First, the name of the meeting. Scrum certainly didn’t invent the idea of a quick daily catch-up meeting, so the term “Daily Scrum” is somewhat presumptuous. The most common alternative name, “Daily Stand-up” has a different problem; it derives from the idea that attendees should be made deliberately uncomfortable by enforcing a standing posture in order to keep the meeting short.


Now of course all meetings should be kept as short as reasonably possible while still covering the necessary. But making people stand up is a terrible way to drive this; discomfort is just as likely to make it harder to concentrate or encourage people to arrive late or not at all. In general, the chairing and facilitation skills needed to run good sit-down meetings are more than sufficient for this meeting – adding discomfort doesn’t improve anything. Personally I have no objection to people standing up if they all want to, but it shouldn’t be mandatory and the meeting shouldn’t really be named thus. The optimal name for this meeting is perhaps “Daily Catch-up”, but most companies seem to call it a Stand-up, and to avoid confusion so shall I.


Stand-ups almost always happen around the board that represents the team’s work, whether this is in software or physical (usually post-its on a whiteboard). Interestingly, such boards are not mentioned at all in the Scrum Guide, an astonishing fact which I will discuss elsewhere. So although these boards are literally not any formal part of Scrum, they are a critically important element of managing complex teamwork, and it is entirely correct that they are the focus of the Stand-up. Indeed I see the principal function of the Stand-up as being to ensure that The Team Board is correct, and that the whole team agrees it is correct, at least once per day, and tons of other Good Stuff flows from that.

Now there are two basic ways to structure a discussion about finding the optimal fit between a bunch of people (the attending team) and a bunch of work (represented on the board). These are:

  1. people-focussed
  2. work-focussed

The Scrum Stand-up format advocates the first, and this is the wrong choice. What exactly does Scrum tell you to do? You should go round the team, person by person, and each answers the Magic 3 Questions:

Q1: what did I do yesterday?
Q2: what will I do today?
Q3: do I see any impediments?

By the time everyone’s spoken, this format guarantees that you know what everyone is planning to do – there can be no slacking! But it does not of course guarantee that everyone is working on the right stuff; it is entirely possibly in principle and in practice for everyone in a team to have said what they’ll be busy on, but for nobody at all to be working on the Most Important Thing(s). What a waste of a meeting if so. Now a perfect alignment of individual work proposals to team priorities may have come out of the ensuing conversations – I sure hope it did, anyway – but the Scrum format does not focus on that desirable outcome.

The alternative is to make The Team Board the focus of the meeting, and fit people to work in priority order. A well-set up board makes priority order obvious, so you start with the single highest prio piece of work, and ask who’s working on it, to do what exactly, and whether they need any help. A super-short summary of what is agreed gets noted down (when I run these meetings I do this summary real-time within the board software, with everyone watching and double-checking, and it takes an acceptably trivial amount of time to do so).

You then move on to the second-most important bit of work. Then the third. And so on, till everyone has their day’s work identified to the team’s satisfaction. You might keep going a little bit after that to look at what coming up next, or you might end the meeting at that point. Now everyone knows what they’re doing today, everyone is working in priority order, and The Team Board Tells The Complete Truth – Job Done, successful meeting over.


This is supposed to be a short meeting, so you have to keep things flowing. When a discussion breaks out in a Stand-up, the team will often let it run for a short time (30 or 60 seconds) to see if it comes to a swift resolution. If not, someone in the team should signal “time out” using the international gesture above (and everyone in the team should be empowered to do this, not just the person running the meeting), and then it’s someone’s job (usually the person running the meeting) to note down who needs to discuss exactly what at a later point in time (often, immediately after the Stand-up). Thus the Action Points / Minutes of a Stand-up are, unlike other meetings, a combination of a) an updated Board and b) a series of discussions whose need has been identified during the Stand-up.

This alternative format avoids forcing people to try to remember what they did yesterday (most people can’t remember what they were doing 10 minutes ago, it doesn’t mean they’re bad colleagues). It asks the sensible question of “do you need any help?”, not some ridiculous question about “impediments”, and most importantly you know for sure and certain that everyone is working on the most important thing they can do. This is guaranteed by the structure of the meeting, and is far, far, far more important to business outcomes than structuring your meeting to ensure nobody is being lazy.

So the golden rules of successful Stand-ups turn out to be:

  • walk the The Team Board in priority order (meaning of course that you have to know how to set up a board)
  • fit people to the work, not vice versa
  • update the board in real time without destroying the flow of the meeting (perfectly possible)
  • keep things flowing with the time-out gesture
  • stop when everyone’s got the day’s work agreed, possibly plus a little look into tomorrow

You can judge the health of a team pretty quickly by the state of their board and their Stand-ups; getting both right is critical. Judging a board is an art in itself, which I will write about separately. But pretty much anyone can observe and judge a meeting; look for the quality of communication and decisions, body language, efficient use of time, what is written down and how, and whether the objectives of the meeting are met quickly and efficiently.

I would encourage anyone interested in a team and/or its deliverables to attend Stand-up(s). Watching people programme or test is often pretty dull (it’s the same as ‘watching people type’), so the Stand-up is the closest you can get to Walking The Line in a factory setting, and your quickest route to assessing the beating heart of a team. Try it – you may well be surprised by what you find, for good or for bad 🙂