Skip to main content
Category

Agile

Luna USA Field Trip: Wright Brothers – less money, less resources, more innovative

By Agile, Disruption, Strategy, TechnologyNo Comments

The Smithsonian Air and Space Museum in Washington DC, a treasure trove of lean and agile lessons for Luna Tractorites.

Simon Sinek has a great talk on the rivalry at play in the early part of the 20th century to successfully fly a heavier than air, powered aircraft.

It is an important tale for agilists, as the small budget and time/ weather constraints faced by the Wright’s forced them into a design that was low cost, modular, easily repaired, and could be iterated on very rapidly. With which they killed the competition. I won’t repeat it – check out the Ted Talk I have linked above.

Having generated the design for the innovative flexible wing surface to allow more control, the Wright brothers developed tools to hypothesise, test and redeploy elements of the planes in days and weeks, where the opposition (funded 20x better) took months.

Their work with a primitive wind tunnel enabled them to test quickly, and they questioned everything – including apparently proven mathematical formulae for key factors like lift co-efficients.

This image of the brothers’ workshop taken from the Smithsonian exhibition.

In the Smithsonian Air and Space Museum there is an exhibition devoted to the brilliance of the Wright brothers, which attributes their success to genius, and the short cycles of innovation and testing real, flying, machines.

The star of the exhibition is the original plane. Yes, the exact original, with new canvas stretched onto the frame in the 1980s to replace the rotted old 1903 covering. Three hundred feet in the air, strung up in a wooden, wire and canvas device, it is the best definition of a ‘commit’ that I can imagine.

Perhaps the most remarkable thing is not the first flight in 1903 – but that only 10 years later, a plane successfully crossed the Atlantic. The next big barrier, a private plane in space, was 100 years away.

The Biological Basis for Visual Management.

By AgileNo Comments

How do we see ?

A lens in our eye focuses light onto our retina, our retina send signals to our brain, and our brain spends a huge percentage of its capacity, by far the largest of any brain function, just to decode those signals and recognise what’s in front of us.  We look for patterns, seeing lines and movement; and we learn over time from when we are babies how to interpret those things and figure out what we’re looking at. We also constantly scan; if our eye is rigidly fixed in one spot (through painful apparatus) the image disappears.

These basic biological mechanics are the reason that the cockpit of nearly all aircraft look something like this:

An early 747 cockpit.

Lots of analog dials, rather than digital readouts.  Dials work better than digits because our visual system lets us scan and notice when things are out of place; we instinctively zero in on things that are changing.  We’re also good at figuring out the direction and rate of change with analog dials. Experienced observers can often estimate where a dial will stop based on watching it while it’s still moving. Even in modern aircraft where digital displays are replacing analog dials, the key instruments are always present as analog representations.  The peripheral systems are monitored by computer software rather than the pilot.

Digital readouts, while undeniably more accurate, require much more mental energy to read and process. We just find it much harder to take a snap shot of what’s normal, and notice what’s different, when faced with a panel of 40 numbers vs 40 dials. This is also why we tend to skim reports, and zero in on the graphics, graphs and pie charts rather than tables of figures or words. We decide what to look at from the visual cues, and then check the relevant reference data only for the more interesting items to work out how and why.

So as we apply this understanding of our visual system to an Agile context we can see how Agile boards are very suited our our natural strengths. We’re good at noticing when things change, move or something looks out of place.

Boards also give us a good way to use our instinctive ‘gut’ feedback system – over time teams and even people outside the team get very good at knowing what a good ‘on track’ iteration or cycle looks like – and equally when things are off track.  It’s often not as simple as one or two cards or tasks, but noticing the natural weighting and flow of the system changing over time.  It’s a worrying thing then to hear from a team talking about their Agile board – ‘It works ok, but doesn’t change very much’.  It’s also why habits like putting fences and rows on cards that are stuck is important; it reminds us to check back later when we naturally gravitate to the shiny distraction of the things that are moving instead.

Documentation – is video an agile option?

By Agile, Communication, Development, PeopleOne Comment

Working software over comprehensive documentation – one of the tenets of the agile movement that was enshrined on the agile manifesto over 10 years ago. But it is often hard to convince grey-haired old men carrying sharpened stakes (aka the stakeholders) that when things go wrong, the safest path is NOT for someone to look up the very thick and comprehensive ringbinder your BA team created at release time, find the page with that code on it, and fix it.

