Liz Keogh's blog

There are a few exciting speaking and training engagements coming up, many of them UK based!

First off, two tutorials:

I’m running my first Deliberate Discovery, Cynefin and Real Options tutorial at Skills Matter on 29th May. These three ways of thinking and modelling software development and the world in general have really helped me, and I’d like to pass the techniques on. Highly workshop-driven and not at all technical.

At the end of September I’ll be running my 1-day BDD tutorial as part of Agile Cambridge. This is the only BDD tutorial I’ll be running this year, so if you’re interested, get in there now! Dan North (my mentor in all things BDD and Agile) and David Snowden (Complexity Thinking and Cynefin guru) are keynote speakers, so it promises to be an excellent conference!

I’ll also be speaking and running workshops through the year:

The Next Generation Testing Conference organised by Unicom is on the 23rd. I’ll be on the panel talking about Agile, and particularly ranting about our obsession with granularity and our need for certainty even where it doesn’t really exist.

I’m going to be talking about Real Options at Dev Tank in London on the 29th, after the Progressive .NET Tutorials. It shouldn’t be a long talk, so lots of opportunity to catch up with your fellow devs over a beer. More details to follow – watch the space!

On June 7th, I’ll be giving an overview of BDD, how to do it well and why it works at Agile East Anglia. If you’ve been out of the loop on BDD, this is a great chance to get into it, and I’ll be answering any questions you have too. I think there may be just one ticket left…

In August I’ll be at Agile 2012 in Dallas, running “Turning and turning in the Widening Gyre”, a workshop on complexity and deliberate discovery, and “BDD: Look, no Frameworks!” on how to do BDD using custom DSLs instead of BDD tools, while keeping steps maintainable and readable.

On 21st – 22nd September I’m honoured to be one of the keynote speakers at Lean Agile Scotland. Topic still to be decided, but it’s going to be related to people and the inside of our heads; one of my favourite minefields.

I’m also speaking at GOTO this year (October 1st to 3rd, Aarhus, Denmark). In my talk, “To be honest…” I’ll be looking at why honesty is so important and yet so hard to do.

In the meantime, I have some days free for in-house training or coaching. Please get in touch now, before the rest of the year gets this busy too!

When I started coaching Agile methodologies, I didn’t know how much I didn’t know.

I had come from Thoughtworks, a company whose tools and processes are mostly driven by Extreme Programming, aka XP. In that respect, most of what I learnt and coached was very similar to Scrum, albeit with different words. We called them iterations instead of sprints, and had stand-ups instead of daily scrums. We had planning meetings, but we didn’t make commitments – just estimates. We had collaborative code ownership and a focus on delivery instead of a cross-functional team, which meant that we ended up with flexible and blurred roles anyway. We had the same problems – getting people co-located, helping business stakeholders become more comfortable with the risk and uncertainty of software delivery, and changing the culture and the infrastructure of the organisations in which we worked. We also had a number of technical practices like unit testing and continuous delivery that aren’t really prescribed by either Scrum or Kanban, but which both put forward as a Really Good Idea.

In the last few years, I’ve been privileged to be part of the Kanban community. I don’t consider myself part of the Scrum community as such, but I’m part of the larger Agile movement and strongly aligned through my background in XP.

In this post, I’d like to cover some of the differences I’ve seen between Scrum and Kanban, and add in some insights from the Cognitive Edge training I’ve done using Cynefin and complexity thinking. This isn’t going to be a full description or comparison, but it should hopefully provide some food for thought, and allow people to see some of the different tools available from both approaches.

Disclaimer: I haven’t explained every term I’ve used, or every practice I’m referencing. I’m assuming familiarity. If you don’t have it, you can to run a search on anything I haven’t linked. I’m also using the terms “Scrum” and “Kanban” as aliases for the community and / or leadership, and I haven’t made much distinction between Scrum.org and the Scrum Alliance. This is deliberate, and I welcome feedback.

Scrum and Kanban have more similarities than differences.

Both methodologies put people and their interactions at the heart. Both have a clear focus on value, fast delivery and the continuing growth of the team and its ability to achieve those valuable deliveries. Both contain mechanisms for feedback and improvement, allowing processes to change according to context. Scrum used to have a very prescriptive format – not dissimilar to XP – but this has been flexed in recent editions of the Scrum Guide, as alternatives to some of the practices have emerged. It’s not even beyond the realms of possibility that some of the alternatives have emerged from the Kanban movement!

