Visual Controls are in
One of the great ideas Agile has incorporated from Lean is the use of Visual Control.
- Release burndown charts tell me if we’re going to deliver on our promises. If we’re significantly behind the plan, we can take action: update the plan or take action to come back to plan. If we’re significantly ahead of plan we can update the plan, by adding more value to the release or by releasing earlier.
- Kanban boards tell me what’s happening with each of the stories in the iteration. If there are too many stories in any column that might be a sign of a bottleneck ahead or we might be starting too many stories. If there aren’t enough stories in a column that might indicate a bottleneck in front or we might not be focusing on the right type of work.
- Different type of items tell me at a glance what’s happening. If there are many red issue/impediment/bug cards on the board, they’ll stand out like a sore thumb. We can “stop the line” and investigate why there are so many blockers.
- Different card colours for different types of features or customers might tell us if our feature mix is good. In one case, a lot of different colours might indicate that we’re not focused. In another case, too many cards of the same colour might mean we’re not giving enough attention to other types of customers.
It’s always fun to walk into a team space, look at the visualisations and ask questions. The most important question is “WHY?” Why do you update this graph? Why do you track these cards? Why is that column there? Why do you put red Post-it’s in that box? Why is there a green dot on this card? “Because the coach or the book told us to do it” is not an acceptable answer.
Why do you visualise these things?
The goal is to take action
This picture shows about half of the information that this team visualises. This team knows what each of the columns means and what it means to move a story or task to another column. They know what to do when one of the columns gets too full. They know what to do when columns are empty. They know that red Post-its are dealt with differently than yellow Post-its. They know who should deal with impediments and questions (the red Post-its on the left) in each of the three impediment boxes (technical issues, business/feature issues, project issues).
They know that a story or task needs to be peer-reviewed before it can move in the “To Validate” column. If the review isn’t satisfactory, the card moves back to the “To Do” column. They know that the stakeholders in the context diagram need to be notified and consulted when something happens to the processes they participate in.
- A visualisation provides the up-to-date information to trigger actions
- These actions are defined upfront
- The whole team knows and agrees with the actions
A visualisation without actions is just a pretty picture.
Stop visualising if you can’t or won’t take action
I walked into a team room and saw that there were five burndown charts, one for each project the team was working on. One of the burndowns indicated that, if things continued to go as they had, this project was going to be released as planned. The four other burndowns indicated that these projects wouldn’t deliver as planned: the rate of descent was too low or they had levelled off (or ‘flatlined’): no progress was being made. I asked the team what they were going to do about those four projects.
Team: What do you mean?
Coach: Well, are you going to inform the customers or account managers of those four projects to tell them their project won’t be delivered as planned? Are you going to negotiate a new release date? Are you going to re-negotiate the scope of these projects if they have a fixed deadline? Can you drop or put some of these projects on hold so that you can stop context-switching and focus on one or a few projects? Are you going to look at the reasons for not delivering as planned? Are you going to see why you accepted more work than you could deliver?
Team: No. We’ll just continue working on the one big, important project and we’ll see what happens with the four others.
Coach: Then I’d advise you to stop updating those burndown charts, you’re just wasting time. You could even stop estimating those projects, because they seem to be of the “it’ll be ready when it’s ready” type.
If you’re not going to do anything with the information provided by your visualisation you might as well stop updating those visualisations.You’re just wasting your time. You’re obscuring the information that is used to trigger action.
If you’ve created a visualisation to take action to solve a problem and to verify if the problem is solved, you might take the visualisation down once the problem is completely solved. For example, you need to visualise the state and performance of a bottleneck while you’re dealing with it. Once the performance of the bottleneck has improved so much that the constraint moves somewhere else, you can stop monitoring. You now need to find a way to visualise the new bottleneck.
You need to refactor your visualisations. That’s why I like low-fidelity and easy to change visualisations. I think Xavier’s kanban boards are beautiful, clear and neat, but I prefer to use a whiteboard as a kanban board, so that we can quickly erase and redraw columns, rows and boxes. And I prefer to put up (story) cards with magnets, rather than stick up task Post-its.
Visualise to show the need for action
A manager came up to me with a worried look on his face.
Manager: That chart over there, is that project XYZ release 6.3?
Coach: Yes, that’s the burndown chart for project XYZ release 6.3.
Manager: Why hasn’t there been any progress in the past three iterations? This way we’re never going to be able to release by the end of the year!
Coach: The team has been waiting for a decision from you. They can’t mark any story as DONE until the acceptance criteria are agreed upon. Your decision affects about three quarters of all stories in this release. The team has tried to raise this impediment with you several times. See that red card on the board there? The lack of that decision is now the #1 risk for the project.
That same day the decision was taken.
Making the consequences of inaction visible can be a way to try and trigger some action, when everything else has been tried.
This is not information for the team, so it shouldn’t be in the team space. It should be where the people who need to take action, are. Some companies put their build status up on a monitor at the entrance where all employees and visitors see it. In this case, the burndown chart was in the corridor that led up to the executives’ offices. A coffee corner can also be a very effective information radiator.
This small internal IT team implemented small projects for about ten internal customers. The internal customers didn’t set overall priorities, they all thought their project had the highest priority. In some companies the customer who shouts loudest gets highest priority. In this company, the customer who shouted most recently got highest priority. As a result, the team trashed: frequent context-switches and priority changes made it impossible to get things done.
During one lunch break a team member bought some packs of multi-coloured index cards and magnets. The team wrote the customer requests on the cards and affixed them to the side of a big iron cupboard next to the coffee machine. Each customer got different coloured cards. The cards were ordered top to bottom in the order in which they had been received.
As the customers got their coffee, they asked about the colourful display. The team explained that this was all the work they had to do, displayed in the order in which they would do it.
Customer: Wow, that’s a lot of work! So, where are my projects?
Team: There, do you see that green card? And there, near the bottom, is another one.
Customer: But that project is very urgent!
Team: Then you’ll have to talk to the customers of the projects above yours.
For the first time, these customers saw why their “simple projects” took several months to deliver: they weren’t the only customer of the team. For the first time they realised that they would have to talk to the other customers to set priorities, because “if you let those programmers set priorities there was no knowing when your project would be ready”.
It’s not a very effective way of triggering actions: you’re essentially “sending signals” in the hope that someone will pick them up. But sometimes it’s your last hope. You can only try this fo a short while: teams won’t keep updating the visualisation if there’s no reaction.
What can I do?
Have a look at all the visualisations your team uses.
If your team has none, ask yourself:
- What is the one piece of information I would absolutely need to see to do my job well? Of what upcoming problem(s) do I need to be aware?
- How could you visualise this information by spending no more than five minutes per day and using nothing more complicated than paper, pens, Post-its, magnets, pieces of string and a whiteboard?
- What different actions can you take based on that visualisation? How do you know things are going well? What kinds of problems can you see? What action will you take for each kind of problem?
If your team has visualisations, ask yourself:
- What is the one visualisation I wouldn’t want to miss? Why?
- For each of the elements (each row, column, box, card colour, writing on the card, number of cards in a box/row/column…): what action do I intend to take based on it?
- Is there any way to simplify this? If there are elements that don’t lead to an action, could I take them away?
Now have this same conversation with your team and refactor your visualisations.
The laws of Visual Management
Just make sure that you obey the two laws of Visual Management:
Before you can take action you must make the problems and goals visible.
If you make something visible you must be prepared to take action based upon the information shown.
Where do you start?
I don’t know about your situation, but I’d start by defining the goal of your team and finding the bottleneck.
Solve conflicts without compromise
I’ll be hosting the “Solve conflicts without compromise” session at Agile Tour Besançon on October 6th, 2009. The session will be in French, so it’s called “Résolution des Conflits”.
In this tutorial participants learn to apply the “Evaporating Cloud” or “Conflict Resolution Diagram” on conflicts they bring to the session. We’re not going to bring about world peace or solve hunger. Not in 90 minutes, anyway. As it’s an Agile conference, the conflicts will be about bringing about change in teams and companies.
This session will also be run at XP Days Benelux on November 23-24. More about that later.
If people are interested, I can run this session at the Open Space of Scandinavian Agile on November 16th.
If you want to know more about the Theory of Constraints’ “Thinking Processes”, have a look at these books. I recommend “The Logical Thinking Process” by William H. Dettmer. It’s not a thin or light book, but the techniques are clearly explained and demonstrated.
Or you could come to one these sessions and solve a conflict.
A call to the support desk
I recently bought an extra service from a service provider who shall remain nameless. I logged into their online account management system, selected the options I wanted, clicked CONFIRM and was promised same-day activation of the options. I got an email confirming that everything I requested had been done. It should work now, but it didn’t.
By the end of the day, the features still didn’t work. The next day, still nothing. Checked the online system: the options were listed as ‘Enabled’, but still they didn’t work.
I called the company’s toll-free support desk. After navigating through three levels of menus of the automated call system, I got through to a human being. I explained the problem. The support technician asked a few questions and had a look in the affected system. The problem was clear: “Despite the fact that their system says the feature is enabled, they haven’t actually enabled it. I’ll send a request so that they enable the option. That usually only takes a few minutes, maximum one hour.”
A short while later everything worked as it should. And everybody lived happily ever after. Except…
There’s something wrong here…
The call to the support desk had been fast and efficient. The problem was solved. Why did I feel I had missed something?
I took a while to find the cause of my uneasy feeling: the support technician used the word “they”.
I thought I was calling the service provider. It turns out I was calling an independent support desk who weren’t a part of the company (or who felt that they weren’t part of the company). For them, the work was done the moment the call ended. If the support desk has decent incentives in place, this technician got rewarded for efficiently solving a customer problem.
As a customer (and if I were a manager at the company) I would like to see this call as the start of the work.
Why did I make this call? Because the online account management system says it enables features, but doesn’t actually enable them. Why? I don’t know, but I’d like to know. Does it do this consistently? If yes, that’s going to lead to a lot of support calls. The statement “…that usually only takes a few minutes…” indicates that I wasn’t the first customer to call with this type of problem.
Actually, the online account management system does do something right: if you enable the feature, you will get billed for it. Billing for a service you don’t deliver makes customers unhappy. How often does this happen? How many complaints do we get about that? How many customers have we lost because of that?
I doubt any of those questions get asked. The phone’s ringing again. Here comes another complaining customer. No time to waste, we have to hit the the helpdesk KPI targets!
Companies spend a lot of money on salespeople, because they are the “face” of the company and they bring in the money. Support personnel is as much the face of the company and they have to represent the company when the going gets tough: when the customer has a problem or is unhappy. That’s when you get to see the “real” company. That’s when the company gets great information about unclear features, about what customers really need and about problems with their processes.
Support people are the mouth and ears of your company. They should be trained and rewarded accordingly. They can be the brains of your company, but only if you give them the time and means to find the root causes of problems. And then only if you have the courage to tackle those root causes. But helpdesks are seen as a cost center: “we want to get rid of that complaining customer as fast as possible, for the lowest possible cost.”
Well, providing poor support is a good way to get rid of customers. That certainly lowers the cost of the helpdesk. But then you have to pay more for salespeople, to attract new customers.
You wouldn’t outsource your ears, mouth or brains, would you? Why would you outsource support?
What can you do today?
- Make sure you thank everybody who brings bad news. Thank you for calling in with your complaint! Thank you for finding this bug in my code!
- Perform root cause analysis on each and every bug report, customer complaint or support incident. Implement Poka-Yoke in your development team or implement ITIL Problem Management in your operations team. I know you think you don’t have enough resources to do this for every case, I’m a bit extreme in these things. The goal is to eliminate the need for a helpdesk and to make all our customers into salespeople by providing an insanely great service or product.
- Involve support people in root cause analysis and finding solutions, not workarounds! They know the product inside out, they know the customer and are born/trained problem solvers.
- Let support personnel create high priority, high value requirements for the product because they know what it takes to retain, satisfy and delight customers.
- Involve the support team in defining the product/service from the start to create supportable products.
- Provide time, training, tools and techniques to perform root cause analysis for everybody in the company.
- Reward appropriately. Reward for customer satisfaction, customer retention, problems avoided, quality increased.
What have I learned today? Be wary of that company and their online tools. They seem more interested in billing me than in providing a service. And I doubt it will get better, because they don’t seem to learn.
Photo by scottfeldstein
XP Days Benelux 2009 program
The first version of the XP Days Benelux 2009 program has just been published. It looks great, with a good mix of subjects, formats and aimed at participants with different levels of experience.
Over the next few days we’ll make this program even stronger by adding a few more sessions. The only problem is that we still have more strong session proposals than available slots. More difficult choices ahead…
Register now to benefit from the early registration discount.
XP Days Benelux, 23-24 November in Mechelen, Belgium
It’s time to start planning for the fall and winter conference season. As an organiser, the 7th XP Days Benelux is top of my list.
We’re finalising what looks like a great program with several sessions I want to go to in each time slot. With five tracks covering all things agile, there should be ample choice for you and our conference personas too.
We can’t show you the program yet, but you can register for the conference. Who would register for a conference without knowing what’s on the program? Lots of people it seems, as registrations are coming in steadily.
Now, that’s T-R-U-S-T, one of the essential Agile Values.
Bram goes to every XP Days Benelux
Innovation and constraints
How did we come up with the idea of registering before announcing the program? By accident.
- Participant: “Can I get a conference ticket now? I’ll be abroad the next few weeks and I want to be sure to get in.”
- Organisers: “But, don’t you want to see the program first, before deciding?”
- Participant: “No, I’ve been to last year’s conference. I trust you’ll have a great program this year too.”
There was nothing holding us back from selling tickets before announcing the program. We only had this self-imposed constraint: “participants want to see the program before deciding to participate”. It turns out that this isn’t a real constraint after all. Part of innovation is letting go of those self-imposed constraints. Another part is dealing with real constraints.
How many of those self-imposed constraints do you have in your work or your life? How many times have you said “I didn’t know we could do that!” ? How often do you ask yourself “What would happen if we tried this?”
That’s why I like organising XP Days Benelux: there are always people coming up with crazy ideas, trying something new and improving it. Sometimes it works, sometimes it doesn’t. We always try to learn. We always try to question. We don’t always succeed, but at least we try.
Try this at home
Note how often you hear this:
- That’ll never work!
- They won’t let us do that!
- That will never happen here!
- Yes, but…
- There’s no budget for that!
- That’s just silly!
- or any other Idea Killer
Now, take one of these instances and instead of shooting the idea down, start looking at the hidden self-imposed constraints:
- It’ll never work? In what circumstances would it work?
- They won’t let us do that? Why? Have we asked?
- That will never happen here! Where would it work? What would it take to transform here into a place where it works?
- Yes, but…? Yes, and…!
- There’s no budget for that! What small part of this could we do for free? How much value could we create? Could we use that value to fund the next small step?
- That’s just silly! Less silly than what we do today 🙂
It just takes a bit of courage. Try something, one small step. Collaborate with people who can help you. Get regular feedback to improve. Instead of “doing agile” (or worse, trying to get others to “do agile”), be agile.
You are an innovator. You are creative. It’s as simple as that.
Come to XP Days Benelux to see what crazy stuff we’ve cooked up this year. If some people get their way, it might involve dancing, martial arts, art and philantropy. Now, that’s just plain silly! Don’t say I didn’t warn you!
Persona created with Janina Köppel’s South Park Studio