As the humanists (and Dan Pink!) will remind us, so often a “thankyou” can be as big a reward as any monetary thing, and in this case – doubly so. An enterprising Melbourne agilist enlisted family members in the Ukraine to find us some amazing Soviet-era Lunokhod stamps. Some all the way from Cuba and Mongolia!
So thank you Anna!
Taiichi Ohno was reputed to take new graduates at Toyota to the factory floor and draw a circle on the ground. The graduate would then be told to stand there and observe; if upon his return they had not seen enough then he would tell them to observe for longer. While it might feel like something out of a Karate Kid movie Taiichi Ohno was really teaching a simple lesson. The only way to really understand a problem is to go to where it happens and see it.
While Lean and the Toyota Production System is largely credited with pioneering this approach, I suspect that like most parts of the TPS it’s just a nice packaging of a common sense observation – Kanban for example was just a reflection of the way a Supermarket has to maintain stock on its shelves: a pull system where the consumer takes an item and leaves space to bake more bread, or butcher another animal etc to replace it.
Rickover (father of the nuclear submarine) understood this only too well and long before the TPS would force ships’ captains into boiler suits to crawl the bilge of their ships with him looking for problems on ships in for repair and refitting.
“What it takes to do a job will not be learned from management courses. It is principally a matter of experience, the proper attitude, and common sense – none of which can be taught in a classroom… Human experience shows that people, not organizations or management systems, get things done.” – Rickover
Co-locationing cross functional teams is just another kind of Genchi Genbutsu, it allows all the members of the team to see and understand the problems that others are solving. Lockheed Martin has colocated designers, contractors, pilots and welders etc in their Skunkworks since the ’40s. The JPL has its Team X and Agile teams colocate everyone from their end customers to the sytem admins if possible.
Many years ago when I was running the IT team at a SAAS business we had a simple task tray application which measured system performance and warned of basic metrics being off trend (user sessions, average response time and # of database sessions). We displayed this on a huge TV in the middle of the building – right between the customer service area and the main developers’ workspace. When a problem happened the phones would ring, alarms would sound and within seconds developers were talking to customer service reps, who were in turn on the phone with customers about the problem. Nobody was told to ‘log a ticket’.
Leaders, get out of your boardroom and out of your confortable office shielded from the world by your highly efficent PA; go and see how the sausages are made. Walk the floor, talk to your staff and spend time doing some of their work. If your product people are complaining about IT ‘never delivering’ then get some extra desks and have them go and sit in the middle of your dev group to understand why. If your inventory system always fails, go to the store room and watch boxes being unpacked and catalogued. If sales are down, go with your sales team, visit prospective clients and hear from their own mouths why your product doesn’t cut the mustard.
Genchi Genbutsu – Go and See.
As much as I might logically argue that the whole Shuttle program was a boondoggle, stupid and use it as a shinning example of what not to do with your project I can’t lie; My heart races a little bit every time I see images like these ones from Dan Winters book about the last launch of Atlantis.
UDPATE: I have my copy of the book now, it’s beautiful.
Field trips to the Smithsonian are highly recommended by Luna Tractor! The lunar lander LM-2 is stored in the Washington DC Air and Space Museum.
We’ve already referred to the Lunar landing Module (LM in NASA parlance) as the greatest machine ever built. The chance to see a replica in Washington DC was very exciting.
So imagine my amazement to discover that the machine is NOT a replica. It is LM-2, the module they built as a spare unit in anticipation of something going wrong with one of the others. As it happened, things went smoothly (if you don’t count Apollo 13) and it stayed in the shed at Cape Canaveral.
The lesson that the Lunar Module teaches us is fitness for purpose – an old definition of 
quality that has stood the test of time. Take a close look at the panels on the module – it is riveted together with the bare minimum of materials to keep it light.
“Why isn’t it shaped like a plane” asked my traveling agile assistant, whom we shall call ‘Retro-Boy’. The answer lies in the fact that aerodynamics are somewhat irrelevant in a vacuum.
The modular design of these craft allowed the lessons of the previous Apollo mission to be incorporated quickly into the next mission.
In our YOW! 2011 talk we discussed the space shuttle era that began in the late 1970s – an era of USA and Soviet rivalry based foolishly on strategic parity (‘our goal is just to have what they have’). Horrifically, many dot com genius business plans are still based on the futility of strategic parity, in short they read: ‘__________ <insert successful website name> but with ________ <insert tiny variation with no proven customer value>’
The Soviets soon abandoned their own space shuttle, which is bizarrely similar in design 
to the USA model (clearly, they downloaded the plans from pirate bay), in favour of the Soyuz rockets they developed in the 1960s and still fly today.
With the first American astronauts eschewing their shuttle program in favour of hitching a (much cheaper) lift to the International Space Station aboard a Soyuz this week, it was timely that I had the chance to see the Discovery first hand at the Smithsonian.
Like the SR-71, you have probably underestimated how big the shuttle is from the TV pictures.
The body is at least the size of a 2-3 story Melbourne house (those long, thin 5-6m wide terrace houses). Shiny and glowing on TV, it is a beaten and battered workhorse on the outside. The tile pattern is infinitely complex, the white paintwork burnt and worn. It is hell to photograph without diminishing it in scale somehow.
Locked in to such a monumental design, it is easy to see how you would avoid change at all costs on this piece of technology, and why the cost of ownership was so high, that in the end, it was retired with the same conclusion the Russians had drawn 30 years before – just too much money to run and innovate as a platform.
Sound familiar to anyone?
Space Shuttle Challenger in one of the most famous (and chilling) space photos of all time.
As I read this week’s Telegraph obituary of a great American rocket scientist, I was moved to thinking about how we deal with the whistleblowers and truth-tellers in an agile world.
How can we strike a balance between encouraging transparency and realism, while managing the impact on the morale of tight-knit teams from Negative Nigels and Whining Winifreds?
I’ll be the first to say that the command and control culture of committed waterfallers (like NASA) is a fast track to secrets being kept, and problems being swept under the carpet. When “failure is not an option” on a project racing toward a fixed launch date, with scope being secretly trimmed off Gantt charts to ensure compliance with public commitments and budgets, and all-nighters pulled by tech heroes, we are just hiding failure.
Is agile any different? If it is effective, yes. But agile zombies, with their card carrying undead marching into retrospectives and standups ritually chanting out their obligations so they can get back to their desks as quickly as possible, is probably just as bad as waterfall.
This tragic tale of an ignored voice is a stern reminder of the consequences of avoiding talking about engineering issues.
When I arrived at Lonely Planet in 2007, and proceeded to shut down a failed waterfall-delivered website program, the HR team had already initiated a training program called Effective Conversations. It seemed uncomfortably basic and quaint in intent – teaching people to get good information across quickly and confidently when in meetings, in casual conversations, one on ones, or in the lunch queue.
A month later, I knew it was gold – I had yet to find a person who did not say “I knew that would happen”. People had just not managed to get the complexity and interdependence of the hairball of product and architecture problems across to Steering Committees and executives. And after a few public scoldings for being naysayers, they learned to shut up and soldier on.
Edward Tufte tackled this same issue of communicating complexity for NASA after the 
second major shuttle program disaster – Columbia in 2003. This $7 report from his website is one of the best training guides for agilists to invest in around effective written communication.
The constraints put upon Boeing and NASA engineers to explain the complexity of the situation where chunks of insulation had broken off the booster rockets and damaged the heat protective tiles on the leading edge of the wing, using Powerpoint slides with bullets points and a constrained number of words per line, was too great. The wrong decision was made to not space walk and inspect the damage.
I wonder if that was a ‘didn’t work’ or just a ‘puzzles us’ in a retro sense? Either way it 
signaled the beginning of the end for the second great chapter of the USA’s space exploration efforts. If you are facing an ever increasing complexity in your product and IT architecture, our advice is to put as much investment into improving everyone’s communication skills as you are any engineering effort.
Buy your copy of Edward Tufte’s handbook from his website here.
As the lunatics in charge of the Luna Tractor, James and I are fortunate to spend time with the 25% of Australian agile professionals who actually give a shit, who we often meet at industry conferences. The smarter among you will have realised I’m rudely suggesting that 75% of so called ‘agile professionals’ don’t actually give a shit, which sounds harsh until you hear my benchmark number for traditional business people (waterfallers, 5 Year Planners, CMD+CTRL freaks) who give a shit – more like 1/100 or 1%. Maybe in some cases 0.1%, depending on the institution.
The British cabinet war rooms - agile wall, all the comms you need, the right people in the room, iterating by the hour in 1936.
Economics lesson aside, being invited to YOW! 2011 to present was a real highlight for us. James and I gave a 45 minute talk on the history of coincidentally agile-like practices over the past century, and how they have contributed to some great innovations (particularly in the engineering and space fields, our favourites), as well as some Class A ass-saving.
YOW is reputed to be a developer-centric affair, with a speaker roster even including several actual inventors of famous programming languages (check out the superstar roster here), so as the resident economist I was fairly nerve wracked! Should non-developers even go to YOW? Is it just too geeky and engineering focused? My experience is absolutely yes, you MUST go to YOW – per Martin Fowler‘s signoff at Agile Australia 2011, we are all complicit in software development now, and gathering an understanding of that craft is vital.
A speaker like Mike Lee might go over your head if you are not an engineer for 5% of the time, but he chooses to focus as much on issues like learning and intellectual property protection as development language choice (and he is damned funny while he’s at it). Someone like Kevin O’Neill from Melbourne prides himself on keeping it comprehensible 
for everyone, without losing the pointy stuff, and the joy of invention and discovery. The big kahunas like Simon Peyton Jones are talking as much about the history, sociology and philosophy of software engineering as they are lines of code. Meanwhile the Linda Risings and Mary Poppendiecks are there for everyone to learn from.
You can easily pick a path through the YOW! program that takes in the more social and cultural side of software engineering and working in teams (these are passions for organiser and founder Dave Thomas) as well as some more general interest code and development talks, and if ever there was an environment where it is safe for non-coders to ask dumb questions – it’s YOW!
It’s actually the developers who need to worry about their reputation in front of their peers – just say “hey, I’m not an developer, but I’d love to learn how that works in simple terms so I can understand…” and you will have an erudite, clear answer in no time.
Good software engineers love their work, and want other people to love it too.
We’d also love to see a few more software developers and testers at Agile Australia 2012 in Melbourne at the end of May, joining the lively community of product managers, agile coaches, lean gurus, analysts, iteration managers, project managers, thinkers, vendors and practitioners who gather there each year.
A great example of our agile community’s need to think more holistically was raised by Mary Poppendieck and Linda Rising at YOW, who both called “bullshit” on agile’s current obsession with teams of 7 +/-2 people (read devs, testers and a scrum master) as ‘optimal’, when organisations that deliver products to end customers clearly involve everyone from the person on the phone to customers at the front desk, all the way to the intern. Teams of 30-70 are way more normal and work just fine, so stop obsessing about your tiny team at standup being the whole agile gang. That mirrors our experience at Lonely Planet for sure.
If you didn’t manage to get to YOW! in 2011, or as always seems to happen, were forced to choose between sessions, the majority of the papers are up on the site, and most of the presentations were video recorded – check out the YOW Eventer website put together by the Cogent crew in Melbourne for the video over the next days – there’s a couple up already including ours.
Craig Smith with Mary Poppendieck at YOW 2011 Brisbane - the gold standard 'hard act to follow' at a conference
A copy of our slides (with still images replacing the video we showed in Melbourne and Brisbane) can be viewed online here: Luna Tractor YOW 2011 Decades of Agile
YOW! is a multi-media affair, so naturally there’s a podcast – produced by two of the Australian agile community’s bright young things, Craig Smith (who blogs here when not
Breakfast at Brew Cafe in Brisbane - sensational
coaching and inspiring agilists) and Renee Troughton (who has a great site called The Agile Forest). This was done in a fab (very Lonely Planet) little cafe called Brew in Brisbane, so the background noise is fairly busy, and we discussed (I suspect that should read ‘Nigel talked about’ – Ed. JP) a vast range of topics around agile, Lonely Planet, consulting and change.
You can listen to that podcast here, and of course it’s available on iTunes: http://www.theagilerevolution.com/episode-19-luna-tractor-with-nigel-dalton
My very best impression of the French gallic shrug - perhaps in reponse to Charles' line of questioning on whether Microsoft could be agile 😉
And finally on the media front, Microsoft’s Channel 9 conducted interviews of many of the speakers at the conference.
You’ll find them all on their prolific and rich tech-focused website, while my own epic 30 minutes of righteous crapping on about everything agile, Lonely Planet, and offering unqualified advice to Microsoft about becoming agile can be accessed right here.
See you all next year.
We spoke at YOW this year on the topic of innovation and agile over 6 decades, highlighting the Agile and Lean principles we see in space and engineering projects. From the 1930s we talked about the Cabinet War rooms and that deserves a whole post of its own as we continue to expand our understanding of how physical spaces enable and impact the people and results. From the 1940s we talked about Lockheed Martin and their Skunkworks which we’ve written about before. From the 1950s we looked at some of the magnificent engineering created by that same Skunkworks team… The Agile movement may only be 10 years old, but the principles and the evidence that it works goes back way further than that. We’ll write more reflections on YOW itself at some point, but today you get one of the lessons that most appeals to us.
The U-2 Spy Plane
When the U-2 first flew in 1955, it was an accident. A high speed taxi test saw it rolling down the runway at 70 knots at which point its sailplane wing generated enough lift and it took off into the air unexpectedly. At the other extreme, its cruising altitude of 70,000 feet is referred to by pilots as coffin corner; at this height its stall speed is a mere 10 knots slower than its maximum speed.
The balance is so critical on the U-2 that the cameras had to use a split film setup with reels on one side feeding forward while those on the other side feed backward, thus maintaining a balanced weight distribution through the whole flight.
The plane is incredibly difficult to land because of the lift cushion under the wing as it comes close to the ground. It lands on two inline ‘bicycle wheels’ and the wing tips also land and skid on the ground on titanium plates.
Perhaps the most amazing U-2 fact, and the reason we consider it such a testament to great engineering, is that it’s still in active service today.
The SR-71 Blackbird
This is the fastest and highest flying air-breathing aircraft ever made (only rockets can go higher or faster). It has a maximum speed unspecified above Mach 3.5 (3.5 times the speed of sound) and a maximum altitude also unspecified but in excess of 85,000 feet. At Mach 3.5 you’re covering 1km per second and the engines are sucking in 3 million litres of air every second – an average human breaths in that much air in a year.
The construction of the plane is pretty special too, with 90% of it being made from titanium. At Mach 3+ the surface of the plane heats up to 500+ degrees. The wet patches you can see on the wings and central spine in this photograph are caused by the fuel leaking out of the expansion joint ‘gills’ in the plane. Until about Mach 2.5 when the plane heats up and expands, the SR-71 leaks fuel constantly.
While the Concord can do the transatlantic London to New York flight in about three and half hours, the SR-71 is the way to go if you’re in a hurry. It holds the record at just 1 hour 54 min.
My favourite SR-71 story comes from a pilot in the book Sled Driver: “One day, high above Arizona , we were monitoring the radio traffic of all the mortal airplanes below us. First, a Cessna pilot asked the air traffic controllers to check his ground speed. ‘Ninety knots,’ ATC replied. A twin Bonanza soon made the same request. ‘One-twenty on the ground,’ was the reply. To our surprise, a navy F-18 came over the radio with a ground speed check. I knew exactly what he was doing. Of course, he had a ground speed indicator in his cockpit, but he wanted to let all the bug-smashers in the valley know what real speed was ‘Dusty 52, we show you at 620 on the ground,’ ATC responded. The situation was too ripe. I heard the click of Walter’s mike button in the rear seat. In his most innocent voice, Walter startled the controller by asking for a ground speed check from 81,000 feet, clearly above controlled airspace. In a cool, professional voice, the controller replied, ‘ Aspen 20, I show you at 1,982 knots on the ground.’ We did not hear another transmission on that frequency all the way to the coast.”
This article from Gizmodo about flying the SR-71 is required reading.
In a world of throw-away appliances and software it’s a salient reminder that great work, great engineering lasts a long time. The Skunkworks team was isolated and protected from the rest of the organisation; this one team designed over 30 planes including the U2, A-12, SR-71, F-117, F-22 – just to name a few iconic aircraft.
Another wonderful set of photographs published by the quirky www.cracktwo.com inspired me to share another tale from the Russian Space Program. The late 80s saw one of the most interesting and the single most expensive space program ever undertaken by the Russian Space Agency: the Buran spacecraft, a reusable space vehicle created as an answer to the US space shuttle program. The Soviets were concerned about the possible military applications of the US shuttle and its ability to launch large payloads into space. This view was compounded by US profitability analysis which required roughly weekly launches to be economically viable. Cold War fears of space-based lasers or nuclear weapons drove the Russians to copy the American space shuttle in an attempt to maintain strategic parity.
One unmanned Buran launch occurred on November 15, 1988 and for 22 years remained the only space shuttle to ever perform an unmanned flight and landing, another testament to the Soviet technology and ingenuity. Ultimately the program was cancelled at the collapse of the Soviet Union, and as it became clear that a reusable launch space vehicle was in fact much more expensive per launch than the cheap and reliable Soyuz spacecraft that had been in use since 1966. There is of course some irony that as the American shuttle program has now been shut down it is the Russian Soyuz craft supporting the ISS and there have even been discussions about reviving the Buran program. To this day the Baikonur Cosmodrome in Kazakhstan remains the busiest space port in the world.
Oh yes I nearly forgot, in good Luna Tractor tradition our stories normally have some lesson. Today the moral is this: just because your major competitor is doing something, doesn’t mean that it’s always a good idea for you to copy them and do it as well.
