I'm taking a breather from tribalism and this may be my last post for a couple of weeks. I'll be taking in the hanami season in Tokyo in the meantime. I won't be going online. I won't be taking my personal laptop with my blog content management system with me and I won't have a broadband connection to temp me to the dark side. I will return mid-April having restored my spirit after celebrating the beauty and fragility of life and how quickly it passes.

But before then...

There has been a lot of discussion in my Yahoo! group about paradigms. I've been pushing the idea that Agile Management is about applying a new paradigm of thought to managing software engineering projects. One reader and fan of my book actually sent me a summary of what he called the "Anderson way" against the established wisdom. It had 21 lines on it. That's a lot of paradigms to go breaking in a single blog post, so I thought I'd summarize what for me are the top five. These actually dropped off the top of my head in a meeting the other day when I was put on the spot to explain what it is I'm doing differently. So it's like second nature for me now. All of these are fully compatible with the Declaration of Interdependence and represent why the DoI is bringing project management guidance up-to-date with more recent management science thinking.

• Flow through value chain, focus on throughput and effectiveness - as opposed to, cost and effort estimating and tracking, cost accounting, efficiency and earned value analysis
• Theory of variation (common and special cause) and buffering - as opposed to, deterministic scheduling and Gantt charts and deviation from plan
• Synthesis and systems thinking - as opposed to, Cartesian decomposition, (bottom up rather than top down)
• Process control and continuous improvement - as opposed to, conformance to plan and specification
• Empowerment and service - as opposed to, command and control

I see this as the embodiment of modern late 20th Century management thinking applied to software engineering. These five paradigms represent the work of many but mostly Drucker, Porter, Goldratt, Deming and Weinberg whilst traditional established software engineering management and process guidance seems to be rooted in the ideas and concepts of Fayol, Taylor, Gantt, Sloan and Brown, and Crosby.

When you see this list, it underscores the magnitude of what we're all trying to achieve here. If you are out there trying to be an agile manager, it takes courage and bravery but stick with it. Attitudes will change given enough time. Unlearning is painful. It's a chemical process in the brain. Giving up a paradigm (or "mindset" - think about that "mind" and "set" - wiring in the brain) is painful. It's like the grief process. First there is denial. We're seeing some of that with the DoI. Next there is anger. We're seeing more of that with the DoI too. Then there is bargaining. We're seeing that too. In fact, the whole project management world is seeing it, as techniques get more and more complicated to try and compensate for their inadequacies. Bargaining is about trying to keep a grip of the incumbent paradigm whilst modifying it to accommodate new demands. [Viz - the risk management section of the new PMBOK]. Then there is depression - the "Gee, I'm not with it" feeling. And the "Oh no, I need to learn something new and I will be a novice at it" feeling. Finally, there is acceptance. The brain has been rewired. The chemical pain is gone. "Yes, this paradigm is better than the one I left behind." And the realization that a new paradigm is an opportunity - an opportunity to realize your potential - to get more out of life. On any given day, you may meet people in any one of these five states of mind, with respect to agile software development and management. That's why it is tough to walk the agile path and to go the whole way - not just development practices - but to rewire the whole organization, how it's managed, how it's organized, how people communicate and report progress.

|

Before I can talk meaningfully about harnessing tribal behavior in software engineering, I need to explain Immelman's basic framework. So today's post is merely passing on a few details. The thesis of Great Boss, Dead Boss is based on notion of the five tribal dimensions

1. Individuals are socially, emotionally and psychologically defined by their tribal membership
2. Individuals act to reinforce their security when under threat (Individual Security or IS)
3. Individuals act to reinforce their self-worth when not under threat (Individual Value or IV)
4. Tribes act to secure their self-preservation when under threat (Tribal Security or TS)
5. Tribes act to reinforce their self-worth when their security is not under threat (Tribal Value or TV)

Note that self-worth or individual value is measured purely in the tribal context. Individual value only increases if the fellow members of the tribe recognize the contribution and ascribe higher value to it. For example, praise from a non-tribal member would not count and would not increase self-worth. This is the critical premise of the first dimension - everything is tribal.