Back in the day, a whole industry grew up around documentation and manuals for software development projects. You could even get a job as a ‘technical writer’! I’m glad to say we don’t hear much from those people today, but I have no doubt they still exist somewhere in the land of waterfalls. Plenty of people still make loser manuals, as Mary Poppendieck is wont to let slip. And between James and I, we must have tried ring binders, post-it notes, wikis, white boards, powerpoints, omnigraffle, photos, blogs, twikis, email, text files… just about everything except stone tablets.

Luna hero Donald Knuth would tell you that to some extent the software should be its own manual (aka literate programming) – if fortune smiles upon you, it will be able to be picked up by a later developer and sorted out, based on the use of well-known programming techniques, sensible structure, and the occasional comment.

Architecture is another matter again – agile talks about it being a shared responsibility, about anyone being able to draw it on a whiteboard at any time. Good principle, but things can get quite complex at times – most people don’t want to know everything, just where the dragons be.

Alistair Cockburn made an interesting point at Agile Australia 2011 – that principle #1 of the agile manifesto was about the importance of face-to-face communication, and principle #2 was around minimising documentation. What if we combined these two ideas? In a world full of Youtube consuming, non-reading, video-savvy people, surely a short piece to camera was the next best thing to having the creator of a piece of code on the spot to consult?

So, from a small scribble in my To Do list, was born a video documentation project to take some risk out of moving the Lonely Planet website with a new team being started up in London – 18,000km away with all new people.

The idea was simple – 10 videos, less than 5 minutes each, hi-res with a Flip camera so the whiteboard drawings could be easily seen, and the focus being on pointing out the dragons. Explain the interfaces, where test coverage was weakest, some detail around the databases (recorded brilliantly with a screen grab tool by the DBA) and a great lesson in all the gotchas. The lowest tech thing we could do was label them well, stick them on a USB drive, and ship them to London.

Great idea for release notes, progressively recording improvements to code. A now out of production Flip is only going to cost you a couple of hundred dollars on eBay.

If nothing else, it might avoid the kind of developer comments we once found in some packaged software code -“what kind of f@#$tard wrote this? I have no idea what this is for!”

Give it a try with your iPhone and let us know how it goes.

Customer expectations are bringing uncertainty to your doorstep – an infographic

By Agile, Customers, TechnologyOne Comment

Eric Ries defines a startup as:

A human institution designed to create a new product or service under conditions of extreme uncertainty.

So what does ‘extreme uncertainty’ look like?

Po Bronson coined the phrase ‘radical uncertainty’ 13 years ago in The Nudist on the Late Shift, the book that got me so excited about San Francisco’s dot-com era I left a perfectly good career in Australian corporate IT to chase the dream of startups in America. And those conditions of uncertainty are what led me directly to the agile way of working (thanks Kent Beck), as the only way to cope with business models, shareholder requirements, and customer needs changing on a weekly basis.

Here’s some of the consumer expectations that are driving that kind of uncertainty today, in a brilliant infographic from the team at onlinegraduate programs.com. Grab your iPad, a stop-watch, and possibly a glass of whisky, and head to your own website immediately after reading. You have 4 seconds or less…

Instant America
Created by: Online Graduate Programs

They love feedback down at onlinegraduateprograms.com so drop Tony Shin a note with any feedback using Twitter dm @ohtinytony

Learning – yeah, yeah, we know. No, you don’t know!

By Agile, PeopleNo Comments

As James and I have been building our fashionably lean Luna Tractor startup over the last 9 months, we’ve had many moments to pause and wonder why people just seem to despise reading, listening, and learning about strategy, culture and new ways of working.

It boggles us! How can this be? Learning is the hot topic du jour!

Eric Ries just reiterated his 10c worth that ‘validated learning‘ is the only true measure of progress when you are building a product or company under conditions of uncertainty.

This has caused a bit of handbag swinging in agile circles, as ‘learning’ isn’t anywhere near as easy to measure as a team’s velocity (the throughput of development stories); or a burndown chart (points per iteration); or cycle time (time for a story to turn into cash). His point is that while you may have made good progress towards achieving a plan, that plan may actually be leading nowhere useful for customers.

“Validated learning is not after-the-fact rationalisation or a good story designed to hide failure (btw I hate those smart-ass CEO put-down quotes about ‘experience is what you get when you didn’t get what you wanted’). It is a rigorous method of demonstrating progress when one is embedded in the soil of extreme uncertainty in which startups grow.”

Revenue, no matter how small (in one of Eric’s startups $300 a week), is one good way to validate you have learned something useful.

It’s therefore obvious we all want learning – it makes us smarter and richer (and more like Eric Ries) for a start!

The science of learning is well documented – there are several theories, which if you happen to be an educationalist, we hope you are familiar with. One or more will likely have been inflicted on you by 10 years at school and perhaps more at a tertiary institution. We’ll side-step the science here for a minute.