Also recently, Scrum has started to evolve from being a set of processes to being a very loose framework in which processes can themselves evolve. Used this way, it joins Kanban as a meta-process, from which the real process emerges and continues to emerge.

IMO, both are infinitely better than that broken model called Waterfall, and both are better than having no process at all.

Scrum isn’t about the Scrum Meetings, and Kanban isn’t about the Kanban Signal.

Both methodologies are named after just one small aspect of their whole. In Scrum, the scrum meetings allow the team to share learning and information about how they’re doing and to make decisions about what to work on next. In Kanban, the kanban signal – showing that someone is free to help move a piece of work closer to delivery – provides a similar focus point. Scrum teams frequently use a card wall that’s similar to that of a Kanban team. Kanban teams frequently have daily meetings like Scrum. To an outside observer, the differences could seem so small as to be irrelevant.

Kanban measures lead and cycle time, Scrum measures velocity.

Both Kanban and Scrum have their origins in “Lean” thinking. We like to think of “Lean” as the set of principles behind the Toyota Production System – the process by which Toyota builds and churns out its cars – but both methodologies have an implicit recognition that software development holds more similarities with product development than a production line. In Toyota, kanban cards are used to help eliminate large amounts of spare parts and other inventory building up; providing a buffer which lets work flow through the system. Both Scrum and Kanban value this flow. Kanban suggests limits on the amount of work in progress, allowing constraints to be addressed. Scrum encourages collaboration, causing less work in progress. Scrum uses the proxy of velocity and estimation, which can help to prevent metrics around productivity becoming targets. Kanban uses lead and cycle time, tying its measurements to valuable targets that are hard to game.

Scrum starts with the right context; Kanban improves the existing context.

I once asked a Scrum practitioner, “What do you do if you don’t have a cross-functional team and you’re not co-located?” He told me that that’s the hardest bit of Scrum – starting from the right context. I realised that these difficulties, once overcome, also provide significant value. Just starting from the right context might be a good idea!

On the other hand, Kanban is neutral regarding context. Of course we think that being co-located is a good idea. Of course we’d love to have multi-skilled, flexible, collaborative professionals. If only this was as common in the industry as we’d like. Kanban’s focus on metrics and its measurements of lead and cycle time might make the impact of not having these apparent, so it’s a good place to start. (I used to think it was only suitable for highly skilled, disciplined, advanced teams, but experience and experimentation has taught me otherwise).

Kanban visualises what’s happening; Scrum visualises an ideal.

This is one of the biggest differences for me. The extent to which Kanban visualises reality is extreme enough that the board might not even have linear flow. Whatever the process policies are – whether helpful or otherwise – Kanban focuses on making them explicit, so that they can be addressed and improved. If the team happen to work with five different phases, this is reflected. If the team write technical stories, they go on the board.

In contrast, Scrum teams tend to set up a visualisation of an ideal process, helping teams to adopt that process. Done prescriptively, Scrum provides a “big bang” starting point. Because it consists of step-by-step practices, it’s easier for beginners to adopt. That could be Scrum’s blessing – but it’s also its curse.

Certification and early adoption.

Scrum has certification. Kanban doesn’t.

Yet.

In the early days of Scrum, there were few enough trainers and experienced Agilists that no matter who taught Scrum, it was done pragmatically. Early adopters tend to experiment, and those experiments led to a better understanding; to a focus on people and interaction, rather than process. Unfortunately the “Scrum Master” certificates are easy to get, compared to any other discipline that asserts a quality of mastery or independence. The training provides simple practices that are relatively easy for teams to adopt. Scrum is taught by a wider group of people, and the quality control over that teaching has become harder to maintain.

As a result, Scrum has been widely adopted and is considered pretty mainstream – the default Agile methodology – but the certificates associated with it provide a level of confidence that the training generally doesn’t support. I’ve met a couple of excellent Scrum trainers, but I’ve also seen “masters”, armed with their certificates, instituting mini-waterfall and silo’d teams as they replace those parts of Scrum that aren’t prescriptive, or that they don’t understand, or that they can’t achieve within a context that they can’t change.