So here is a list of some of my tribal affiliations which may be weaker or stronger but they are all entities to which I feel an affiliation

• Anderson family
• Anderson clan
• Scotland (Scottish)
• Britain (British)
• Europe (European)
• Software Engineering Profession
• Manager
• Microsoftie
• Feature Driven Development
• Coad / Color Modelers
• UML Users
• Agile Community
• Ballard residents
• Seattle residents
• Western Washington Residents
• Mountain Bikers
• Skiers
• Strathclyde University Alumni
• IEE Members
• Kansas City Wizards
• MSF Champions
• TOC (Theory of Constraints) community
• Lean Design Community (CFD user)
• Real Ale drinkers
• Sprintpcs.com Mobile Portal (former leader)
• and on and on...

Have a think about it and make your own list? What threatens your security and how do you react? Then ask yourself, how do you increase your self worth? What makes you feel good or worse? If someone insults you, why does it hurt more or less depending on who it is? How strong are your tribes? What threatens their security? How do you feel about it when their security is threatened? How valuable is your tribe? What can be done to increase or decrease its value?

|

So I've been very patient. Last month I blogged my enthusiasm for Ray Immelman's Great Boss, Dead Boss. I purposefully didn't spoil it for any prospective readers by spilling the plot or the underlying theme. However, I've been getting mail and it is now time for a series of blogs with lessons learned from Ray. If you intend to order the book, or are reading it now and don't want the plot spoiled then look away now and ignore my next 3 or four postings, come back in week or so and squint at the top of the screen, don't look down ;-).

Last year, I wrote a treatise on my discomfort and dissatisfaction with tribalism in the agile community. My feelings were based on the assumption that we are all highly educated and articulate and should be able to put our tribal past behind us and act objectively for the greater good. Well I was wrong. So it's time to eat humble pie. Ray Immelman takes a whole different view on tribalism. He basically believes that it is a force of nature. We are genetically wired to behave in tribes. This genetic wiring is pre-human. It can be observed in our close genetic cousins such as chimpanzees. Hence, it is so old as to be impossible to undo through training and education. Immelman argues that denying our tribal wiring leads to dysfunction. He takes the view that to improve productivity, we must harness the tribal force in nature and use it to our benefit. [Hint: functional orgs are not tribes]

If you want to understand why Extreme Programming has been so successful and why people are so passionate about it, then you need to understand Immelman's 5 tribal dimensions and his 23 tribal attributes. I'll be writing more on this tomorrow. Meanwhile, we can use Immelman's primary approach to understand what might be wrong with the agile community as a whole. When the tribes are warring, the way to unify them is not to appeal to their intellect (as I did) but to create a super-tribe to which they can all affiliate. A super-tribe which is stronger than the local tribe. A good example of this would be the United Kingdom. Where people like me feel Scottish and would identify with the Scottish tribe - an affiliation underscored with a broad brogue accent, a penchant for wearing a plaid skirt to formal dinners, and a deeply wired need to eat Haggis around the birthday of Robert Burns on January 25th - most of us Scots identify with being British and being part of the British super-tribe. It is this super-tribal affiliation which holds the United Kingdom together. Compare and contrast with the breakup of Eastern Europe into many small nations in recent years.

Hence, how do you get the agile community to speak with one voice? to work together optimally to change software development for the better, for ever? You create a strong "agile" super-tribe. So far the Agile Alliance has failed to achieve that. It's membership stagnated at around 1000 people. Until the Agile Alliance can deliver on most of Ray Immelman's 23 attributes and 5 dimensions, I fear it is inevitable that it will remain a loose affiliation of rival tribes. [Hint: To pick the 22nd attribute from the book - a strong tribe has a leader dedicated to the tribe's success. (a selfless leader who puts the tribe first before his/her own interests). This would be a good place to start. Can you even name the leader of the Agile Alliance? - I'd have to go look it up.]