Instead, we’ll talk about guitars.

As it happens we are both musicians – James an accomplished trumpet player, having played for years, and me, a struggling noob rock guitarist. It’s a skill I chose to pick up in my 40s, and whilst reading about strategy, lean and agile is a painless habit for me, guitar playing has been a start-from-scratch nightmare.

But what the guitar has been for me, I realise picking up a book or learning about agile is for others. Far out – no wonder people avoid learning!

The first thing about learning the guitar is the pain. Pain in the note-holding finger-tips (and some fine callouses to boot); along with pain in the left wrist, hand and fingers (I have a Bb7 claw hand at the moment). The pain comes from contorting my long-standing limbs and digits into new shapes and combinations.

That physical pain is nothing to the pain of emotional embarrassment at hearing notes and chords come out hideously (in front of friends and family); the feelings of incompetence that weigh down my shoulders; and worst of all the nagging, uncomfortable pressure just under the solar plexus that is my bruised self-esteem. You just suck at it, for quite a while. Nobody wants to suck. So we (quite logically) just avoid pain and sucking by staying the hell away from learning.

The second thing is that learning is tiring. I’m trashed after an hour of practice – listening, trying, re-listening, trying again, playing along … keeping up with band-mates and having fun jamming leads to the best night’s sleep.

Photo by Jamie Supple

Thirdly, learning moves at different rates. Some days it just clicks, others a small chord change can take a week to master. It doesn’t pay to plan (in my case) that I can master a song a week for example – too much uncertainty in that! Then, just as my left hand gains competence at changing from an F to an Am chord, my right hand can’t master the strum pattern that makes it sound rich and funky. The ‘team’ are learning at different rates!

The internet both helps and hinders learning – willing amateur musicians seem to have tabulated (aka written the non-notation cheats for) every song every written, and loaded them up to sites like Ultimate Guitar tabs. But most of them are wrong! As you can see in the example above I spent literally months in the wilderness with that Fly My Pretties song trying to figure out why it didn’t sound right – only to have a competent guitarist point out it was a B-flat, not a B.

Learning works so much better with feedback – and not after a week of doing something wrong, mastering the wrong damn thing only to find the chord progression was different all along – and quickly deciphered by a guitar master (see the hand-written chords at right on the photo above). Ten to 20 minute intervals of feedback are the natural human learning cycle. Which makes you wonder how useful a weekly retro can ever be!

Most of the time is spent on my guitar doing it wrong, listening and adapting. It takes a lot of repetition, and I often find it is best to just walk away and come back later – and then be amazed what your muscles have learned while you were cursing those chord changes.

Photo by James Pierce

Launching songs for real into the world at a band gig, or even a band rehearsal is a world apart from practising solo. Everything you thought you knew from doggedly playing along to the original song on the iPod goes by the wayside as the team rhythm takes over, and what matters is the skills and techniques more than the precise process of hitting all those notes in order. The order, in fact, can change with alarming speed!

And finally, a good teacher makes all the difference. I am very lucky to have several, professional and talented amateur in my life. And now I can reflect on why coaching is such a fundamental part of learning to play agile in business.

At YOW! in Melbourne this month we heard Jeff Patton talk about agile adoption, and he told us the story of how Ron Jeffries responds to people who whine about their failed agile project “oh yeah, we tried agile and it didn’t work for us”. He says that is akin to  saying “oh yeah, we tried baseball and it just didn’t work”.

You need to practice, chances are you just suck at baseball!

And it is practice that is the biggest secret of all – for guitarists, baseball teams and agilists.

Footnote: for the curious, here’s a live recording of the original (and beautiful) Fly My Pretties song tabbed so badly, and scribbled all over in my song book above.

Challenger 1986: NASA’s most explosive retrospective.

By Agile, Communication, People, Space, TechnologyNo Comments

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.

Eric Ries – ‘pivoting’ immortalised in a New Yorker cartoon

By Agile, Disruption, StrategyOne Comment

James and I recently had the pleasure of hearing Eric Ries speak on innovation and product development, through an excellent event called Thoughtworks Live here in Melbourne.

Eric Ries has written a great book called The Lean Startup, which was an important book on our list of 33 texts you should read to get your Luna MBA. His presentation last week did a great job of pointing out how the book is as applicable to innovation within big companies and organisations, as it is the garage-based ‘startups’ – the more popular sense of the term.

One of the most enjoyable moments was Eric’s reflection that he never set out to add a word to the global lexicon of buzzwords around startups, and how the term ‘pivot’ had become painfully over-used over the last 2 years. It is still a key concept in the book, but to some extent obsession with it has distracted from the many other great ideas. Pivoting is all about the moment you have learned your startup idea really sucks, and (in James’ words) ‘you need to take your investor’s cash and try something completely different, quickly and without them panicking and taking all their money back’.