Any examination or certification body suffers from a paradox: while the people who rely on those qualifications need them to be rigorous, the people teaching and taking those qualifications would much rather they were easy. The Scrum Alliance and Scrum.org between them have both helped to set up and reinforce the desirability of their certifications, and I can only imagine the difficulty that their leaders face in balancing the financial incentives involved against the good of the IT community and industry.

In contrast, Kanban is still in an early adopter phase. We’re still working out, as a community, what’s possible. Most Kanban practitioners and coaches are bright, experienced, willing to experiment, desiring of feedback and able to share and learn from each other in a relatively small community. Scrum no longer has that luxury. We don’t know what will happen if and when the Kanban community treads the same path, but we do have the advantage of being able to learn from what’s happened with Scrum.

You can also bet that the leaders are being watched carefully by the rest of the community to see how they meet this challenge. So far I think they’re doing an excellent job. So far there are no certificates available. So far.

Some thoughts spurred by Cynefin.

The Cynefin model of complexity thinking teaches us that in a complex environment – one in which cause and effect can only be understood in retrospect, and which includes most systems with people in, as far as I can tell – we should increase the opportunities and incentives for interaction, so that the practices best suited to the context can emerge.

Waterfall treated software development as complicated, using Cynefin’s domain definition; as though each project was a thing that could be taken apart into many pieces, analyzed, then put back together as a whole. Unfortunately the ability of human beings to make mistakes, combined with our inability to either effectively communicate our intent or see into the future, has meant that this was always doomed to fail. (Most successful Waterfall teams, who complain to me that I label it unfairly, have not practiced it in a pure form, and have included elements of iteration, feedback and common sense. When these are lacking, any methodology is doomed to failure, but Waterfall above all others doesn’t mandate or even leave much room for them.)

When we look at applying Scrum prescriptively to a Waterfall team, we’re looking at pushing forward increasing levels of interaction in a context in which interaction is easy – where teams are co-located, have all relevant skills, are willing to collaborate and can share learning. Scrum’s acts of estimation and breaking stories into tasks force team members to talk to each other. The act of commitment which Scrum recommends in planning meetings causes a team to discuss their concerns frankly. The cycle of feedback and retrospection allows the team to discuss whether they’re delivering value and how to do it more effectively.

But Waterfall is no longer the context from which we always come. Many Agile adoptions aren’t taken up by teams doing Waterfall; they’re taken by teams who have abandoned their process altogether, and are talking and sharing their learning in order to work out what to do next, while having no metrics against which they can improve or track their progress and risk.

The context in which Scrum starts is not often possible. We’re not always co-located – many start-ups and companies now allow developers to work from home, and the industry still seems to suffer from a delusion that offshore work is cheap to obtain. We may not have multi-skilled people – it takes some time to learn skills. In both the environments which are already more collaborative than Scrum, and the ones which are a long way from being able to do it successfully, Kanban can be useful.

I fear that this may include the majority of environments and the IT industry, and that’s why I choose to hold myself closer to the Kanban community than the Scrum one. IMO, Kanban works in a larger set of contexts than Scrum does, even though for a subset Scrum might achieve results faster.

They’re still more similar than they are different… and I still like XP too.

If you’re not familiar with the concept of Chickens and Pigs, it’s based on an old joke in which a chicken and a pig set up a restaurant. The chicken wants to call it “Ham’n'Eggs”. The pig says, “No thanks. I’d be committed, but you’d only be involved.”

The story is used in Scrum and other methodologies to suggest that only “pigs” – the people whose bacon is on the line – should have the right to speak in stand-ups. This deliberately excludes management.

Yesterday, Dean Leffingwell spoke on the subject at Agile 2011. He pointed out that the practice calls out the chickens as the “bad guys”. “Wrong!” he says. “These are the people who run the company.” Quite aside from some cultural implications of calling people “pigs” – it doesn’t go down well in countries which consider pigs to be unclean, for instance – excluding management from stand-ups can be disrespectful at best, and damaging at worst.

I finally decided to be done with the Chicken and Pigs analogy and practice after a roleplay organised by Derek Wade, in which the manager had something very important to share – something that would have reduced the stress the team was experiencing, as well as the workload, the weekend’s overtime, and the risk to delivery that was approaching our fictitious team.