As we begin to build the new project management organization behind the Declaration of Interdependence, I'll be very aware of the lessons from Great Boss, Dead Boss. I'm confident we can build a strong tribe of new paradigm project management professionals.

 

|

Some more little notes I took on day one of the Lean conference.

Bart Huthwaite, Institute for Lean Design

Put value in, don't just take waste out - too many Lean practitioners get obsessed with waste and forget about value. In addition, waste prevention is the purpose of good design - sounds like a Pokayoke tactic to me. [I recall talking about Pokayoke in a similar fashion at least twice before most specifically in Why is Agile not Lean].

The 8 value brothers [Ilities] - performance, affordability, deliverability, usability, maintainability, durability, image(ability), profitability, produceability, marketability

The Evil Ings [which put good Lean Design at risk] - complexity, precision, variability, sensitivity, immaturity, danger, high skill

Always use iterative design cycles (small batch sizes and batch transfers). Huthwaite doesn't think iterations are about risk management either. Iterate because there are 3 forces of uncertainty - marketplace, technology, competition

People is where the greatest opportunity for improved productivity lies

Innovation must be systematically applied. Must have measurement. Tope 3 are usually, cost, schedule and quality but it is important to also measure value. [By innovation, he means process innovation or kaizen or continuous improvement]

Use measurements to understand and always baseline first to show the improvement

Yaruz Goktas, Motorola University

Change agents must have strong technical skills but must also have leadership. [When you think about this it is so true.]

David Rowe / Steve Unvari - Institute for Lean Design

Understand the "cadence" of a business - it is different for every domain. No one iteration size fits all.

TRIZ method teaches - your problem is not unique, it is merely a variant of someone else's problem. [This should be printed as a large poster and hung over the cubes of every software engineering department]

Soni Meckem, Intuit

Key values of change

• Be decisive - stick to vision (strong leadership)
• Shared vision
• Over-communicate, over-communicate and over-communicate
• Openness
• Patience
• Surround yourself with the right team [As Jim Collins said, get the right people on the bus and put them in the right seats]

Tollgate process at Intuit asks a specific question at the end of each "phase". The team focuses on providing the governance information that the leadership team needs to make appropriate decisions. They are not focused on artifact delivery or data. [I was particularly pleased with this news, as it is precisely the governance model we're rolling out in MSF v4.0. So it's wonderful to hear that a company like Intuit is already doing this.]

SDLC built from the ground up through a continuous improvement mechanism not simply an enacted prescription.

Each team is encouraged to self-assess their improvement achievements with respect to their "from behavior" and their "to behavior". Teams always more self-critical than management were of them. Teams always thought they could do better and were eager to improve.

[I didn't take notes on the second day as I was focused on my own presentation. However, highlights included a case study from Hewlett-Packard's printer people who presented data which correlated with mine that small batch size, correlates to short lead time, which correlates to better quality. Very refreshing to hear. If we keep this up, correlation of results based on a sound underlying theory, then we might be able to call this world of software engineering a profession someday soon ;-) Heck, maybe even a science. Geesh! No more herding cats - what will all the cat shepherds do? Take up gardening I suppose.]

 

|

I'm at Lean Design and Development in Chicago this week. The standouts from day one were Bart Huthwaite from the Institute of Lean Design who kindly gave every attendee a copy of his book The Lean Design Solution - funny how you can do that when you self-publish and Don Reinertsen who chaired the conference. In his keynote, he emphasized again and again that the most important thing was to recognize the bottleneck resource in the value stream and insure that it had excess capacity. He called it basic queuing theory but I had to smile and wonder whether he's gotten the TOC religion.

|

Stephen Hawking is on record as saying that you can optimize your brain for intellectual capacity or for quick wittedness. Think of it like an athlete - you can have one great big muscle bound monster between your ears, or you can go for a svelte, lithe, quick, agile model with less intellectual horsepower. James McLurkin seems to be one of the former. In fact he's so muscle bound by intellect even his monthly schedule lacks flexibility.