When there’s a New Yorker cartoon based on your new buzzword, you know you’ve made it.

Is this why your boss wants to be Agile?

By Agile, People, Strategy4 Comments

There are 2 words in business more loaded with double meanings than an entire season of Benny Hill – agile, and lean.

No pointy headed boss worth their MBA (or salt) is going to ignore someone who says they would like to try to become more lean. That simply translates in their mind to ‘do more with less staff’, and focusing on cost reduction – ergo, more shareholder value and bigger bonus for the boss. If you’re not more explicit, they’ll be adjusting their Excel budget and 5 year plan PowerPoint while you’re still in their office explaining the actual guts of your idea being about changing work practices.

And in terms of agility, the PHB misinterpretation most common is that you will help them change direction in their strategy all the time. Agile = limber = flexible = ability to dance about randomly.

If you’re suffering from executive miscommunication over agile in particular, I suspect this article from the McKinsey Quarterly a few years ago (you’ll need a login to see it I’m afraid, but they’re free – search for ‘Building a nimble organization: a McKinsey Global Survey) might also be a contributor to your pain. Here’s the key issue of misinterpretation of ‘agility’ in a diagram:

Now, those things are all good, but the bottom of the ladder finishing spot of employee satisfaction and innovation is a disaster in understanding what and how agile really works. It works by creating a good system for people to work within. If you’re good at doing that, and learning in short cycles, then you might well see the benefits of higher revenues, customer satisfaction, market share and operational efficiency.

Bizarrely, if you built your organisation focusing on the stream of benefits being read in reverse order from the bottom up, I’m certain you’d have a good chance of winning. Yet these are the things CEO’s expect to be of least value in their lives.

A bad system will defeat a good employee every time. Focus on the system – people, machines, knowledge working in unison for end customers. Stop obsessing and reporting solely on revenue, efficiency and market share. They’re only a by-product of a great system.

YOW conference on Eventer.com by Cogent

By AgileNo Comments

YOW have got their speaker presentation videos all sorted on the new Eventer platform, designed and sold by Cogent Consulting in Melbourne. You will notice 2 things about it – 1) the user experience is absolutely beautiful; and 2) it is a thrill to use. Some magic has been going on down at Castle Cogent.

Check it out here:

You’ll find James Pierce and I presenting on our history of agile-like work practices here (James is the one who looks like Steve Jobs):

I also recommend Damian Conway‘s talk, who is something of a national treasure for Australian technology, and Simon Peyton Jones, the inventor of Haskell, and serial abuser of Comic Sans. Mike Lee and Linda Rising are 2 more sessions to look out for, while Martin Fowler and Jim Webber will be sure to keep you in fits of laughter as you learn.

Congratulations Cogent on the launch of Eventer – YOW makes a great showcase for you.

YOW! 2011 Australia Conference – something for everyone, even the economists!

By Agile, Development, Lean, Space, TechnologyNo Comments

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.

Luna BAHA Award nominee #1: “Implementing Scrum in your project will certainly be a cakewalk after this training”

By Agile, People2 Comments

Picture credit: Dan Abramson

We’d like to present our first nominee for the Newt Gingrich ‘Lunar Colony 2020’ bullshit agile hubris award (the Luna BAHA).

Ed Cortis, the lucky recipient of the email below, is CIO at Lonely Planet, and has a pretty decent knowledge of how  challenging it is to upgrade from the organisational equivalent of Microsoft Windows 3.11 (using commands to control!) to a more Mac OSX agile-like culture – for 4 years he built and ran Lonely Planet’s agile – ITIL – DevOps operational teams, before taking over technology overall in 2011. It is an organisational transition that not many people pull off – but once an Apple agile convert, you’ll never go back.

Ed consequently knows a fair bit about Scrum, plus XP and even Kanban, and the resulting hybrids that the couple of dozen teams at LP now use every day to get things done.

It wasn’t the email’s bizarre spelling and grammar, or the screwy mail-merge that started it off with ‘Dear Cortis’ that sent the numb feeling to Ed’s legs – it was the suspicion that within Australian business’s desperately scrambling to ‘see their business grow at an amazing pace like never before’, too many IT departments would fall for an email like this and leap on the vendor’s international Scrum certification bandwagon, believing the hyperbole. I mean, they’ve got Mike Beedle, world-renowned Scrum guy!