The manager started to speak. “I…”

“You’re a chicken,” the Scrum Master announced. “Next!”

Let’s not.

A few people here at the Lean Software & Systems Conference have asked me to write more about using the Dreyfus Model to game culture.

I’ve already written quite a bit about the Dreyfus Model – how to use it to create experts, grow teams, etc. – but this is more of an experience report.

I was working with a number of other coaches to transform a small IT organisation. We were asked to come up with some strategies for spreading the adopton happening in a couple of teams. When we presented our options, the head of IT went with one of the faster ones: giving us an afternoon every 2 weeks to play a game with the developers.

We assigned developers and testers to teams made up of people they hadn’t worked with before, one tester to two developers. Then we gave each team the requirements for the Game of Life – just the basics:

• Cells with less than two neighbours die
• Cells with more than three neighbours die
• Cells with exactly three neighbours are born in empty spaces.

We gave them 15 points for developing these rules, and also scored them according to the cultural values we saw, taken from Kent Beck’s XP books:

• Respect
• Communication
• Courage
• Simplicity
• Feedback

We were already using Dreyfus models with numeric values to help individuals move forward. We adapted these for the game:

1. Novice: team exhibit antipatterns
2. Experienced Beginner: team are human
3. Practitioner: team are behaving like successful Agile team members
4. Knowledgeable Practitioner: team behaviour influences others
5. Expert: superhuman.

By the end of the game I don’t remember that we had any 2s left, let alone 1s, and one team were exhibiting 4s. Here’s what we did.

How we did the marking

The 5 coaches got together at the end of every session to share their notes – what we had seen, how the teams had behaved, what points we thought they should have. If we hadn’t seen anything particular, we gave them a 2 – ordinary human beings.

Whenever a team exhibited particular antipatterns (1) or particularly excellent behaviour (3-4), we gave them feedback as to why. We also only ever marked whole teams. If a particular member of the team was showing anti-patterns, it was the whole team’s responsibility to help them adopt a better culture.

We also held a clinic in which team members could ask for clarification, or advice about how to improve their score the next week.

An example of marking

On the first day, one team named themselves “Team Buttplug”. The coaches had spent a while putting the game together – coding a UI for the teams to use, setting up version control, etc. – and we felt that this wasn’t very respectful of our efforts. So we gave the team a 1.

The next week, the team renamed themselves “Team Redemption”, and scored a 3. We appreciated their turnaround!

The stories

After the first week, we added more stories, which made the software progressively more complex. The testers started having plenty to do!

The stories we added were:

• The grid can now switch from bounded (no cells outside it) to infinite (gliders run off the edge).
• The grid can switch from any other to wrapped (gliders return on the other side).
• The cells change colour depending on how old they are.
• The cells change size depending on how many neighbours they have.
• The rules can change from Conway’s rules to High Life (cells are also born when they have 6 neighbours).
• Users can step backwards.
• Users can scroll around infinite or wrapped grids using a joystick.

Gaming the culture

The teams quickly worked out that behaving according to the culture was an easier way to get points than developing the increasingly complex software.

“What will you do if we just pretend to be courageous?” one developer asked.

“How will you do that?”

“Well, we’ll just pick up things we’ve never done before. Or we could pretend to communicate; just get a whiteboard and talk about what we’re doing and draw on it.”

“Sure, we’ll give you the points if we can’t tell the difference…”

Of course, these cultural values are really hard to game without actually adopting them. Teams pretending to communicate better actually were communicating better. Teams exhibiting respect engendered respect around them. The culture of all the teams gradually improved. People started to be more forgiving; to provide feedback to us as well as to each other; to treat each other with respect and collaborate more and more effectively.

The end-game

On the last afternoon, two teams from the 8 we had were almost neck and neck. There was 1 point in it. One of them had developed more of the software – they had a particularly heroic developer who did much of the work.

The other team had started off poorly. They weren’t the best at development. However, they were using their tester very effectively, talking to us and clarifying the requirements, discussing their design on the whiteboard… and slowly overtaking the first team.

They won by 1 point. Thoroughly deserved.

All the teams who participated were amazing, but most of all I remember the head of IT who let us run the game in the first place. That commitment to learning really helped the teams understand the importance of what they were doing.

Swanky prizes helped, of course!