James McLurkin might be off-the-scale brainy but he's an old paradigm thinker. In order to get everything done, he plans his daily schedule to the minute. But his girlfriend complains that he gets up to 2 hours behind schedule in a typical day. Why? James has no theory of variation in his scheduling. For all his brain power and focus on complex adaptive systems and robotics, he hasn't discovered the theory of variation or realized that his daily life suffers stochastic common cause variation, and uncertain special cause variation.

He's also got cost accounting syndrome. He's fascinated with efficiency to give himself more time. James knows that time is his constraint. There are only so many hours in the day. So he doesn't want to waste time doing laundry. The answer - save up 6 weeks of laundry at a time and do it all in one night. Yep, he went out and purchased enough clothes to last for 6 weeks. He also had to get a bigger closet and presumably a bigger house for that bigger closet. Yep James has a lot invested in clothing inventory.

So he's really smart - right?! Well, I wouldn't doubt it. I'd be lucky if MIT let me in for a tour, never mind a PhD. But I know that if I need my favorite Helly Hansen (North West chic) casual shirt for an evening of beer, sushi, good company, pool and dancing that I won't have to wait 6 weeks for the large batch of laundry to process. In order for James' efficient life to work, he must be able to plan with accuracy. There must be low uncertainty in his life. He must not play much sport. I wouldn't leave a pair of my sweaty cycling shorts for 6 weeks before I washed them.

So here is the lesson - large batch sizes may be the algebraic answer to efficiency but the cost is large investment in inventory, high carrying costs, and a lack of ability to cope with variety, or change and uncertainty. Not to mention the embarrassment of being unfashionable because you can't afford the replacement cost of such a large wardrobe- after all, to be efficient you must keep the clothes for longer or the cost per wearing - remember, each outfit is worn only once per six week period. - will look ridiculous... ridiculous... ridiculous... ridiculous.... [is there an echo in here?]

|

I don't often use blog space to link to others postings. However, I've added Tom Evslin to my blog roll. Tom is a real software management success story. I clearly can't teach him anything. He's clearly much smarter than me. However, he's stuck in a rut badly burned from years of running development groups that gave him no insight into their methods. I'm sure he doesn't trust a software developer as far as he could throw one. He lives in a world where he can't even imagine the type of transparency of reporting, accuracy of estimating, near perfect quality and high level of productivity possible on a well run agile management or FDD project. If I showed him some of my work, he'd think he'd gone to sleep and woken up in a parallel universe - what do you mean, you can see all the development work in action, as it happens? Tom's writing in Managing Programming for CEO's is very amusing, very real and very readable. I'll certainly be following it regularly. But Tom, (sing along now) it doesn't have to be that way...

If you're the CEO or are ever going to be, you've got to know when things are going to be DONE.  Nothing else matters; you can't sell or use half done or 95% done.  As I blogged the other day, "95% done" is programmer-speak for the remaining 5% will take 95% of the total elapsed time.  You are asking for trouble if you try to manage by the percentages.

[Tom, there is warm welcome at Building 25 any time you want to come and see what can be achieved with Visual Studio Team System, MSF v4.0 and the agile management reports available out of the box ;-), David]

|

So a few of you have realized that I was being mildly flippant (well perhaps more than mildly ;-)) when I suggested that you should STOP ESTIMATING! But I hope I got your attention.

By asking you to stop estimating, I'm suggesting that traditional forms of estimation - take a list of tasks, ask for a level of effort for each one (in man hours or days) - is a waste of resources. It's better to have some form of inventory measure. A fine grained one based on some quick, broad and cheap analysis would be ideal - like Features in FDD - but anything else is just fine too, for example, Change Requests, Bugs, Scenarios, Use Cases, User Stories. Now don't estimate them, but measure the velocity - how many you can do in a given time, and measure the variation in the velocity. Use this to estimate the mean time to complete a given batch of inventory and the required buffer for variation. Or flip it on its head and buffer an iteration appropriately and then use the mean velocity to calculate how many units of inventory you can take into the iteration and guarantee to complete them all within the given time.