I can hear it now – “Off you go to training, and then come back to make us live by the values and practices of agile please!” As we say in NZ – “yeah right”. It would be a funny joke, if it weren’t horribly true.

Are we being too literal, harsh and grumpy? You decide:

Oddly the  main benefits quoted are about you getting a certificate, not a team successfully transforming to a top agile modus operandi. Resume driven development then.

So sorry to disappoint anyone, but:
a) The simple task of ‘just getting rid of conventional ways of working’ will take most of the organisation to change their ways, and that won’t come with this certificate;
b) Implementing Scrum in your project will never be a cakewalk, no matter how many credits you collect, or exams you pass; and
c) Once you’ve finally grasped that, and you’re certain Scrum is the one for you, why not just club together the cash you and your mates might have dropped on a certificate each, and get someone like Kane Mar at Scrumology, Martin Kearns at SMS-Renewtek, or Sandy Mamoli in NZ (or plenty of other good local people) to show you hands-on how Scrum actually works on an actual business or product problem you have.

Hell, they even do certification training, but I don’t think you’ll find them ever promising a cakewalk.

A moon walk maybe…

Great Engineering Lasts – The U-2 Spy Plane and the SR 71 Blackbird.

By Agile, Development, Lean, Space, Technology4 Comments

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.

Eating our own Dog Food

By Agile, DevelopmentNo Comments

Some Luna friends, Horsham Colour – or I should say now HC Pro – are one of the largest professional photographic labs in Australia, situated in the charming country town of Horsham in the middle of the wheat belt of western Victoria.  Their business is as a high volume, but still very high quality, photographic and print production house.

As a generation of wedding and portrait photographers grow old and retire, a new generation of photographers and products have grown in their place.  Customers no longer just want prints in frames, but albums, cards, books, canvas and prints bonded onto metal etc.  Enabling photographers to understand and order such a wide range of products online has been a goal for the lab for some time.

hcpro.com – a new website which describes the lab, their products and the online ordering process – has just gone online with a bunch of hard work from the guys in Horsham, Grant Bisset at www.speakinteractive.com and ourselves at Luna Tractor.

We extol to teams the virtue of actually using their own products and processes… to eat their own dog food.  With this web project we took exactly the same approach we would recommend to others, ourselves.

We started with a brain storming and culling exercise to decide what the  minimal viable product was – which messages we had to communicate to give us focus.  Working through three areas:

  • Brand – What people remember.
  • Content – What people learn.
  • Action – What people do.

With each of those three areas defined as 2 or 3 easy to understand anchors we went away and designed a simple site. From there we made basic, hand drawn wireframes.

Next we drew up a rough content plan based on the wireframes and started to flesh it out by doing the product photography and copy writing. Over about a week we continually updated our content ‘board’ until we were happy with how it was sitting.

Ready now for construction, Grant did some work on the build in short cycles with Michael (from HC Pro) and I engaged in a review and then tasks to create missing pieces of content.   Having the whole website as a visual picture on the wall made it easier to choose images that conveyed the story we needed to tell,  quality and careful made products.  It also showed us what was missing, and we could put in place holders which served as our to do list, and a kind of burn down chart. Building a very small site (which is really only a version 1.0) made it easier to get quick feedback from potential customers.  From here we’ll listen to what real life customers say, how they use the site from the stats, and phone them to ask why.

The end result is a surprisingly small and simple site, just what we were aiming for.  It never ceased to surprise me how often our solution to problems was simply to remove content, text or extra ‘fluff’ which we had designed in but wasn’t answering one of our core Brand, Content or Action goals.  Check out the site and let us know what you think.

Before:

After:

LUNA CASE STUDY: A health insurance start-up.

By Agile, Development, Disruption, Lean, People3 Comments

Luna Tractor has had the great pleasure of working with a small health insurance start-up here in Melbourne this year. This is their story.

The competitive landscape for health insurance in Australia is dominated by a small number of large incumbents that have been in business for many years. Below that are about 30 smaller players who have as little as <1% market share. Many of the business practices of these players are rusted on through highly proscriptive regulation, legacy systems that are common across players, and old mindsets. New brands pop up now and then, but they are bolt-ons to older players and typically somewhat contained by old practices. Even when new products come out, the bulk of an insurer’s book remains “old school” on the former products. There has not been a material new entrant since Medibank spun out of the HIC in 1975.

A small team of innovators came together in 2011 to break into this oligopoly. Setting themselves a tough deadline to be in the market in 2012, the main business challenge that emerged was to develop an effective operating model – a way for a group of seasoned insurance executives and subject matter experts to collaborate at high speed to reach their goal.