After my talk at QCon London, some of the feedback I got was that I was really, really mean to PMs.

In fairness, I was also mean to Tech Leads, architects and other managers, both in and out of software, as well as treating development teams as if they were made of sheep. It was a talk titled “Learning, Perverse Incentives and the Evil Hat”, and it focused on how we game systems, as set up by people who create the processes through which those systems emerge. But, mostly, I was indeed really, really mean to PMs. My hat was evil. I’m sorry.

And because I hadn’t been mean enough, Dan North and I ganged up to do it again during our Deliberate Discovery talk at Cuke-Up today.

It’s very easy for me to take the mick, especially out of a role that I’ve never taken on. I’d like to redress the balance.

Project Managers – the good ones, anyway – are invaluable. They protect us from the stress of high-level management and business politics. They spot obstacles coming and help prevent them from hitting the team. They negotiate deadlines. They facilitate collaboration between teams and across departments. They manage the budget. They work to protect the stuff that’s working and address the stuff which isn’t. The best project managers are servant leaders; invested in providing a motivating, learning, creative environment in which useful, effective software development can actually happen.

Not all project managers are good project managers. This is mostly because they’re learning, and while we get environments in which we can share our skills and learn from each other – pair-programming, talking, fixing problems together – project managers are frequently put in competition with others (because the high-level managers are still learning, too). The politics and existing processes can make their job hard. Really, really hard. They’re expected to be independent. They’re expected to know how to do their job. As one PM put it, “It’s a lonely place to be.” I’ve not yet worked as a PM, but I’ve coached a few.

So be nice to your project managers, and give them an environment in which they can learn. A PM is also human, and will make mistakes. Make it safe for them to say “Sorry”. Take them down the pub for a chat, and give them honest feedback. Very few PMs actually bite, and most will be grateful.

If you can do this enough, hopefully they’ll forgive you for the taunts, easy jibes and jokes at their expense. And hopefully they’ll forgive me too.

Some while back, I was invited to a meeting with two people who worked within that area called “Human Resources”. To be fair to the individuals concerned, neither of them ever referred to people as ”resources”, and indeed both of them showed an uncommon desire to learn about what really worked in companies and projects. However, the conversation started as many Agile conversations with HR often do.

“We understand that the IT department is transforming to Agile. What training courses would you recommend?”

Apparently this is the way that many methodologies and practices - including Waterfall, Prince 2, and most lately Scrum – have been taught. I’ve only found one company who managed to successfully transform to a Lean / Agile way of working from a few Scrum courses run by Martine Devos, and they did it because their culture was so well set up for it. No other company that I know of has made a transformation to Lean or Agile without significant external help. Dan North has previously compared companies who can’t deliver software, and are wary of external help, to patients too shy to tell the doctor about their constipation. It’s a shame that we can’t simply say, ”Don’t worry; take two of these pills and eat some prunes.” Agile isn’t something which can be taught in a couple of days. Really.

Still, they can make a good start. I outlined the things that I found worthwhile in an Agile training course. I provided some hints and tips for making the learning from those courses stick and ensuring that development is ongoing. I also provided a caveat that I’ve come to regard as almost a tradition. If you ask me to teach the people in your company Lean or Agile, I’ll also give them some basic skills to spread that movement and develop their skills further. I’ve not yet seen Lean or Agile survive without some champions on the ground, and one coach can’t do enough on her own. Furthermore, the basic skills I teach to spread the movement are related to life coaching. I will be training staff with the ability to look objectively at their projects, chunk their observations up to their personal values, decide on their goals, and match their lives to their goals accordingly. It helps them to leverage their passion; to make people care as much about their work environments as they do about watching the footy with their mates, coming home to their loved ones, or tucking their babies in at night. When you’re giving up forty hours a week to a profession, the opportunity to develop passion around that profession is addictive, and rightly so.