It's lightweight estimating - weigh the number of value units and multiple by velocity, and buffer for variation. An agile estimate should have a number of value units, a velocity, an end date and a buffer (or a measure of variation in velocity). That's it. You shouldn't be estimating anything individually. Fine grained individual estimates of effort are waste - muda! Just say "No!"

|

So the cat is out of the bag, with respect to the work I'm doing for Microsoft. Last week at the SEI's SEPG convention, we announced MSF for CMMI(R) Process Improvement - an MSF process instance which is enacted in Visual Studio Team System. We got a very positive reaction to the concept from convention attendees. We got some positive reaction from the press too - see this Yahoo article.

It's been a learning experience for me. When you set an agile guy loose on a formal traditional software engineering problem such as CMMI conformance something unusual is bound to happen. For me, it was the discovery that the CMM was inspired by the work of Edwards Deming and the realization that levels 2 through 4 are all about special cause variation with level 5 being about continuous improvement (or reduction of common cause variation). Coupled to the transparent traceability of work items and work products, this opened the door to the agile management solution for CMMI. MSF for CMMI(R) Process Improvement will be a lightweight process. We've taken a stretch-to-fit approach by stretching our MSF for Agile Software Development process and adding just enough to meet a CMMI Level 3 appraisal. We're targeting Level 3 this year and will go for a Level 5 solution later.

We're going to be using a lot of agile management techniques including velocity, cumulative flow and uncertainty buffering with unplanned work charts. Anyone familiar with the material at this site will know that I've done a lot of the groundwork on a Deming style solution for software engineering. To further break with tradition, we won't be offering time on task estimating and tracking, earned value and critical path or much of any other traditional PM guidance as standard elements. We do recognize that there are many people in the market who need these things - particularly through government mandate. So we'll be providing guidance on how to swap them in and users who want EV, CPM and time tracking can still do it with the MS Project interface to Team System. However, out of the box, it'll be a lightweight, agile approach to CMMI.

Because this is quite radically different and threatens to actually deliver a truly democratized CMMI process for the rest of us, we've had to pull in some heavyweight advisors and collect data points from other respected members of the community, to ensure that we're not crazy and that we can meet the spirit and the letter of the CMMI law (err, goals). This is one of the cool aspects of working for Microsoft which wouldn't be possible for me as an independent consultant. I get to work with people like Mike Konrad who looks after the CMMI model for the SEI and Jack Ferguson who guides the appraisal side. I've taken other data points from Bill Curtis who owned the SW_CMM for a long time and now through the recent acquisition of Teraquest, is Chief Process Officer at Borland, and Watts Humphrey who started the whole thing off 17 years ago with a dream of delivering a Deming solution for software engineering. Overall I've had a very positive reaction from these experts. It's validation that it may be possible to deliver an agile, lightweight, low overhead, low bureaucracy CMMI solution. [Naturally, there are lots of others providing input and guidance on this project and they all know who they are.]

So now I need to deliver on the promise. Time will tell whether I get it right. I'll be saying more about this publicly around TechEd in July.

|

This is the fourth piece in my recent series which might have been called Drum-Buffer-Rope for Software Development 101. The first three steps were step 1, Measure the capacity, step 2, Subordinate to that capacity, step 3, Exploit that capacity by stopping estimating.

Step 4 involves driving variation out of the capacity constrained resource. I harp on this a lot. In fact so do most of the TOC community. You must drive variation out of your constraint. Why?

Well the most obvious reason from this thread, is that it will make your planning more accurate. If you can say, our capacity is 100 Features plus or minus 4 per month, that is a lot better than saying 100 Features plus minus 20.

The second reason is that wide variation means that your constraint may not be stable. If your bottleneck resource can fluctuate upwards in throughput significantly then it may cease to be the constraint. When this happens, all bets are off. If you have a different constraint then your plan based on throughput at the constraint has been invalidated.