We set the company to work using the principles of Agile and Systems Thinking from the start. Instead of each subject matter expert retreating to their office to write board-level strategy papers to present to VCs and partners, they settled into their future headquarters around large Ikea tables with laptops and built a war-room. They defined themselves by this highly collaborative, communications-heavy set of business practices.

The rhythms of Agile serve them well. Daily conversations about everyone’s work-list (from CEO to office support) help avert risk and surprises. Weekly demonstrations of achievements, most of them not software at all but related to building online distribution, new products and governance, get everyone on the same page, and are platforms for the one-hour retrospectives and planning that follow every Friday.

Everyone has cards on the wall, separated into swim-lanes that reflect the key business objectives such as license approval and product development. The board is constructed using a customised ‘Hurricane’ model, ranging from 6 months out to today, in ever increasing levels of certainty and detail.

There were initial doubts about the suitability of Agile from some of the seasoned professionals on the team – having only ever worked in command and control businesses at senior levels, some perceived they were being asked to trivialise their work with index cards, scissors and coloured dots. There was a strong desire to see Gantt charts and more traditional sources of comfort. These concerns soon vanished when the blunt accountability of speaking to their peers every morning about their achievements and work for the day became apparent as the main purpose of the system.

Any concerns that the new way of working was ‘soft’ were dispelled in the many tough discussions about progress at stand-ups. As the team often reflected, it was far better to have many smaller moments of debate, receive timely feedback and correct their course than have a big ‘oh shit’ moment a month later.

In no time new boards sprang up around the walls, developing products in a shared way, and to the team’s delight their distribution partners, new IT team, Board of Directors and the industry regulators expressed their support for this ultra-transparent and interactive way of working.

With time pressure obvious, everyone focuses on delivering the minimal viable product that can be brought to the table for discussion, or validated with customers and experts. That ‘product’ might range from an actuarial analysis, to a regulatory document, competitive information, or a set of accounts – a desire to boil the ocean and deliver a gold-plated answer when 80% would enable an informed decision has long gone from the culture.

The whole business is now being built on this foundation, to be customer-focused and fast-moving. The team’s ability to collaborate, solve problems and correct their course in short cycles is a major competitive advantage they will never lose – and it is clear they will take these into the operational phase of the business in 2012.

Time to competency at working this way? Eight weeks, with one Luna Tractor Partner coaching four mornings a week initially, eventually only dropping by on Fridays for demo, retro and planning sessions.

The new company estimates their return on the investment in Luna Tractor’s executive coaching to be at least 10x.

Agile Roadmaps, Agile Planning and Topical Storms

By Agile, Development, People, TechnologyOne Comment

All plans are educated guesses, and in truth the futher into the future we try and gaze the higher the likelihood that our plans are really just guesses. We often use an analogy to cyclone or hurricane forecasts when we are explaining this.

Meteorologists can forecast that a big tropical storm (please insert hurricane or cyclone in your mind depending on whether you’re reading this from the top or bottom of the world) is coming 4 or 5 days out, but it’s not clear at that point where it’s going to land.  Instead they predict a wide potential path.  As the storm moves closer and closer to landfall the accuracy of the storm’s path increases until about 8 hours out when we know within some 10s of km where the storm is going to end up.

Planning for large projects is just like this; we can have a good idea of the major direction of travel but working out the fine details of what is going to happen in a few months is unrealistic.  This is one of the key reasons that so many Waterfall projects run into trouble; to continue the analogy, the wind changes direction, customers’ demands and desires change, the regulatory environment changes or perhaps a competitor enters the market etc.

So this is not to say you shouldn’t plan; you need to plan.  Just understand how far away the storm is. If you’re thinking about next week, it’s valuable to plan in detail (stories, tasks, detailed estimates and wireframes etc).  If you’re worried about next month, break it down into the major tasks, but don’t get too worried about the details yet. When you’re looking at what you’ll be doing in 3 months, remind yourself that this is just your best guess is; know that it will change.

Having these longer term plans is still very valuable, but often not for obvious reasons. Having a plan gives you something to push, pull and test alternatives against.  We humans are very very good at comparative value calculations and very bad at abstract ones.  So the plan in place gives you a benchmark against which to decide whether a change will be an improvement or not. It also gives your team a framework around which to make bigger decisions about platforms, architecture and longer term expenditure – again just tell your teams and yourself:

“This plan is just our best guess right now, and we promise to keep talking about it and keep updating where the storm is going to land as we go.”

Rugby and the origins of agile

By Agile, Lean, People4 Comments

A recurring challenge we face when discussing the transformation of 21st century organisations to more agile and lean ways of working might be paraphrased as:

“My boss has never heard of it and thinks it must be a fad – does this agile thing have any history to fall back on?”

