I was coaching a software development team recently, and following the day’s Stand-up I asked the TPM* of the team a series of questions about how the Stand-up had gone, and how her team is currently working. It then struck me that these questions are not a bad checklist for judging the level of organisation of a team, so here they are:

• Does everyone in the team know & agree the priority order of all its tickets?
• Does everyone instantly understand what work a ticket describes?
• Does everyone instantly know where that work has got to?
• Does everyone give crisp, clear answers to what’s the next step and who does it questions?
• Does everyone understand the whole work queue so that they know what they should be picking up next?
• Does the board clearly and simply tell the truth about the team’s work such that anyone, inside or outside the team, can get a pretty good idea of What’s Going On in a 5-second skim?
• Does the team have a good grip of the incoming work, and continually manage to process that work into tickets smoothly, efficiently & in timely fashion?
• Are the often complex decisions & assignations around tickets that are made in the Stand-up (& at other times) clearly recorded somewhere for future reference and to avoid endless arguments, confusion and waste over what was actually decided?

The TPM’s answer was: “definitely ‘no’ to all of those, and in no team that I’ve worked on was that the case (well, maybe one, but they were so unhappy and under so much pressure that I wouldn’t call them a successful team)”.

This answer saddened but did not surprise me. My own experience is that it is absolutely possible to get teams to a state of self-organisation where such questions are asked, and easily answered; and moreover that such teams tend to be happy ones, since attaining this improved level of organisation involves reducing levels of waste, streamlining processes down to only those that actually help, and seeing the team’s work makes an actual, real-world difference. These things are enormously motivating.

So how to achieve this nirvana, asked the TPM. My short answer was that the preconditions for achieving this level of organisation can be divided into two categories.

The first category is attitudes within the team, where the following is required:

• discipline
• common sense
• a desire to change
• a willingness to try out new ideas & properly evaluate their impact
• a commitment to thinking your way through problems
• a commitment to continuous improvement

Secondly, there are some non-negotiable tactical tools that must function well in order to get to this good place:

• an Agile Board that works right
• a Stand-up that works right

As for the long answer – well, that answer is here 🙂

—

*TPM=Technical Project Manager. Also known as Agile Project Manager, or (if you’re running Scrum) the Scrum Master.

There’s an art and a science to creating good Agile Boards. As with any truly Agile endeavour, your board design should evolve over time in response to a continual inspect and adapt process, so in theory, whatever your starting point is, you’ll eventually end up in a good place, where the board is a decent model of your team’s work.

But of course the better your start point, the fewer iterations it will take to get into that sweet spot where your board really works, so let’s examine what a good start point might be.

Many teams are somewhat intimidated by more than a few columns on the board (especially to start with), and might not feel comfortable beginning with the kind of detailed workflow that I outlined here and here. And that workflow was for managing software development, which you might not be doing.

So here I offer a simple generic workflow that is a worthy start point for any team; and I really mean any team – there’s nothing in what follows that references software development, or any other technical work, so this could work for a Finance Team, for example.

Here’s how the lifecycle of a generic piece of work maps to these columns:

• A ticket describing a piece of work is created. This ticket has not yet been properly evaluated, and for all the team knows it could be anywhere on the value scale from “brilliant and/or extremely urgent idea”, to “complete nonsense that deserves immediate deletion”. Tickets in this “they’ve been created and nothing else meaningful has happened to them yet” state are in the Candidate column. Other names that work for this column are Inbox, Idea, the Jira default To Do – and you may have better names still.
• This next thing that needs to happen to a ticket is to flesh it out such that it is ready to be worked on in earnest. That fleshing out is captured by a column called Defining. At a minimum, an adequate ticket definition might be as simple as a one-bullet-point Definition of Done. It might require more, maybe much more – detailed Business or Technical Analysis, accompanying files of various types such as Spreadsheets, Process Flows, Mockups or Wireframes… it’s all contextual, and in this simple workflow it’s all done under a heading of “Defining”.
• When a ticket has been properly fleshed out – meaning that representatives of all the downstream functions (the roles that will need to work on the ticket later in its life) have agreed that what’s written in the ticket enables them to efficiently take on their portion of the work when the ticket lands with them – then the ticket is Ready to Start. This, technically, is a “buffer state” – it represents a gap between activities, rather than an activity itself.
• When the real meat of the work is under way, the ticket is In Progress. I actually don’t much like this term for a column, as every state between the first and last is some kind of “in progress”. For software development teams a better term for this state is In Dev, but for non-tech teams I’ve yet to think up a better name.
• Any non-trivial work should always have a second pair of eyes on it before it is presented back to the people who requested it; you don’t want to look a fool in front of your customer, after all. This is the Reviewing step. It’s might be performed by a peer of the person who did the work, perhaps by someone in the same role (eg one developer checking another developer’s code), or it might be done by a specialist function (eg QAs/Testers). As ever, such decisions are contextual; but that non-trivial work should be properly reviewed/checked is as close to a universal truth as you get, and that’s what this column represents.
• Finally, whoever wanted/requested the work (the Customer, or their proxy) needs to agree that they’ve got what they wanted (or near enough, dammit) before you can declare the piece of work to be “Done”. This is the Sign-off step, and in a well-functioning team should be unproblematic. After all, all that’s required for Sign-off is to compare (i) what’s been delivered with (ii) what was agreed would be delivered, and since (ii) is definitely written in the ticket (right?), and since you make every effort to regularly update the Sign-off people on progress (perhaps they come to your Stand-ups), there ought to be little in the way of controversy or surprises in this step. If a team is having problems signing work off, the root cause(s) are usually to be found upstream, often all the way upstream at the Defining stage, and need to be solved there.
• Hopefully I don’t have to go into great detail about what Done means.

So there you have a simple, generic workflow that’s a decent starting place for any team representing its work on an Agile Board, and may turn out to be fine longer-term too. Remember; this is all empirical, so inspect and adapt, keep what works, and change what doesn’t!