The final reason why low variability in the constraint is important is that it facilitates consistent, reliable multi-project critical chain scheduling - for the same reason as explained in my second point.

|

In this blog's tradition of cocking a snoot at traditional project management guidance and conventional software engineering wisdom, I'd like to suggest that you STOP ESTIMATING. That's it - just say "No!"

Yesterday, I talked about subordinating to capacity. I skipped over the second of the five focusing steps - exploiting the constraint. Exploiting (including protecting) a capacity constrained resource means that you will do everything to insure that its capacity is fully utilized. So why are you wasting that capacity estimating tasks or work items? I've seen teams burning 40% of their capacity on estimating. That's 40% of the capacity wasted on something we know to be inaccurate at best and pure fantasy at worst.

So I ask you, what do you think your customer would prefer? - a promise which says, "we can deliver approximately 100 Features this month, plus or minus 20" (i.e. 80 to 120), or a promise which says, "Well we estimated everything carefully and we are confident that we can deliver 63 Features this month?" (and we are almost completely certain that we will break this promise because this isn't an exact science).

If you want to fully exploit your constraint - even if you don't know where it is - stop estimating! Starting planning based on capacity throughput and promote the concept of variation and fluctuation. Make promises based on approximate productivity levels. Banish conformance to specification from your planning and estimating activity. When you can persuade everyone in the system to think differently, to view software engineering through a different lens, to embrace a paradigm of flow of value and variation, then you can actually produce significantly more value for the customer.

[This entry is deliberately a little flippant. See Agile Estimating before passing judgement]

|

In TOC's five focusing steps, step 3 is "Subordinate everything else to the decision, in step 2, to exploit (and protect) the constraint, identified in step 1."

From yesterday's post, we identified the capacity of our software development organization. We did this by measuring the output over time. We had no idea where the constraint was. Our system was opaque - just a mass of analysts, developers, architects, testers and others doing work in some ad hoc fashion that we didn't attempt to understand. We didn't identify a constraint. But it doesn't matter that we don't know where the constraint is. We can still subordinate to it because we know its capacity.

The capacity of the whole system shown at the output is the capacity of our constraint. To subordinate appropriately in a drum-buffer-rope problem, we must get agreement from the source to stem off the flow of input to the rate at which the constraint can consume it. Hence, if we measure capacity as approximately 250 Features per quarter, or 35 Use Cases, or 23 Scenarios then this is the rate at which we should accept new work into the system from the marketing folks generating it.

What happens next?

Quickly after we stem off the flow of input to the rate the system can consume it, our constraint will be revealed. Why? Because non-constraints will now have slack time as they will have less work to do than previously. They will start to put this slack time to good use - in my experience developers hate to be idle. When idle they start to work on other things like build tools, or environments or building additional test environments - and so forth. The part of the system which is still capacity constrained will continue to work flat out on deliverables. This is how you identify the constraint in a software organization. First measure capacity. Second subordinate to that capacity - and the constraint will reveal itself. Next follow the five focusing steps.

|

I get asked this question often...

How can you measure the capacity of a team when every feature is different? My answer is always that capacity isn't an absolute number (and I now realize that I didn't make this clear enough in the book) and that it is expected to have a spread of values. It's important to understand the mean and the variation.

What's the first step in a drum-buffer-rope solution for software development? Answer: Understanding the capacity of the system! Find a way of measuring it in terms that are meaningful to the outside - at the output but preferably at the input. If the supplier - the marketing folks - provide Scenarios then the ideal unit of measure is Scenarios. If they supply Change Requests then the ideal measure is Change Requests. With FDD teams, I've tended to use a measure that is meaningful on the output side - FDD Features. As Features are derived from the domain modeling, this requires that time is set aside every quarter to model the requirements and then negotiate the Features to be included. To make this negotiation work, the marketing folks need to be involved in the modeling. They need to agree the currency conversion from Use Cases or Scenarios into FDD Features.

