About 6 month's back we [Microsoft Visual Studio Team System] hosted a meeting of our customer advisory council. This is a hand picked group of people who help to steer our product. They all know who they are, so I don't need to name names. Many of them read this column regularly. Back then I was soliciting input for our "formal" methodology. During this session, one of our advisors urged me to avoid giving "us yet another quality initiative. We've tried them all and people are tired!"

And so, I'm sure he'll be delighted to hear me say, "Quality initiatives! Just say no!"

The problem with quality initiatives, and their champions, and their change agents, and their sponsors, and their improvement projects and their quality teams and process experts and black belts and green belts and funny handshakes and secret rituals and coded handbooks and group hugs and therapy sessions is quite simply that the improvements don't last. When the black belt goes home, and everyone breathes out, the regular work force go back to their same old behavior.

QUALITY IS EVERYONE'S BUSINESS!
CONTINUOUS IMPROVEMENT IS EVERYONE'S BUSINESS!

Plain and simple - quality and continuous improvement are everyone's business. It's an everyday thing for every employee. Everyone should understand variation and specifically understand how to measure and interpret the variation in their inputs, their rate of input, their working method, their lead time and their rate of output. Eliminating special cause variation should be everyone's business, every day. Reducing common cause variation should be everyone's business every day. Suggestions for improvement could come from anyone, any time and be implemented by a local consensus on the shop floor. No need for a central process improvement group or sanction from an ivory tower full of process priestesses.

That's why in MSF for CMMI(R) Process Improvement, I've included daily standup meetings to surface issues and monitor and manage risks, eliminate special cause variation and make it everyone's business to do so. That's why we're dropping conformance to plan and conformance to specification in favor of conformance to process and focus on variation reduction. That's why we're encouraging a bottom up, empowered team, consensus model. That allows decentralized decisions to be made quickly. The way to institutionalize continuous improvement across an organization is to make it everyone's business, every day! The way to deliver an agile process which meets both the original spirit of the software CMM and the letter of the CMMI(R) appraisal model, is to distribute the quality responsibility at grass roots level across the whole organization. Everybody, every day allows quality and agility to walk hand in hand.

The hot topic on the internal British ex-patriot mailing list at Microsoft this week has been this article [subscription required] by Rupert Steiner (a guid Scots name, Ed.) which appeared in the most recent edition of the Scotland on Sunday newspaper. Why the commotion in the belly of the beast? Well to quote one colleague (and you have to read this in your best Dundonian accent) "It's tripe!" A partake of a good plate of tripe without the cognitive friction of completing the registration and remembering yet another password, here is a convenient link to a PDF of same article courtesy of Media Report.

According to the The Economist and Business Week [who mysteriously coordinate their editorial efforts once again this week], we bloggers leach off the old media. I, therefore, bring you this in the interests of balanced and accurate journalism or is it just my inner leach coming out?