Often the people I pick to help make the change are those who are most dissatisfied with the status quo, and who want the change to happen. Even if I don’t help these individuals to help themselves, they usually find ways anyway – a little bit slower, perhaps; but just the knowledge that change is possible, and valued, seems to cause them to go out and seek new ways of doing things. Having a coach on the ground and an explicit mandate for change accelerates their desire to do something different and their acquisition of practices that will show them how. They tend to value principles over practices; they don’t really care which Agile toolbox we use, but they do value self-empowerment, transparency, honesty, care for one’s work and pride in the result, delivering real value, getting feedback and learning while they do it. They’re often the quiet ones, working tirelessly behind the scenes to make sure that a project succeeds; or the loud ones, vocal in their objection to existing practices which don’t help them to deliver. They’re usually the ones you want to keep, too, especially if the Agile transformation is going to succeed.

If you happen to be the kind of company who allows its goals to conflict with those of its staff, Agile training could be quite dangerous. If you want training in Agile, you are going to have to support your staff in adopting it. The skills they obtain will be hugely valuable within the industry. There aren’t enough people with these skills to satisfy industry demand. I browsed a couple of UK job sites over the recession and the Agile role demand dipped for about 3 months, 6 at the most. I hear that skilled professionals in the US haven’t been out of a job for long, either. Whatever gratitude your staff feel at being given the training will be weighed against your support of their new, tantalising, fun way of working; an assertiveness or curiosity which perhaps weren’t there before; and a disinclination to play victim to project management decisions when a different way of thinking could see them in control of their lives.

In other words, if you train your staff in Agile, you’re also training them to see through some of the aspects of business which don’t always make sense. These might include bonuses, yearly reviews, corporate standards, unreasonable deadlines, blame cultures, overtime cultures, unnecessary projects, unnecessary features, unnecessary management, unwieldy timesheet systems, holiday restrictions, cost-cutting on tools, cost-cutting on infrastructure, cost-cutting on coffee (never do this), awkward seating arrangements, lack of meeting facilities, dodgy third-party software, alienated offshore teams, command-and-control management, unconfident management, bullying… the list goes on. Of course no company can change overnight – but the only way to retain staff newly trained in Agile is to listen to their concerns and act on them.

Agile isn’t a mechanism for success, whatever you hear in the brochures. It’s a mechanism for making failure transparent so that you can adapt quickly, and it will show failure at many different levels. For companies who are genuinely interested in improving their ability to see difficulties emerging so they can respond, Agile is a godsend; otherwise, it’s a curse.

You can minimise the effects of Agile transformation by starting small - taking one team, and slowly growing the adoption – and this will give you time to respond. You will need to respond, or you’ll be fighting a tide of people leaving, and a growing number of companies wanting to hire new staff with Agile skills and passion. If you want to be ahead of the wave, keep the staff you’ve got. Talk to them. Find out what they most want from their jobs, once they’ve got a better idea of what’s available. Act on it. The average developer appears to have a frustration threshold of a few months, six at most, with testers and analysts not far behind.

You could, of course, resist transformation. Retain the old command-and-control structures, the change requests, the three-month documentation cycles. It takes longer to respond to change, and in many domains, change is happening faster and faster. Eventually someone will start to take over your portion of the market, differentiating themselves and responding to industry changes faster than you can. If a company wants to stay in business when technology, society and markets move so quickly, it is inevitable that teams will need to be empowered to respond to change themselves. Any such empowerment will bring the same transparency and the same problems that I’ve outlined here, whatever banner it comes under.

Failure is inevitable. It’s already happening. Companies who accept it can handle failure and adapt. Lean and Agile practices will make it visible more quickly and provide some mechanisms for turning it around. Traditional practices will keep it hidden until later. All you can do is prepare for failure and the problems that it will bring. Engage all the departments, including Human Resources. Be ready to change your metrics. Be ready to listen and get feedback.

Be ready to fail… because failing, and preparing for failure, is the only way to succeed.

The Pask Committee have given the Gordon Pask award to me this year for deepening existing ideas and coming up with some pretty crazy ones of my own.

I can only do this because of the fortune I have in my communities, including some great coaches on either side of the pond, the Extreme Tuesday Club, Thoughtworkers and alumni, and the wonderful online communities in Lean and BDD.

My communities give me a safe place in which to play and get feedback. I am a member of a community of thinkers, and if I should happen to be a catalyst more than others, I consider that to be a tribute to those who have inspired me. This is as much a measure of your success as of mine. Thank you all.

I’ll be running the ever-popular Haiku Workshop in the SPA2010 evening diversions on Monday 17th May. My focus for this is limited to 24 people. I’m not sure how attendance is being organised; however, if you want to attend and find out before I do, get in there quickly!

