Monday, October 22, 2007

Bypassing Hubs - where is the constraint in the long haul airline industry?

I really liked this article, The Giant on the Runway, in last week’s Economist. While the locals here is Seattle can take some pride that Boeing appears to have pulled one over on rival Airbus with its 787 Dreamliner model, and its lean manufacturing capabilities that see huge aircraft assembled on a moving line, greatly reducing WIP inventory and lead times, mean that it isn’t just the cheap currency that make the Boeing planes more competitive. The article in the Economist gets at something deeper - the guess work required to predict the future constraints on the long haul airline business and how best to exploit it. Make sure to read down to the section titled, Bypassing Hubs starting…

Boeing believes that a combination of airline deregulation and the popularity of heavy-twin aircraft have changed long-haul flying for good. Instead of the hub-and-spoke system, in which passengers flew in 747s to big hub airports and then took short-haul flights to their final destination, Boeing says that passengers now want the convenience of flying point-to-point and that smaller long-haul planes make it both possible and economical for them to do so. As evidence, Boeing points to the drying-up of orders for passenger versions of the 747.

The following paragraphs go on to debate the cost-accounting efficiency model that clearly guides the strategic planning at Airbus. And we are offered a debate about point-to-point heavy twins versus the hub-and-spoke model that started with the 747 and Airbus believes can be further enhanced with the A380.

If Airbus are to win then the constraints have to be air traffic control systems limiting expansion at more airports, environmental concerns and physical constraints limiting growth of runways and takeoff slots at major hubs, and perhaps the number of qualified pilots. Airbus would exploit the constraint by simply flying a bigger aircraft - the A380. This allows more passengers to pass through the constraint. The exploitation mechanism is a bigger batch transfer. It allows more people to fly without more runways or takeoff slots. It is also efficient from a cost-accounting perspective and drives a lower cost per passenger mile.

However, those of us who’ve been paying attention to the Lean revolution that is quietly dominating businesses well beyond automotive manufacture, may recognize Boeing’s strategy. Boeing’s approach is Lean - based on smaller batch transfers with smaller aircraft, and direct flights between traditionally secondary airports and minor hubs. Rather than overload hub airports it assumes that the correct exploitation strategy is to avoid the hub altogether. It might produce higher cost per passenger mile numbers but you can’t help wondering - will the ever more wealthy customer be prepared to pay more for a better experience based on direct flights over the next 40 years? Isn’t it trip lead time that ultimately defines the airline industry? How much are you prepared to pay to fly direct? Recently I paid almost 50% more just to fly direct from Seattle to D.C.!

My money’s on Boeing! Technorati tag: Lean, Aerospace

Thursday, October 04, 2007

Amit Rathore - new Lean Dev Blog

I really like this blog by Amit Rathore that I just discovered via Aaron Sanders, Epistemologic. Amit is talking about many of the same things I’ve been working on these past 3 years - applying Lean ideas to software engineering problems. Amongst other things he has independently realized that we should stop estimating because it is waste and replace it with something more value-added, that reporting actual velocity is the measure of success that matters, we should move to an iteration less process (like my kanban system), and use charts to plot WIP and identify bottlenecks.

Go add Amit to your RSS feeds now! It’s another Lean development blog not to be missed!

Related Posts: Stop Estimating, Agile Estimating, Kanban in Action, Managing with Cumulative Flow (BorCon 2004), FDD - towards a Lean Solution for Software Engineering (TOCICO 2004) Technorati tag: Agile, Software+Engineering, David+Anderson, Lean, Kanban, Amit+Rathore, Aaron+Sanders

Anatomy of an Operations Review

I get asked what we present at operations review every month. As you can see, we have a full agenda. One key element is that I’m not a presenter. I do open the meeting and close the meeting with just a couple of minutes of very quick remarks to set the scene, remind everyone about the month in review and why we do operations review, and I close by thanking those who contributed and organize the event each month. For the remaining 145 minutes, its the management team that each present their own material.

The agenda is as follows:-

• We lead with action items from last time - kaizen suggestions and follow up
• Then we have company level financial performance and sales performance by market sector etc.
• Next up we present departmental budgets year-to-date plan versus actual and year on year. And we list headcount, open reqs etc.
• Then we typically have a guest speaker from some other business unit who presents on what they do and how they rely on IT for support. Perhaps they focus on a recent initiative that we have supported. This helps connect our people to specific business units and work we undertake for them.
• Next up our business intelligence group reports on some recent release and typically gives a 3 month review of metrics on performance - might be revenue generated, or costs saved, or customer click-through etc etc.

Then we move in to the software engineering section of the agenda…

First we present sustaining engineering stats - throughput, lead time, due date performance on SLA, quality etc

• We then repeat this process for major projects and have our Config Management and SQA department managers present stats for work in the build lab, pre-prod support and quality assurance departments e.g. throughput of test cases written, lead time on builds, build breaks, time to recover a build break, server up time, server outages and so forth.

Then we have our downstream value chain partners present…

Change Control reports successful changes, sources of change failure and so forth

• Help Desk reports tickets and root causes

It’s fairly comprehensive. There are typically over 70 slides of data. We round out with a summary of issues and suggestions raised and we allocate owners for each suggestion/issue.

Related Posts: Operations Review Technorati tag: Agile, David+Andeerson, Lean, Kaizen, Organizational+Maturity, Agile+Management

Wednesday, October 03, 2007

Some other kanban activity

Scott Miller has been blogging about using kanban board in software development and how he went about designing his board.