To measure capacity simply observe the throughput of value units over a period of time e.g. 6 months and sample the capacity for each month. I recently worked with a team that does maintenance. Their unit of value is a Change Request. These very immensely in scope, nature and size. However, the manager collected data and demonstrated that there was such a thing as an "average Change Request" and that his capacity could be defined in terms of a mean and a reasonable minimum and maximum per month.

|

If you are going to be attending the Software Engineering Institute's SEPG convention here in Seattle this week, this please stop by the Microsoft booth and say hello.

|

Some very old news, that I intended to post back in October.

Regular readers of this column will know that I use public transport a lot. In fact, I often get up as early as 5.15am to go catch a bus to arrive at the Microsoft campus around 6.30am. Such is life when you want the convenience of coming home in the HOV lane but still have to be there for a 7am meeting. Once, at the Microsoft campus, you can take a minibus from the Overlake Transit Center to any Microsoft building. The service is convenient, fast, clean, has excess capacity and there is free candy - you don't that on King County Metro!

Back in September, Microsoft made some significant changes to the on-campus bus service. Until then, the service was door-to-door like a cab service. You simply asked a receptionist at a building to call you the bus, and you waited a few minutes. It would then take you directly to your destination. Occasionally, someone else might be using it and you'd have a minor diversion to deliver them to another building. The whole system relied on a dispatcher to direct the buses in the most optimal fashion. In summer, the service was great - pick up within 10 minutes and delivery to destination within 10 minutes. However, in winter when demand was greater, the wait could be up to 45 minutes.

The change was to introduce a circular timetabled route. In fact two routes, a clockwise and a counter-clockwise route. Buses run at 10 minute intervals staggered 5 minutes in either direction. Buses don't stop at every building but at designated stops situated centrally in a cluster of buildings.

When I first heard of the changes, it set off my "cost accounting" sensor and my nose started to twitch. I used the bus service pretty much every day so I started to talk to the drivers. I was actually on one of the last ever door-to-door service vehicles just before 5pm on the changeover day. And I was one of the first scheduled passengers, the following Monday morning. So I got to experience the before and after quite close together. I was expecting to discover that management was secretly calculating efficiencies for trips, drivers and buses, and that the changes would "increase efficiency". I expected that the new fixed route service would look more efficient but there would actually be no true savings because the costs were fixed - same number of vehicles, same number of staff. As it happens, I was surprised. The new service is a Win-Win.

The new fixed route provides better overall quality of service - a guarantee that a bus will pass each building ever 5 minutes and a guaranteed journey time to my destination. In winter, this is a huge improvement over the old door-to-door service. So the customer - the traveling employee - wins. The customer throughput is on average increased. It also turns out that the drivers are hourly paid variable costs and sure enough the fixed route allowed the management to reduce the number of buses actually working and cut driver hours as a result - a true cost saving. Note: this is a classic Lean strategy of smoothing flow and reducing WIP inventory. The airlines are doing similar things in their hub airports, reducing the number of staff required. So there is a throughput accounting gain for the business too. It's a genuine improvement. Not just a cost accounting mirage.

This is a great example of a cost saving initiative done right.

|

In the time honored AM Blog tradition of bringing you yesterday's news today, here are the results of the Inside Blogging Business Blogging Awards for Best Project Management Blog of 2005.

And the winner is... Agile Management Blog! :-)

I'd prepared a long speech but I see the clock ticking down. Geesh! Only 25 seconds to go. I'd like to thank Peter Coad for puting me up to this. He and Jeff De Luca persuaded me to start uidesign.net back in 1998 which was the beginning of web publishing for me. 4 years later Peter persuaded me to write the book. It meant the start of a new online direction, this website, the Yahoo! group and eventually the book was published 15 months later. I've just got time to thank my family who put up with daddy disappearing after 9pm most nights to go blog. And finally, most of all, thankyou to all you readers who took the time and trouble to vote. It's nice to be appreciated.

I guess it's time to redesign to accomodate the winners badge on the banner.

|