Mr. Steiner visited the campus in February covering another story. His editor asked him to "cover the trip" by getting a second one, so he interviewed a few Scottish emigrants who ply their trade in Redmond. [I can't help feeling this is a cost accounting nonsense surfacing - a cost per story metric measuring efficiency of story gathering, whilst a high brow paper such as the broadsheet SoS might be better to focus on quality and effectiveness]. Microscots! Huh? We'd never heard of the term until this Sunday. Trips to Vancouver, BC, to buy vegetarian Haggis - we believe that Mr. Steiner made this up as no one will admit to telling him this. And Irn-Bru isn't banned. The manufacturer A.G. Barr now exports a modified version which meets American regulations. I'll need to be careful driving over that wriggling SR-520 pontoon bridge on my way to work. I guess the straight due East-West design was getting boring. And then there is "Lake Bill". Huh? I guess that is where the ducks like the stock options my colleagues contemplate are indeed underwater. And I could go on and on... The whole article is full of errors. Poor Paul Booth who was misquoted in the article had to be taken for pint of ale to mist over his misery.

It seems that Rupert Steiner wanted to write a story about rich kids with yachts, sea-planes and trophy wives but discovered that life at Microsoft is pretty mundane for most of us. We all have mortgages, kids to put through college and pension plans. There was a story in there waiting to get out. The story of why the Scots who work over here wouldn't be keen to go back. It's not a new story. It's a 200 year old story with a new digital twist - Scottish talent leaving home and making good in lands overseas. However, Mr. Steiner didn't want to search for the real story, instead he wanted to corroborate the story on which he'd set his mind. In the end, he just made it up. Cheap column inches!

My feedback to the editor of SoS - two words - "Fact Checker"!

[Anyohyews fur a wee bit oh tartan trim oan this here website when ah redesign mae banner? G'on geez'a comment...]

Part 2 of my reply to Dan Vacanti: following yesterday's post about gardeners, today I discuss those who simply won't do the job, those with a posture or attitude that makes them dysfunctional on the team.

It's easy to argue that the attitudinal is responsible for his own performance. He can choose to change his attitude and start to perform. Were this to happen his performance may well come up to or exceed that of the average team member. As a team, we'd certainly be able to factor his performance into our estimates. We could take him off the bench.

Team members with an attitude problem are usually not difficult to spot. They simply don't behave according to established team norms. For example, their attendance at the morning meeting is sporadic and when they do attend, they don't act like a functional team member. The body language (and sometimes the spoken language is all wrong). [Now it is true that there can be the fifth columnist who hides their dysfunction and let it manifest itself as poor quality code or very slow code production. This is harder to spot and requires intelligence from the grapevine - best gathered through the managing by taking coffee or managing by having lunch approach].

So, once again its the managers responsibility. The manager has to talk to the individual with the attitude. Make it plain to them why they need to change and that the manager will not tolerate it or bend the rules. There can be no exceptions. It's like parenting.

I've seen all sorts of attitudes. The most common perhaps is the "I'm God's gift to software engineering" often coupled to the complaint that "the team doesn't give me any of the cool stuff to work on". The advice: try doing the mundane stuff and doing a good job of it and earning the trust and respect of your peers. If you do the mundane stuff well and they learn to trust you then they will realize that you can help them to be successful and you will be given the harder, sexier tasks.

The second job is once again to take the attitudinal out of the estimate. Don't have the rest of the team carrying the burden. Treat them as bench slack or give them individual tasks to perform that are off the critical path of the deliverable. This has a side-effect. The attitudinal is isolated from the team and can never be integrated.

By maintaining a firm stance on expected norms, the attitudinal will either (a) change his attitude, earn the trust and respect of other team members and re-integrate as a functional team player, or (b) self-select out of the organization.

So, to Dan's point, I believe that the individual is responsible for their professionalism and their discipline, for their attitude towards their job, the business and their fellow team members. They can choose to work functionally with the team or they can strike a pose and behave like a spoiled toddler. But when it comes to writing code, they aren't responsible for their performance. That will always vary according to the techniques employed. Improving the techniques, reducing the variation and increasing the mid-point (or mean) productivity is the responsibility of the whole team and the manager. The team member simply has to agree to be a part of the learning organization. To strive to be professional and to show a willingness to learn.

I'm separating out productivity from dysfunction. When as managers, we couple the two together, we expect miracles. We expect that somehow magic will happen and the team will learn to use new techniques and become more productive with lower variation in productivity. But this can never happen on its own. The team will never take a risk to change because of the J-curve effect and general fear of change and feeling of insecurity whilst adopting new techniques. It needs the manager to give permission to change. To provide coaching and encouragement. To create a space and to provide air cover whilst the team works through the J-curve. By learning to treat dysfunction as a separate management problem, we free ourselves to focus on better productivity.

So Dan has challenged me, following Friday's post, to explain what to do about underperformers. [I had to edit Dan's comment because it got a little close to a real HR issue from a few years ago. I purposefully didn't reply to it directly either.]

I think there are two types of under performers - those who simply can't do the job, and those who won't do the job. I'd like to deal with the first type in this post.

"There are a lot of gardeners in IT"

Jeff De Luca uses this expression a lot. It dates from his years with IBM and a time during the grim dark years under John Akers, whilst the World economy was reeling from the 1987 stock market bust and the later property bubble, and IBM was laying off people left, right and center. Jeff in discussions with his boss at the time, had been reassured that "there was always work for good people" and that "there are a lot of gardeners in IT" and that they might soon be "mowing lawns around Melbourne" once again.

Dan will recall the time we interviewed a tree doctor for an $80 per hour contingent staffing position. His previous IT experience amounted to less than 3 years at a large wireless company as a contractor doing Java development, and several years in the Cascade mountains heeling sick trees. Following the interview, where he couldn't describe the difference between the == operator and the .equals() method, I advised his agent to advise him to go back to his true profession. In general, I try to avoid the gardener problem by not hiring them in the first place.

The employee who can't do the job is the responsibility of the manager. It is the manager's failing. The employee is still trying to do her best - even when it isn't nearly good enough.

As Dan rightly points out, a gardener on the team, can destroy morale. When you inherit a gardener from a previous manager, it creates a problem. You identify gardeners primarily from a "managing by walking about" strategy. For me this includes the sub-classes of "managing by having lunch", "managing by drinking coffee" and "managing by playing ping-pong or foosball". Many of my former staff will recognize these techniques. Step 2 in dealing with a gardener is to stop estimating based on their productivity. If the team has effectively benched the gardener then as a manager you can't count them as part of the productive team when estimating projects. By eliminating them from the estimate, you stop the team from carrying the burden through extra heroic effort. That just leaves the morale problem. The gardener has to be managed out. As anyone working in the USA's Fortune 500 knows, this is a tricky problem and it takes time - sometimes up to 18 months.

I've mentioned before that I like to measure individuals on secondary contributions. For example, "become the language lawyer on unit testing and test-driven development and transfer your new knowledge to the other team members. Build their respect as the authority on TDD and make yourself the go to point for advice on TDD and unit tests." Now that is something I can measure. A gardener will never be able to accomplish this task. Managing the gardener out is the responsibility of the manager. Coaching the team quietly and privately to be patient and to understand the difficulty of achieving this is how to deal with the morale problem.

In summary, the "can't do the job" employee is not responsible for their performance. The manager is responsible. The manager should never have hired them in the first place.

No I'm not swearing!

This is a serious post about the difference between management by objectives (or conformance to plan commitments) versus management of process variation. The management scientists will recognize this as the Peter Drucker versus Edwards Deming debate [Drucker and Deming actually roomed together at one point in the early 50's where this argument started. Drucker is said by Deming to have capitulated eventually.] Yet others may see this as a Crosby versus Deming debate. And in many ways the Crosby idea of measuring quality by conformance to spec, isn't so far removed from the Drucker idea of set a target, get a commitment from an accountable person and then hold their feet to the fire until they deliver.

Back in 2001, Mac Felsing and Ken Ritchie [both of Process Exchange] were working with me at Sprintpcs.com. Whilst I was managing a dev team amongst other duties, they were working for the newly appointed Senior Director of Engineering in his process improvement group. They were tasked with building adoption for FDD across the business unit. One day they set up a meeting with me, and when they arrived, they were filled with frustration. The boss had asked them to start measuring individual performance on feature commitments and report conformance against commitment.

[A brief sidebar. I've written before about my dislike for the "planned date" in the feature milestones in FDD. It's a topic about which Jeff De Luca and I disagree. I see it as management by inch pebble objectives and I don't like it. I prefer to measure feature completion velocity. At most I only ever ask for chief programmer work package completion milestones and then its a feature team commitment against a batch of work.]

I'm on record as being very anti individual measurement. The likelihood, that measuring individual feature milestone commitments and using them in performance reviews would blow an FDD team apart and destroy productivity and morale, is very high. It's a fundamental tenet of FDD that you never, ever, measure individuals. Heck, FDD doesn't even monitor individual tasks - only features constructed by a team. I had to save the senior director from his own ineptitude. So I suggested that they flip this metric on its head and take it back to him as a report on our ability to estimate and a measure of the variation between planned and actual. Over time, we should as a team and an organization be able to show that we are learning and that this learning manifests itself as reduced variation. Under no circumstances should we use this data to evaluate individuals performance.

[I also promised myself that I had to get out from under this new boss. Five months later I quit Sprint altogether.]

The executive request was for management by objectives (MBO) and conformance to plan or individuals would pay the consequences. [Management knew that layoffs were coming the following year and they wanted to identify the weaker players with objective data.] The alternative to MBO is management of process variation.

Lesson Learned. In MSF for CMMI(R) Process Improvement, I am taking a management by reducing variation approach. Commitments are based on ranges derived from measured variation. The standard metrics and reports show the process variation in productivity, velocity and quality. It is through these mechanism that we undo the heavyweight, document centric, trustless, fear driven process designs out of CMMI.

[To close out this post, Deming firmly believed that individuals were almost never responsible for their own performance but rather victims of the variation in the tasks that they had to perform. Only if the organization could learn to understand and reduce its variation would performance improve. Now there is a radical idea - programmers are not individually responsible for their own performance!]

The power of tooling to reduce variation is often overlooked. Together is tool that significantly reduces variation in software development when used correctly. Microsoft Visual Studio 2005 Team Architect is another one, though its 2005 features address different problems such as design of distributed systems and deployment across data centers. Nevertheless, there is a common theme - right first time! The automation in the tool reduces rework and provides validation of one rendering of the knowledge captured in the product against another rendering. The chance of source code incorrectly implementing a design when Together is used correctly is greatly reduced. This reduces defects. Reduced defects reduces rework. Reduced rework improves planning accuracy and improves productivity through greater productive use of capacity constrained resources.

But Together is even more powerful when correctly used with The Coad Method and the architectural ideas that come with Peter Coad's teachings. With The Coad Method, the domain analysis is kept is synch with the design and the source code. There is significant reduction in variation across a greater span of the lifecycle. With the resultant productivity gains. This is the paradigm shifting power of Together - a tool designed to implement The Coad Method. I've always been amazed at how lousy Togethersoft and more recently Borland have been at communicating that message. Perhaps the widespread adoption of J2EE and Enterprise Java Beans is what caused the problem. The J2EE simply got in the way of good Coad Method implementations. [I've got data that shows FDD teams practicing the Coad Method significantly outperform teams doing J2EE EJB's. The difference in architecture wasn't the only variable so these aren't scientific results but anecdotal, empirical data is good enough for me as a manager to know that I'd never recommend building a J2EE based application ever again.]

I am hoping that we can drive similar ideas into Team System and Team Architect with respect to Service Oriented Architecture. The end product would be a version of MSF which was optimized for SOA and prescribed analysis and modeling techniques, implemented with domain specific languages (DSL's) in Team Architect that significantly reduce variation throughout the lifecycle from requirements through to deployment. In other words, it would be nice if we could learn the lessons from Coad and FDD and apply them in a 21st Century SOA context.

Returning to yesterday's post, there also exists tooling to drive variation out of user interface design and development. My old friend Brían O'Byrne founded Statesoft to solve this problem. His tool implements Ian Horrock's method of using Statecharts for modeling the interaction design - an equivalent to the Visual Vocabulary technique I described yesterday but more rigorous, more directly mapped to the source code. Brían and I first developed this technique as a framework when we worked together in Ireland in 1999. His latest tool works for Java and .Net and allows you to draw a Statechart model of a UI screen flow and then generate the View-Control code for either GUI or web deployment. It's a tool which reduces the variation from the designers vision to the implemented working code. [And it was developed using FDD.] The domain specific extensions that we made to Statecharts to handle exceptions and transactions also greatly reduce the possibility of defects in error handling code. Once again, tight coupling of analysis, design and code reduces defects. Reduced defects reduces rework. Reduced rework improves planning accuracy.

If your constraint, today, right now in 2005, on .Net software development, is coding productivity, then you simply have to look seriously at tools like Together and View Control as additions to Visual Studio and consider training your people in how to use them properly - model-driven design!-Analysis, design and code always in synch significantly reduces the opportunities for defects and the actual numbers of defects. Drive variation out of your software development lifecycle!

[In the interests of balance, if anyone else is producing tools which they can demonstrate significantly reduce variation across the lifecycle in a similar fashion please comment]

So back when I proposed a multi-project Critical Chain solution for software engineering, I wrote a paper - based on real experience - that a good shared resource to select as the synchronizing drum would be the user experience (or interface design) group. This met the first criteria for a good drum resource. It was close to the front end of the system and therefore the rope (back to the start) would be short. [For those not deeply familiar with Critical Chain, the synchronizing resource is actually operated using the Theory of Constraints Drum-Buffer-Rope solution commonly associated with manufacturing plants].

The second criteria for a good drum resource is that it have low variation. The reason for this is pretty obvious. If a drum synchronizer had high degrees of variation then there would be times when it wasn't the constraint and the unknown and unmanaged alternative constraint would throw the system into chaos. Equally, at times when the drum was severely under performing due to wide variation, it would mean very low productivity from the whole system. Everything would be dragged down by the wide variation in the constraint.

So it was argued, the user experience group with its artsy types would not be a good choice because artists are too unreliable. Hmmm. That could be true? So, I was left with two choices, persuade the organization to invest the user experience group to relieve it of its bottleneck status or solve the problem. The answer was to introduce the use of Visual Vocabulary modeling as an analog to the domain modeling in FDD. The VV model is used to identify all the work items for the design team. For each box on the model, the team has to design a screen or web page. We then measured the design effort typically associated with this and it exhibited remarkable low variation.

So, that just leaves the modeling effort itself, which is also conducted by the same capacity constrained user experience designer resources. This has the ability to eat into their time for designing and hence is a variable of variation. The way to drive variation out of modeling is to strictly time box it, for example, one week per quarter, or no more than 7% of an iteration's calendar time. We had remarkable success with this technique. The theory was pretty closely reflected in the operational reality.

So as a general rule, organize a process to put the bottleneck close to the beginning - this requires investment elsewhere to provide slack capacity - then optimize the chosen drum resource and reduce its variation through the introduction of better analysis techniques.

My friends at Borland just released Together for Visual Studio .Net. This is fantastic news. It means that IT shops across the globe can now easily practice Feature Driven Development for .Net applications. Just add Together to Visual Studio and you can do Coad Method domain modeling in color and couple that to the FDD Tracker tool and you have a full blown knowledge management system for FDD. This setup would easily rival the tooling we had in Singapore - and we had a dedicated team of 5 people providing it, along with a site license for the Beta of Together. We started with version 0.4 ;-)

It never ceases to surprise me how few people actually understand the paradigm of a tool like Together. It's a tool which requires a team to change its behavior. It's not just a drawing tool. It's more than a typical modeling tool. It is a tool for reducing variation in software engineering. It keeps the design and the code in synch. It allows the design to drive the development. It is the original model-driven design tool.

So, following the previous two days posts about driving variation out of bottlenecks and the relationship between Deming and Goldratt's approaches, let us now consider an example from an FDD project. Let's imagine that the bottleneck is software development, i.e. design and build in FDD-speak.

Our goal is to maximize the throughput of FDD Features [Coad 95 & 97 - Object Models] and to do this we must maximize the rate of Feature completion. How could we maximize the rate of Feature completion? We must seek to reduce the time between completion of Chief Programmer Work Packages (batches of Features) and increase the average Features per day or week. There are several things we could do...

(1) Improved Feature Analysis

By getting better at The Coad Method, we can improve our ability to analyze Features. Properly analyzed Features exhibit lower variability and map better to the object model and the design of the code. With better mapping to code, there is lower variability in the size of Features and the time they take to design and build. This improves the predictability for the lead time in a chief programmer work package and allows the batch size to be set appropriately.

(2) Better Time Management

We can teach developers to better manage their time, or introduce rules to let them focus quality time on productive design and coding, such as "no email before noon". This will reduce the lead time for chief programmer work packages and increase productivity. Better time management will lead to more reliable effort expended and reduce variability of throughput.

(3) Single Project Tasking

We can insure that developers single-task on one project and preferrably on a single chief programmer work package within that project. This helps them to optimize time management and focus on minimizing lead time for that work package.

(4) Quality Assurance Measures

We can enforce design and code reviews and unit testing techniques. In fact, 100% coverage for reviews and unit tests is mandated in the FDD presecription. By reducing rework caused by poor initial quality, this reduces variation in throughput. In addition, the prescribed design techniques using Coad Method object modeling and UML sequence diagrams for each Feature design reduce the variability in design techniques and increase the reliability of the solution.

These first four pay the highest dividends as they directly address the main variable - rate of Feature production. It's no accident then that the Coad Method and its evolution Feature Driven Development focused on (1), (2) and (4) and that the SEI's PSP/TSP methods focus on (2), (3) and (4).

(5) Limiting Work-In-Process Inventory

We could use a Kanban-style system to limit the size of work-in-process, preventing new Features from being started without completion of others, even if those others are blocked with issues logged. Note, this would provide the equivalent of "pulling the chain" or "stopping the line" in a Lean/Toyota-style manufacturing line. The Kanban system would limit WIP and force quick root cause analysis and resolution of issues. Limiting WIP has been shown to be directly related to lead time. My own work published in several papers last year showed that I have empirically observed that Little's Law holds for software engineering.

The SEI has objective data that shows that lead time correlates to software quality - in terms of inserted defects. My empirical observation with FDD projects would reinforce this. Small batches with short lead times correlate to higher initial quality.

Hence, limiting WIP has a secondary effect on variation in the constraint - it reduces rework caused by poor initial quality. We can see from this that a Kanban system for software engineering has some value but is definitely secondary to improved techniques in requirements analysis, time management, initial quality assurance and pride-of-workmanship and dedicated single project resourcing. For this reason, introducing a Kanban-style system in Visual Studio Team System is not a priority for me.

OK! So how many readers spotted the relationship with yesterday's driving variation out of the constraint techniques and Goldratt's 2nd step in the 5 focusing steps of TOC - exploit the constraint? Yes, driving variation out of the throughput variable in the constraint is an exploitation technique. By reducing variation, we can guarantee that we get the maximum performance from the bottleneck resource.

Notice how I carefully selected the variable I was going to focus on. I could have chosen the speed of the vehicles or the vehicles-in-process inventory (the density of traffic) on the freeway, but instead I chose to focus on the distance between traffic and the rate of cars passing the bottleneck point at the entrance to the bridge - the takt time at the output of the bottleneck. By careful selection of the variable for variation reduction I can align the techniques of Deming and Six Sigma with the five focusing steps from Goldratt's Theory of Constraints. The flip side of this is that unfocused reduction of variation produces little productivity improvement. This is the main criticism of 6 Sigma leveled at it by the TOC community. This example shows that it doesn't have to be an either/or choice - you can do both!

I've been asked by email to publish some more material on driving variation out of the constraint. Specifically I was asked for software development and FDD examples but I'll get to those in a future post. First of all I'd like to look at one of Seattle's famous bottlenecks - the SR-520 freeway bridge across Lake Washington linking Seattle with its "east-side" suburbs of Bellevue, Kirkland and Redmond.

Anyone who works at Microsoft's Redmond campus and lives in the city of Seattle commutes across the lake on the SR-520. Equally suburban dwellers from the north east-side take it in the opposite direction to commute to Seattle. On an evening when there is a baseball game or a basketball game in the city, it can be jammed for 6 miles from the lake back to the Redmond campus. It's a notorious bottleneck every day morning or evening. So how would we drive variation out of this bottleneck?

The throughput of the SR-520 has a maximum of 60 cars per minute. That number is limited by the takt time (the time difference between moving cars) of 2 seconds. There are 2 lanes. So the maximum throughput is 30 cars per lane per minute. The 2 seconds comes from a well buffered "thinking time" for braking. It's the minimum safe time between vehicles. Empirical study of traffic has shown that maximum throughput is usually achieved at about 40 miles per hour. Faster speeds add extra variation to the system because not everyone can react fast enough and the result is that at faster speeds, a longer takt time between vehicles or greater variation in the gaps occurs. Below 40 miles per hour, maintaining a 2 second gap is difficult because the forward velocity is so slow. Below 20 miles per hour, it becomes impossible.

It's worth observing that takt time controls throughput and not velocity! Velocity affects lead time. At 40 miles per hour, the 4 miles of the narrowest part of the SR-520 on the east-side would take 6 minutes to navigate. Equally, the work-in-process inventory of cars on the freeway does not affect throughput directly. The goal to maximize throughput, therefore, is to find a way to maintain precisely 2 seconds between vehicles.

So we must look at what causes variation in the gaps between vehicles. Some causes will be - driver skill, attention span, eyesight, weather conditions, speed combined with reaction time of individual drivers, and lane switching. It's clearly hard for the traffic management people to control many of these but some they could affect. For example, lane switching. Why not simply ban it for the whole 4 mile stretch? Place double white lines between the lanes for the whole 4 mile stretch! This would have a significant effect. When the freeway becomes overloaded with too much inventory and speeds fall to a crawl, lane switching as people try to find the faster moving lane, actually causes things to get much worse. Eliminating lane switching is a way to drive variation out of the constraint.

What could be done to overcome some of the more human variations such as reaction time, eyesight and skill level? Well technology exists and has been tested by Mercedes on German autobahns to use ultrasonic or laser technology to measure the distance between vehicles. Such technology could be used like cruise control to maintain the 2 second gap between vehicles. Naturally, every vehicle using the bridge would need to be fitted with it. The combination of these two ideas would probably treble the throughput on the SR-520 at peak times. It's so compelling, it's a wonder that the employers on the east-side don't sponsor it ;-)

However, such technology is not full proof and accidents will still happen and an accident (or special cause variation) is devastating to throughput. What else could be tried to reduce the likelihood of a special cause variation?

Well ultimately, you take people out of their vehicles and put them in larger ones with a scheduled timetable running on rails. Anyone for a monorail extension across the lake?

In traditional Japanese society, there are 4 classes of people: samurai; farmers; artisans; and merchants; in that order of importance or rank. Actually there is a fifth class - the untouchables who are also unmentionable. This group includes shoemakers and leather tanners who are not classed as artisans. The Japanese are very particular about anything to do with feet. Feet after all walk the dirty ground and the shoes covering them are therefore unclean.

[A brief tribal aside: one of Ray Immelman's 22 tribal attributes is that a strong tribe knows how it compares to the untouchables. To make the unified Japanese tribe of Tokugawa Shogunate strong, it was therefore necessary to have an untouchable class in society.]

I've been wondering how the Japanese view software engineers. Are they samurai or artisans? Technically, any knowledge worker makes the samurai grade. Software engineers have a university degree. They are educated. They are part of a profession. All professional occupations are samurai jobs. By the 19th Century, Japan was so peaceful and civilized that the samurai were no longer needed as warriors. The modern samurai of his day was a doctor or other professional. Meanwhile, in todsay's world, those ceremonial swords - the short and the long - would both come in handy for hacking up source code and refactoring it ;-) However, the reality of much software development and a key argument from some of the agile community has been that software development is a craft. That would put it clearly in the artisan category.

So, if the Von Neumann architecture had been around in the 1840's before the American forced regime change in Japan, would the Shogun have viewed the programmers as members of the samurai? Would they have been rich, well dressed, middle class land owners with servants, horses and vacation homes in the country, licensed to carry swords in public, and revered by ordinary members of society as their betters? It's interesting to compare which of these attributes apply today and which don't - "So, you work at Microsoft. Tell me, what is it about software engineering that has got anything to do with being a professional engineer?", a Boeing employee.

When you visit the National Garden in the Imperial Palace grounds in Tokyo, they give you a plastic entrance card on entry. You return the card on exit at either the North or East gates of the palace. On first observation, it seems like a security scheme to insure that no visitor is accidentally forgotten and remains in the grounds after 4.30pm. However, I wonder how well this scheme would work. Let's consider the variation in it.

On entry our guard couldn't decide if we were a party/family of 5 or 6. The 3 month old in the carrier around my neck ought to count but was it really necessary. As we shuffled through so did several other individuals and families. Had he really counted everyone accurately? On exit, it might have been easy to explain that the 3 month old didn't have a card whilst we secretly kept it as a souvenir (which we didn't, everyone in the party except me being a good upstanding Japanese citizen). I'm left wondering what the shrinkage of cards is each day? And how much search effort around the National Garden is required to be sure that the missing cards walked out the facility and aren't hiding in the bushes.

As a security system, I think the card system has more variability than would ideally be desired.

There is a second, simpler but less obvious reason for the cards - it's a Kanban system. The cards simply limit the inventory of people visiting the gardens to keep them from getting overcrowded. I strongly suspect this is the real reason. When the cards at the entrance run out, then new visitors need to wait until someone leaves. This is only likely to happen on very peak times such as New Year, the Emperor's Birthday and so forth. The Kanban solution has much lower susceptibility to variability. It doesn't matter if there is a small amount of shrinkage on an individual daily basis because it's a fail safe arrangement. So what if a few visitors have to wait a little longer to gain admission and the overall maximum inventory is reduced from shrinkage. The Kanban idea is much more variation tolerant.

I'm currently thinking a lot about Kanban systems and software engineering - after Don Reinertsen challenged me with it recently. He believes that the work I've been doing with cumulative flow diagrams will enable a Kanban system in tooling. The question is, what would be the benefit of such a system. It would certainly be easy to extend Visual Studio Team System to report inventory levels at different work item states and to limit the creation of new work items or movement of work items from state-to-state according to some Kanban limit. BUT, and this is the real question, for what purpose? I need to find a team willing to experiment with this idea manually and compare it against the drum-buffer-rope solution I have been evangelizing to see whether it is a flyer or not. Don't expect an answer to this question anytime soon.

Saturday 9th April was my birthday. One that put me fairly and squarely in the "late thirties" category (san-ju-hatuchi to be precise). In honor of this occasion, my in-laws treated the whole family to a sushi lunch at a serious but not overly pricey sushi restaurant in the Hibiya district of Tokyo. Hibiya is a financial office district to the North East corner of the Imperial Palace. As it was hanami season and the palace gardens were busy with visitors, the restaurant which was no more than a sweet 5 iron over the moat into the palace grounds, was also busier than usual for a Saturday. However, this seasonal variation must be considered as common cause rather than special cause because it is entirely possible to anticipate that any Saturday during hanami, the restaurant will be busier.

On arrival we were told that we could not be seated - there was a constraint ;-). The constraint was being protected by a capacity buffer of seats outside the door. We sat down. The menu was brought to us but strangely no one came back to take our order. Eventually we were seated inside at our table and a waiter arrived to take our order. My brother-in-law had placed some serious effort into selecting the pieces to be ordered and the numbers of each piece including some special treats for me as the birthday boy. The order was placed and we waited and waited. Meanwhile, the almost 3 year old in the corner seat was getting hungry and was eager with anticipation for the arrival of her California roll.

A plate of sushi arrived. No California roll!

On further inspection, it appeared that only half (han-bun) of our order had been fulfilled. An enquiry was made. A very polite waitress explained that the sushi chefs were fully loaded (a capacity constrained resource) and that in order to keep all the guests happy and provide food in a reasonable lead time, they were filling only half the order initially. The sushi chefs were self-organizing. They were presented with the order list and could burn it down as they saw fit. So an essentially randomly chosen selection representing half of our order had been delivered. Fair enough! Small batch sizes. Incremental delivery. Shorter lead times. It all made sense.

However, the vocal toddler was annoyed and frustrated. She started to chant, in English thankfully, I WANT SUSHI! I WANT SUSHI!

This was a serious sushi restaurant. You could tell this because the only condiment on the table was soy sauce. The sushi was served with ginger but no wasabi. This is to prevent uncouth foreigners from insulting the sushi chef by adding extra wasabi. The chef has expertly selected just the right amount of wasabi to enhance the flavor of each piece. Why add more? However, the uncouth do have an outlet, they can always dip pre-prepared pieces such as unagi (grilled eel which already has soy sauce) into the soy sauce - henna gaijin!

So we offered our unhappy customer the tamago (egg) sushi. She wrongly identified the egg as cheese and said, "I don't want cheese!" So she dismantled the sushi, offered the "cheese" to daddy and ate the rice!

Eventually, the second plate of sushi arrived. No California roll!

This was a serious sushi restaurant! They could not or would not make us Kariforunia maki! A lot of bowing came with this explanation. The toddler burst into tears and wept uncontrollably to the consternation of the waitress who could not comprehend what had just happened. My brother-in-law skillfully negotiated an alternative order and asked that they expedite it.

So now other customers order were being delayed whilst they processed our expedite order.

Serious sushi eaters, eat their rolls (maki) after the individual pieces. The chefs had chosen to make any rolls we ordered last. As they were self-organizing and burning down our order list, the information that they could not or would not make the California roll had not been forthcoming until the last moment. Hence, the surprise!

So what is the moral of this story? Iterative incremental delivery and self-organizing burn-down aren't enough! There has to be some analysis of the requirements and an attempt to understand the true customer needs - to understand the customer's definition of quality. Based on this, the priorities should be set for the incremental deliveries. There should be a commitment to the customer - a promise made - and it should be honored.

In addition to the quality problem, this restaurant had a broken organizational structure and poor separation of responsibilities. The "Anderson lunch project" should rightly have been the responsibility of the waiter who should have been playing the project manager role (and maybe the program manager role). The waiter should have analyzed our requirements and understood our priorities. This should have been communicated to the chefs and the order of production of our sushi should have been negotiated against the competing orders at the time. The sushi chefs should have been purely responsible for the production of sushi. They should not have had any project management, program management or scheduling responsibility. After all, they had no direct contact with the customer and as the system's capacity constrained resource, they should not have been wasting sushi making capacity trying to do anything else. (Actually, they weren't wasting capacity, they simply weren't doing a job that needed to be done. This was the root cause of the quality problem.)

[We will see when I get back to discussing Ray Immelman's work that he agrees with my separation of functional capacity against project flow responsibilities but for tribal reason rather than variation and constraint reasons].

All of this goes to show that quality is not a given in Japan. They might be great at making cars but many of the management lessons have not transferred elsewhere. No end of bowing can make amends to a 2 year old whose expectations were disappointed.

Before I get back to describing Immelman's model for organization and management based on tribal behavior, I thought I'd make a few observations from my trip to Japan.

The Japanese season of Hanami (cherry blossom viewing) is taking place in Tokyo this week. From a management perspective, this means an excuse to organize a morale boosting party for your staff. Here's how to do it. Select the junior-man (the Japanese have a word for this) from the office. At this time of year, he (or she) will be a fresh college graduate with a new suit, shiny shoes, and a stunned, deer-in-the-headlights, look about him. Dispatch this individual with a large tarpaulin to Ueno Koen (or another nearby park open after dark) with orders to stake out a territory and under no circumstances should he leave his guard post. If you're feeling generous then send a couple of his friends to keep him company, fetch water and sandwiches. It will be a long day of guard duty. Now have your assistant source a karaoke machine - probably from the cupboard under the printer and insure the batteries are charged ;-) and send someone trustworthy to buy the beer. Show leadership by leaving the office before 6.30pm and ask everyone to follow you to the park. Maybe let your hair down - loosen that tie a little - heck, maybe even take it off. [They're snappy dressers in Tokyo]. There will be a fun evening ahead for everyone - and the Japanese really know how to party and enjoy themselves when you put a microphone in their hands. Lastly, as a manager, it would be responsible to wind things up in time to insure that everyone can catch their train home.

So here is the problem with Hanami. It's not like the Emperor's Birthday - you just can't schedule it in your calendar. The cherry trees bloom when it suits them dependent on the winter weather conditions and the arrival of Spring. Yes, there is variation! The thing is, that to really be enjoying the spirit you have to hold the party under the trees whilst the cherry blossom is falling around you - not before and not after. The whole idea is to celebrate the fragility and shortness of life and its beauties. The window of opportunity is only a few days long each year.

So when the Anderson's (yep, that's me in the Asakusa Temple gardens last week with the junior carrier of the Agile Management gene code) go to Japan for Hanami, we have to make a guess - airline schedules are deterministic (more or less). So we book for the first week in April. And then we set our expectation that we will probably get to see some cherry blossom either blooming or falling but probably not both and maybe neither.

In our real home lives, we know how to deal with variation. We know how to set expectations appropriately. We accommodate variation like it was natural because it is. Why do we struggle to do so in our professional lives? So, did we get to see cherry blossom. Yes, we did! Did we see it falling? No, we didn't. Did we get to party under the stars, petals falling around us. Nope! Did our vacation meet specification? Yes, it did! Because that specification had variable expectations built into it.