|
|
 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.
Manager: Oh.
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.
  
Agile 2009, Chicago 24-28/08/2009
 Next week Portia and I will present two sessions at Agile 2009 in Chicago. And we’ll be attending lots of other agile sessions, if we manage to choose from the massive program.
Besides that I hope to meet agilists from all over the world, see a bit of Chicago and finally see Edward Hopper‘s “Nighthawks“. Incidentally, I discovered Nighthawks after listening to Tom Waits’ “Nighthawks at the Diner“. I wanted to find out more about the inspiration for the album. Tom’s diner is warm and cosy, filled with misfits with tall tales; Hopper’s diner feels as cold as outside and is filled with people who don’t have anything more to say or a place they want to go to.
Both Hopper and Waits are worth checking out if you want to know more about Americana.
I’m not a Bottleneck! I’m a Free Man!
In this game we apply theTheory of Constraints’ “Five Focusing Steps” to improve a simple simulation process. Step by step, we apply Agile, Lean and Real Options techniques to improve the work and its results.
Portia describes some Bottleneck Games we played recently. The techniques we present are really simple and broadly applicable, not just in manufacturing, where the techniques were developed, or in IT organisations, where we apply them most of the time.
After this session you can use the game materials to teach these concepts in your company. After this session you will be able to apply the techniques in your company. After the session, you will see bottlenecks and opportunities for improvement everywhere. You will look at the world differently.
The number of participants is limited to 60, so come to the session on Wednesday 26th of August at 9:00 sharp.
The Business Value Game
The Business Value Game pits 6 teams against each other to achieve the highest possible income by planning effectively. Each team has a limited development capacity and several customers who want their project implemented NOW. By creating a “Business Value Model”, an agreement on the way to value projects, teams can optimise their income without much time. Portfolio and program management doesn’t have to be complex if you’re value-driven.
After this session you can use the game materials to teach these concepts in your company. After this session you will be able to apply the techniques in your company. After this session, you will look at “business value” and project prioritisation differently.
The number of participants is limited to about 50, so come to the session on Wednesday 26th of August at 16:00 sharp.
Ask for help: will you help lead the Business Value Game?
The teams in the game need coaching from someone who’s familiar with the game and its concepts. If you’ve led or played the Business Value Game before and want to help us run the game, contact us.
See you in Chicago!
Takt time
Takt time is the rate at which customers buy a product. Takt time determines the speed at which a Lean manufacturing runs. For example, say we sell 576 units of product A. If we have a 8 hour shift, we need to make 72 units per hour, or 1.2 units per minute. We have 50 seconds per unit.
Every step in the production process must now deliver their contribution to the product in 50 seconds.
What if there’s a step that can’t deliver in 50 seconds? Then we have a bottleneck. We’ll produce and sell less than we could. We apply the 5 focusing steps to increase the bottleneck’s capacity so that they can deliver in 50 seconds or less.
What if there’s a step that can deliver in less than 50 seconds? They still deliver every 50 seconds, even if they have to slow down. If they delivered more frequently, we’d build up lots of work in process as other steps can’t use its output faster than once every 50 seconds. Or we might build unsold goods.
Slowing down? Isn’t that inefficient? Yes, but we’re not optimising the efficiency of a single step. We’re optimising the whole value stream. If a step has a lot of spare capacity, this could be used to work on another product, but only if it doesn’t endanger the delivery of the first product.
Using Visual Management, the value stream tracks actual production rate regularly. The steps won’t run perfectly as clockwork, there will always be some variation. The production rate displays allow everybody to react (speed up, slow down a bit) to keep to the takt time. The takt time works as a metronome that synchronizes musicians.
Takt time isn’t (always) the drum beat
In Theory of Constraints, the Drum-Buffer-Rope system synchronizes the speed at which each step in production runs. The “Drum Beat” is the rhythm, the steady pace at which the slowest step (the bottleneck) runs. The rest of the system works to that beat. Again, no use producing faster than the bottleneck because we’ll only create more work in process.
The two concepts are quite similar and I sometimes confuse them. There’s one clear difference:
- takt time is customer-focused, outward looking
- drum beat is bottleneck focused, inward looking
If the customer is the constraint, a base (if not outspoken) premise of Lean, takt time equals the drum beat and drum-buffer-rope implements customer pull.
Takt time in software development
What is the equivalent of takt time in software development? If you’re Microsoft, you know approximately how many copies of Microsoft Office are bought every day. You could run your disk duplication and packaging plant at this takt time. But that’s not what I want to talk about.
Takt time = the rate at which you release a new product (version) to users
How often do you put new, valuable features in the hands of your users? Every day? Every week? Every month? Every quarter? Every year?
The logic of slow takt times or how to kill all your Agile teams with one simple decision
Most teams I work with, including Agile teams, have long release cycles. Long by my standards. Some of this is under control of the development team, but the release cycle is often dictated by other concerns. Often, operational teams (systems engineers, DBAs, support) reduce the number of releases.
Operational teams are often stressed, in fire-fighting mode and jerked around as projects miss deadlines and make last-minute changes. To reduce the load and ease the pressure, they reduce the number of releases. Fewer releases means more complex and error-prone releases, as more features are batched up in one release. These releases require more effort and have more issues. Fixing and patching those issues requires more work. Business people, under pressure to generate more value faster push harder to get features out of the door. Corners get cut, features get released under the guise of fixes. More work. The logical reaction is to reduce the number of releases again. Which makes the problem even worse. And so on.
Reducing the number of releases, increasing the overhead of releasing is the perfect way to demoralise and ultimately kill any Agile team. Why should we define short iterations and releases, if it takes so long to get something in production? Why should we collaborate tightly with customers if the software is outdated by the time it gets into the hands of users? Why should we focus on business value if potentially valuable features gather dust in an endless release process? We might as well switch to waterfall.
It doesn’t have to be this way. The first step is to regain the trust of the operational teams: release on time, deliver great quality code, involve operational teams in planning and retrospectives, treat members of operational teams (who are often involved in many projects) as members of your team: listen to them and optimise the whole value stream.
Once we’ve established trust and created one team, we can start to talk about improving and going faster.
Operational Excellence AND Customer Intimacy, but not at once
In the previous blog entry, we saw how one company resolved the conflict between operational excellence and customer intimacy. They found a way to have both. But we didn’t implement both at the same time.
We first went for Operational Excellence. First we standardised, made things reliable, made work repeatable, not only in production but also in IT. The existing product definitions were inconsistent and complex. This made our code complex because we had to treat every product as a special case. Over a period of about one year all the product definitions and the code were refactored to new standardised forms. All of this happened while the system was in production and new features were released every two months. We got very good at refactoring and migrating without disrupting because we did it so often, in small steps.
A similar ‘refactoring’ happened on the production floor. Product line by product line was tackled: work cells clearly labeled, clear flow lines from input to output established, work in process limited… When I first went to see the production floor I nearly got lost between the piles of work in process and it was hard to see what was going on. After the changes, the area looked a lot more spacious and it was clear at a glance what was going on.
Once we had the production and development system under control, we started to think about customisation and getting more intimate with our customers.
Effectiveness AND Alignment, but not at once
This reminded of Alan Kelly’s blog entry about the “Alignment Trap“. In summary: we want our IT organisations to be effective (do things right) and aligned with business objectives (do the right things). Unfortunately, most organisations do neither.
If we want an organisation that does the right things and does them right, what strategy should we follow? Based on a study, Alan conjectures that it’s best to focus on effectiveness first, alignment second. First learn to do things right, then do the right things.
Managed and Agile, but not at once
I encounter a similar situation in many coaching and consulting engagements. Organisations want IT teams that are reliable, predictable and can be trusted to deliver as promised. And they also want them to be agile, deliver faster and respond to change. Lean and Agile can get you there.
What’s the first step? Usually, we need to bring things under control, clear away the clutter, reduce chaos, limit task switching, limit work in process and make things visible. This often involves “anti-agile” or “anti-lean” measures such as batching support, analysis and design work to avoid task switching and installing strict change management and issue prioritising to keep focus. I always get lots of complaints and get accused of “not being agile” from people who are used to the chaos and suddenly find that the team no longer asks “How High?” when they yell “JUMP!” Those who stop jumping find that they get a lot more done and that the results are better. They are less stressed.
Once we have the process under control, we can start improving the flow.We know how to do things, we can start to go a bit faster, in smaller steps; we can disrupt the stability to improve a bit. And then we find a new stability and so on.
Heijunka
Heijunka is one of the often forgotten Toyota Way principles. It means “levelling the load”, working at a steady, regular, sustained and sustainable pace. It means planning the work so that there’s a good balance between flow and the load on people and machines.
Large companies who impose just-in-time deliveries to their suppliers without levelling their orders abuse their suppliers. Teams who randomly request clarifications for stories burn out their Product Owner. Teams who push out releases faster than their customers and users can accept them throw away value.
Heijunka means making and keeping work humane.
Which small step can you take to make your work more humane?
|
|