Chris McMahon mentioned my example of a coaching kanban board in the second of his series of posts against Kanban. That it comes across as simple and infantile in Chris’s example is my fault; I only really touched on the “signal” aspect of the kanban board in this conversation, and didn’t go into more detail. So, in this post, I hope to correct that.

Picture a scene. You’re one of five coaches, hired to help transform the IT department of Screwfix. As part of this effort, you’ve set up a lovely story board on which you put the things you’re working on. This is the kind of thing that we had on our boards (all stories in this post are just examples, I can’t remember the exact concerns):

Each day, the coaching team met for a daily stand-up around this board. Our goal was to put our little avatars on the boards to show what we were working on, and move the stories (on post-its) to “done” when we had finished. After a couple of weeks, we realised – we weren’t actually using the board.

“The problem is,” Andy said, “half the things that we’re doing aren’t the kind of things we can move to ‘done’. They’re ongoing.”

“Right,” I agreed, “and half of them aren’t even on this board. There’s all kinds of things we’re doing with respect to the competition, coaching individuals, writing workshops, etc., and they’re not even up here. I wonder what we can do differently?”

At the time, I was hearing a lot of buzz around the word “Kanban”, and reading the Poppendieck’s “Lean Software Development”. It occurred to me that we might be able to use it to help us manage our coaching efforts.

So, I drew up a new board, and talked to our head coach, Chris, about it. “I’ve realised that I can cope with about three concerns at a time,” I said. “If you try to get me to worry about a fourth, I’ll promise to do it, and then something else will drop off the radar. It doesn’t matter how much I promise to do four things, realistically I’ll only get three done well at any time. So, I’m going to limit myself to 3.” I talked to the other coaches, and we found our own limits: 3 for each of the other coaches, and 1 for our part-time coach, Antony. So here’s what our new board looked like:

“Why, Helen!” I exclaimed, grinning. “You’ve got a space there.” I took a new post-it and wrote, “GIVE ME WORK!” on it, then stuck it in Helen’s space.

“What? No!” Helen exclaimed. “I can’t possibly take on any more work!”

“Well, either your limit is wrong – it’s OK to only manage two things – or there’s something you’re working on that’s not up there. Team C’s quite big; is that taking up about twice as much time as normal?”

“Not really,” Helen said thoughtfully. “There’s something else I’m working on. Let me think a moment… Ah! Of course, I’m also running the Agile induction course.” She wrote a post-it to replace mine.

“That’s great,” Chris said. “Now I can see what you’re working on, and also what you’re not working on.” We had a chat about some of the items in our backlog, and talked about when we might be able to bring them into play.

The board was much more effective, helping us juggle our workload appropriately, until it came close to the time for me to leave. Suddenly, I found I had more work than I could possibly manage.

So I cornered Chris. “You know how I said if I ended up doing four things, something would drop off the radar?” I asked.

“Yes…”

“Well, turns out it’s my lunch-hour. I’m exhausted; this isn’t sustainable. Can we sort something out?”

“Of course!” Chris said. So we got the coaches around the board to look at what we were all working on.

Chris looked at the various teams, competitions, workshops, technological strategies and other coaching concerns. “I don’t really care too much about these,” he said, removing about ten items from our (overly large) backlog. “And we don’t need to worry about Team B any more – I think they’ve got it. I’d really like you to run the other coaching workshops before you leave though, Liz.”

“Right,” I said, “then someone else needs to take over the TDD training.”

“I can’t,” Helen said, “I’m not technical. I’ve just finished the last Agile induction course, though, so I’ve got space to pick something else up. Andy’s been facilitating the retros; why don’t I take that instead, and then Andy could do the TDD training?”

“That works,” Andy replied. We swapped stories accordingly, moving them into their new places.

“Fantastic,” I smiled. “Anyone fancy some lunch?”

Having the visual aid helped us prioritise our efforts, as well as letting us share and organise our concerns. The most important aspect of this, for me, was the realistic recognition of our limits, which allowed Chris to direct our focus much more effectively. The Kanban board was just a tool for us, not a process or methodology in its own right. Nor did it replace conversation. It just facilitated it, and acted as a visual radiator. I found it useful, and I hope you enjoyed reading about it.