Having just spent a week at the 2011 Rugby World Cup in New Zealand with plenty of time to reflect (kiwis don’t go for half-time extravaganzas), it occurred to me this FAQ – which might better stand for ‘fairly annoying question’ – should be a blog post, suitably peppered with rugby metaphors.

RWC 2011, Georgia v Romania

The long history of agile goes back to the emergence of mass production from a world of ‘craft’ industrial production in the 1800s. Around 1908, Henry Ford, with management theorist FW Taylor (and later AP Sloan albeit Sloan worked at GM, not Ford) developed moving production lines in huge factories focusing on economies of scale (make more of the same thing, use semi-skilled labour single-tasking and doing what the boss commanded of them, and unit cost comes down), building any colour of Model T as long as it was black.

When a new product was finally demanded (the Model A), Henry and son Edsel Ford simply abandoned the old factory at Highland Park in Detroit and built a new one at River Rouge, as land and labour were plentiful – the factory and re-tooling reputedly cost up to $100m in 1927 dollars!

The next great leap forward in industrial production methods was not developed in America, but in Japan with America’s help, emerging after World War 2 under a rather unique set of circumstances as the Japanese economy was rebuilt – limited capital, limited land, and limits set on labour by the USA including the bizarre ‘job for life’ laws which forced employers to develop systems of working that enabled 60 year-olds to be productive alongside 16 year-olds.

The system that emerged is now known widely under the tag of lean, but also as the Toyota Production System (TPS), and in Deming’s writings ‘systems thinking‘. By the second half of the 20th century, there was no capacity for constraining consumer demand to only 1 model of car – variation in consumer demand and the increasing speed of change were the key challenges for Toyota to respond to as it set up for business. It was within the cradle of this 40-year period that Agile was born as the next great model of organising work.

The happy coincidental crossing of national obsessions: rugby and lean.

Rugby came to Japan in the 1890s from England. In 1987, built on over 100,000 grassroots players in their corporate leagues and competitions (including imported players from NZ and Australia), Japan qualified to play at the first Rugby World Cup in New Zealand. (Note: Japan actually only lost the hosting of the 2011 RWC by 1 vote – so they will certainly be hosts in the next decade). The national coach for Japan is of course John Kirwan, a kiwi hero of the victorious 1987 All Blacks team.

Just a year before that first Rugby World Cup, Hirotaka Takeuchi and Ikujiro Nonaka of Hitotsubashi University in Japan wrote an article for Harvard Business Review titled ‘The New New Product Development Game‘ that is recognised as the source of a stream of innovative thinking that first rolled into smarter ways of developing software in the 1990s.

Clearly Takeuchi and Nonaka were rugby fanatics, meticulously documenting the way a good rugby team can flow up the field as a team in a series of overlapping phases of play (like option C in the diagram above)- and using that analogy to describe the way successful product development was happening in Japanese companies. Remember the Honda City and the stir it created in the 1980s? That’s one of several great examples they document in the article.

Ultimately Jeff Sutherland‘s coining of the phrase ‘scrum’ in the 1990s to define a wide-reaching agile method was inspired by that article. Personally, I feel ‘scrum’ somewhat misses the overall point of their work, as a scrum is a tiny fraction of the game’s flow, but we’ll go with it. We’re not all rugby-nerds or kiwis.

The most important thing you (the reader) can do right now is to buy a copy of the 1986 article and read it. It is only $6.95, and yes, there is a frustrating paywall thing on HBR.org, but it will be worth it.

For the 99% of you who are non-readers, here is the HBR summary of the article:

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan (and the United States) are using a holistic method—as in rugby, the ball gets passed within the team as it moves as a unit up the field.

This holistic approach has six characteristics: built-in instability, self-organizing project teams, overlapping development phases, “multilearning,” subtle control, and organizational transfer of learning. The six pieces fit together like a jigsaw puzzle, forming a fast flexible process for new product development. Just as important, the new approach can act as a change agent: it is a vehicle for introducing creative, market-driven ideas and processes into an old, rigid organization.

And when you’re done with the article, pass it quickly down-field to the captain of your team. Remember, companies have been using and refining this way of working to beat you since the 1980s, so what are you waiting for? It will cost you 200 times that amount of money to go to the RWC final in Auckland and see the world championship of agile in action for yourself.

My thanks to Marcus Fazio, multi-national consultant extraordinaire, and Japanese expert who reminded me of this all important link between two of my favourite things. I’m sure Marcus, Takeuchi and Nonaka would all have enjoyed this fabulous moment from the RWC last month.