Meanwhile, Business Lean blog has some advice on the trade off between an electronic kanban system versus a manual system. As many of you know I addressed these issues myself with the Sticky Buddy scheme and the Digital White Board. Technorati tag: Agile, Software+Engineering, David+Anderson, Lean, Kanban

Team Frustration Server

I thought I’d continue my short series on first year job frustrations, with my thoughts on Team Foundation Server and MSF. [At the severe risk of upsetting a bunch of my buddies across the lake in Redmond. ]

TFS has been an agent of change for me. But implementing it was painful. It comes with so much inertia that the team struggled for 5 months prior to my arrival and got nowhere. When I arrived I put some management weight behind it and supported the rollout with resources and political capital. In addition, I focused the efforts of my own direct line management team, by announcing that our first operations review would be held in December and therefore, we needed TFS in place by November 1st in order to have data to present. That gave us three months to complete the rollout. Using a date as a forcing factor really focused folks attention and the work got done. But, think about it - 3 months to roll out version control, work item tracking and reporting! That’s a long time and major management investment. For me it was one of my major “First 90 Days” initiatives.

Since then TFS has become an essential part of how we do our day-to-day work. We also use the TeamLook plug-in for Outlook and the former TeamPlain web client access now available from Microsoft directly. We have well over 100 users on the system. In fact so many non-technology folks now have access that I’d don’t actually know precise numbers. We have vendors using the system and storing their work items and test cases on our servers. We’ve developed a replacement user interface that simulates our kanban white boards. And that user interface has become the client of choice for many of the technology folks working on projects. I hear people refer to “Digital White Board” far more often than I hear “TFS” when I attend stand-up meetings. TFS has become part of the fabric of how we engineer software. [And now… here it is… drum roll please…] But…

Maintaining and supporting TFS has proven hugely expensive for us. We’ve had to invest heavily. While we value the investment - the team lives and breaths on the utility it provides - for an IT shop of our size the investment is non-trivial. We’ve had to invest in supporting work item type definition and process template customization, and in configuration management and Team Build expertise, but most of all we’ve had to invest in report authoring. Currently we have probably 3 headcount dedicated to TFS - one on reports, one on process templates and one on build and config management. Each of those folks but especially the process template and report guys have a long backlog of work.

TFS just isn’t a very agile tool and it doesn’t support so well, the kind of agile/Lean environment and culture, that I’ve built at Corbis. We find that our highly empowered teams are making process changes weekly. Kaizen events that change a process happen too often for a middle-manager like me to keep up with them all. Each time a process change is implemented, there is a work order generated for TFS changes - any change to a work item type definition creates a knock-on change to reports. It can be 4 to 6 weeks later before the electronic system catches up with the manually maintained system. This can lead to incorrect reporting and other funky side-effects in reporting.

We are also not using the out-of-the-box MSF process templates - though we do tend to customize from the MSF CMMI template by default. We like the CMMI template because it comes with an Issue work item type and a “proposed” state in many of the WIT definitions that easily enables our triage process. We almost always customize the work item type definitions and consequently break all the out-of-the-box reports. This causes inertia getting new projects spun up and tracked electronically.

We’ve also found that we have to abandon the MDX authored reports as we are unable to maintain them. We can’t afford to train a developer on MDX. This is a pity because some of the more valuable out-of-the-box reports (read some of the more powerful and complex) are authored in MDX.

We’ve also found TFS to be a lousy tool for continuous integration and we’ve had to abandon it and go with Cruise Control.

We’ve also abandoned the use of the MSF process guidance templates and we use our own custom developed Sharepoint wiki for process guidance. While some tooling has appeared from Microsoft as unsupported Power Toy releases allowing editing of process guidance after a Team Project is deployed, it came too late for us. We’d already committed to Sharepoint. The editing and support experience is nicer too. We’ve been able to open our process guidance up as a wiki where everyone on the team can provide edits. This means we can keep guidance up-to-date with process changes as kaizen events happen. If we were stuck with the XML of MSF then we’d probably have dedicated technical writing resources who’d have a 6 to 8 week backlog of process guidance changes to update.

While TFS continues to be a drain on our resources, and a ball that we drag on a chain slowing our progress, we really couldn’t live without it. It’s power and flexibility is unchallenged in the .Net space and possibly in the entire market. We’ve been able to develop innovative agile/Lean process solutions and put in place innovative reporting methods to provide feedback and management reporting. Powerful but niche products such as Rally, VersionOne, or FDD Tracker might be easier to use, require less resources, provide better and more powerful out-of-the-box reports but they don’t offer the flexibility and programmability and integration with version control, build and test that TFS can offer. TFS truly has been the enabler of our Lean solution, our Kaizen culture and our Kanban process for development scheduling and prioritization.

So we will continue to invest in TFS and it will continue to be mission critical for us. We have some advantages that we have very close links with Microsoft and we can use that influence to provide feedback and target the future direction of the product. However, as many of you will be aware the release cycle remains painfully slow. The interim Orcas release is delayed until next year and it remains to be seen when we get Rosario. Unfortunately the fix for many of the flexibility issues we have with WITDs, reports, process guidance and process definition probably won’t appear until the one after that, if at all. So I know I need to continue to budget for three people to maintain TFS for at least the next 4 years. This cost is justified as long as we continue to get the productivity gains we’ve seen. But my conclusion is that a full-blown TFS implementation like ours is not for the faint of heart. Go there at your peril!

Related posts: First Year Frustrations, One Year Anniversary, My Approach at Corbis, Digital White Board Technorati tag: TFS, VSTS, MSF, Team+Foundation+Server, Visual+Studio, Microsoft, Lean, TeamLook, Personify+Design, Software+Engineering