Japan's winger Hirotoki Onozawa runs to score a try during the 2011 Rugby World Cup pool A match New Zealand vs Japan at Waikato stadium in Hamilton on September 16, 2011. (Photo credit: GABRIEL BOUYS/AFP/Getty Images)

 

The real legacy of Steve Jobs

By Agile, Development, People, Technology

It’s not like the internet doesn’t have enough people regurgitating old Steve Jobs stories right now and despite personally being a shameless fan boy and wanting to give my little tip of the hat to Steve I’ve held back, until now.

There is a huge myth about Steve, that Apple = Steve Jobs. Of course he was a very clever guy, and from the outside looking in he seems like a much more hands on CEO than most. We get blindsided by the stories of his individual touch on products, as if the hand of God had reached down and then it was done. I don’t believe it though, not for one minute.

Steve’s major contribution was and is a culture, an ethos and a way of thinking about the world. The intersection of liberal arts with technology. The obsession with thinking differently, as a marketing catch cry and a way of working. He knew what great looks like and he set the bar, demanding that standard.

The thing is, with rare exception, at best teams and individuals only perform at the level of the ‘greatest’ work they have seen done. It’s a big part of how we learn – we mimic, we imitate and finally we own things. It’s why having one or two gurus in a development team can lift the level of the whole team. It’s why going to conferences, reading books and being actively involved in your industry outside your own company is so important. This is also why stagnant teams and organisations need new blood, new ideas and dramatic intervention to effect change.

Steve created an environment, a culture, where being obsessive about the little details was rewarded. Where it was ok to scrap things and start again. Where it was just assumed that even the best ideas would be iterated on, over and over again before they might finally see the light of day. Even then, very often we see a lean minimum marketable feature set in version 1.0 Apple products.

Steve’s real legacy was in creating a whole company of people who know what’s remarkable and what insanely great really means. That’s the lesson for the rest of us: make sure you really know what great looks like.

This post was inspired by Steve Jobs and the Eureka Myth at HBR. Also, if you haven’t seen it, make sure you check out the Stanford Commencement speech Steve gave in 2005.

Not just an IT thing

By Agile, Development, Lean, People, TechnologyOne Comment

Derek Sivers says we shouldn’t share our goals, or make them public, that the act of sharing our goals makes us less likely to achieve them. However, our experience with the teams we’ve worked with is that making public commitments to each other is a powerful motivating force.

With all things Luna Tractor we try to practice what we preach, plus eat our own dog food, so today we went public and launched a project to share the stories of agile and lean transformation at Lonely Planet.  At a lunchtime briefing with our friends at ThoughtWorks, we started to share some of the stories and photographs we have been collecting as the basis of an ebook about the remarkable business transformation at Lonely Planet in the last 5 years.

The book’s title, ‘Not just an IT Thing’, was inspired by Thoughtworks’ Lean business strategist David Joyce, who in early discussions with us was lamenting that so little progress has been made outside of software development with systems thinking, lean, agile and kanban methodologies, and that all too often agile was dismissed as “just an IT thing.”

To continue this, and share our progress in an agile way, our goal is to publish some of the photographs of Lonely Planet’s remarkable workplace on a regular basis as the content comes together.  Stay tuned to the blog for snippets and the team’s stories, and most importantly tell us what you think.

A note of thanks must go to everyone over the last 5 years who told us to ‘write it down!’ Well, your exhortations have been heard, and this time we’ve actually started.

Better or just Different ?

By Agile, Development2 Comments

This visualisation of Crayola Crayon colours over the last century got me thinking.  If I were a kid, drawing things with my Crayolas, I’m not sure I’d need all those colours.  In fact maybe I’d be pretty happy drawing stuff with just the same 8 colours that had been keeping kids drawing stuff for 32 years, from 1903 to 1935.

Very often when we’re tweaking as part of a creative design process, or trying to figure out the best way to organise our agile boards etc, we make endless small changes searching for perfection.  And we’re not making things better, just different.

I’m not saying you shouldn’t tweak, test, adapt and evolve.  That’s exactly what you should be doing, but make sure you’re making whatever system you’re working on better, not just different.  Developers should be writing unit tests, plus monitoring code coverage and complexity metrics.  Usability folks need to be actively testing and measuring the impact of their changes through customer usability studies and managers need to be engaged with their teams, rather than ‘command and controlling’ them to know when they are just making a mess.

Today when you’re going back and forwards on some choice ask yourself – “Am I making this better ? Or just different ?”

Subscribe to the Luna Newsletter

Close Menu

Quote of the week

The new competitive advantage is the ability to anticipate, respond and adapt to change.

Recent Luna Posts

Become Remarkable.