Category

Agile

Just like Bruce Lee

By | Agile, Food for thought, Organisation | No Comments

Just finished reading Dan Olsen’s book “The Lean Product Playbook”, after hearing him speak at the Leading the Product conference in Melbourne last week (his book is now firmly on our Luna Tractor MBA and available to borrow if you’re that way inclined). Other than being a damn fine guide on how to do “good product”, he made a good point early on in the book about learning a process and then customising it to make it your own.

Bruce Lee, philosopher and butt kicker

Bruce Lee, philosopher and butt kicker (from: goodwp.com)

He used the words of Bruce Lee to make his point:

“Obey the principles without being bound by them.” and “Adapt what is useful, reject what is useless, and add what is specifically your own.”

Firstly, quoting Bruce Lee is super cool. But beyond that, who’d have thought that us 21st century worker-bees could gain wisdom from a man most of us only know as a butt-kicking, strong and silent, hero type?

Olsen likened the learning of the process he had created to be similar to karate drills that students learn and practice on their path to a black belt. Once learned, it’s possible to move things around, “mix, match, and modify” to create something more your own.

The idea of learning something and then building on and improving it to make it your own resonates for me when introducing methodologies like Agile or Lean into an organisation.

Read More

The Luna MBA 2014 Update

By | Agile, Development, Disruption, Education, Lean, Organisation | No Comments

Two topics remain consistently popular on our little LT site… Agile Workplaces and the Luna MBA.  Just as we encourage all our clients and friends to keep reading and learning so we do ourselves and so we present some new reccomended additions to the MBA… If you’ve finished the current list then consider this extra credit for your degree.

Adapt: Why Success Always Starts with Failure – Tim Hardford

A remarkable, if slightly repetitive set of stories showing us the unpredictable path to true innovation. He starts with the story of Palchinsky at the turn of the 20th century who may have just invented Agile approaches analysing the Russian ecconomy even before the ship building yards of the first world war; Of course he was exiled to Siberia for his efforts. He also explores our aversion to variation and experimentation – the tendency for governments and corporate bosses to love large and grandiose projects instead. As Hardford points out the proliferation of iPhone and Android apps has hidden the uncomfortable truth which is innovation is harder, slower and costlier than ever before. All the easy problems have already been solved. I’ll leave you with a quote from the book to inspire you to buy and read it.

‘Return on investment is simply not a useful way of thinking about new ideas and new technologies. It is impossible to estimate a percentage return on blue-sky research, and it is delusional even to try. Most new technologies fail completely. Most original ideas turnout either to be not original after all, or original for the very good reason that they are useless. And when a original idea does work, the returns can be too high to be sensibly measured.’ Read More

Weddings, Parties and Agile!

By | Agile, People | No Comments

Do you think Agile is just an IT thing? Well you’d be surprised!  

It’s the 24th February 2013, and my girlfriend and I just got engaged.

I’m sure many couples planning a wedding can relate to the
“OMG moments” when realising that they have agreed to get married, but also agreed to plan this once-in-a-lifetime event, where everything will be beautiful and run more smoothly than a precision racing team.

Having run many projects and led large teams across multiple timezones – I seem less than puzzled by the thought of arranging everything. After all it’s just another project isn’t it? Wrong! At least that’s what my fiancé reminded me 🙂

I’ve spent the past 12 months myself on an Agile journey, learning the ways of visual management, lean and flow. With much gusto I pulled together a Trello board. I was excited, but not sure that my fiancé shared in my enthusiasm. None-the-less we pushed on and started to plan our wedding.

Wedding Trello Board

Read More

Self-Selecting teams – tales from WW2 Lancaster bomber crews

By | Agile, Organisation, People | No Comments
ePredix Office, Minneapolis, MN in 2001

ePredix Office, Minneapolis, MN in 2001

Back in the day, when I worked in the USA in a fascinating startup (then called ePredix, who were rolled into Previsor and are now part of SHL), I was regularly set on my chuff by one of our amazing technical advisory board members for thinking that anything at all under our digital sun was NEW, or that any of our 21st century science of Industrial-Organisational Psychology (in simple terms, big data about people, for hiring and development) could be viewed as a sure thing.

Our tech advisory board had every right to proffer those kind of opinions to a young economist whippersnapper, as between them they had invented several of the things the science was founded on!

The tools we were building at ePredix were online selection tests, delivered in short form on the web. We had patented ways (don’t get me started on patents by the way…) of serving up a couple of dozen multi-choice questions and then stack-ranking the applicants in their suitability in the role. Bloody clever, big data, but a PhD required to do the maths.

Lancaster crew WW2

One of my most memorable moments was at dinner one night when one advisory board member quietly advised me “you know, it’s all baloney really, you might as well just let teams self-select – they’ll be just as successful”. He went on to tell me of the Lancaster bomber crews of the RAF in the early 1940s, where after short training periods, Bomber Command were stuck with terrible problem of selecting the crews.

Their creative solution? Jam them all (several different flying disciplines, from multiple countries around the world) in a hangar or mess hall, and tell them they had 10 minutes to join a crew.

The result was some of the bravest, effective, well put-together teams in the history of the war. That said, the odds were against them surviving as a team – at the final tally, half the 125,000 young men had been killed or wounded in action, and nearly 10,000 became POWs. The crews had a fair idea of what they were in for – in some cases, 25% of intakes were killed in training.

With a lot of discussion at present about team self-selection in the agile world, it occurred to me the Lancaster bomber story was worth looking into again. Here’s Sandy Mamoli’s recent blog post on squadification at Trademe in New Zealand for example.

Lancaster by Leo McKinstry 2009I found this book by Leo McKinstry from 2009. Here’s the key quote that validates what I heard way back in 2001:

“Once all the initial course had been finally completed, the recruits were sent to an Operational Training Unit, where they began their real preparation for bomber combat. It was at the OTUs that the individual trainees formed themselves into crews for the first time. After all the formality of the previous selection procedures and examinations, the nature of ‘crewing up’ seemed strangely haphazard, even anarchic.

“There was no involvement from the senior commanders, no direction, no regimentation. Instead, the trainees were all taken to a large hangar or mess room, and just told to choose their colleagues to make up the 5 man crew: pilot, bomb-aimer, gunner, wireless operator and navigator. The engineer, who had to undergo specialised training, and the second gunner, would join at a later stage. Without any guidance or rules, the trainees had to rely entirely on their own gut instincts in selecting which group to join.”

Location 4295 of 12152 in Leo McKinstry, Lancaster, 2009 (Kindle Edition).

The book goes on to discuss the kind of people who made up the trainee group of Bomber Command – aged between 17 and 27, self-selected into the jobs (not conscripted), intelligent, inwardly motivated, with broad-based educations.

“They did not need leaders or formal structures” concluded Frank Musgrove in 2005 (Dresden and the Heavy Bombers).

This story sounds a lot like the thinking at Zappos at the moment around Holacracy, and other innovative organisations like Valve and Spotify.

As someone deeply involved in my own day job experimenting with REA-Group’s organisation with new ideas that change traditional leadership roles and formal reporting structures, I’m excited to find these kind of references. I see similar patterns in the world of rock bands and music – but that’s another blog post!

Let me be the first to concede that RAF Bomber Command is a horrific story, for both the crews and the millions of civilians who bore the brunt of this brutal military strategy on both sides of the war. But the extreme nature of the situation called for unusual methods to be applied – we should not ignore them today as we find old ways of running things coming up short and wasting time and money.

And as a grandson of a UK war veteran, I offer a moment of thanks for their sacrifice.

Inspired by Agile – A guest post from Avril Jean

By | Agile, Development, Education, People | One Comment

Avril is a talented artist and QA super star.  While we worked with her team she would always paint pictures to express what was going on.  In this very honest piece (re-posted from her own blog with permission) she shares the story of what it was like for her team to try Agile in words and pictures.


The department I work in (Technology) did a bit of an experiment last year to get agile software development going for a bit – that was a really interesting time to live through.

(If you want to bone up on Agile: wikipedia article is here)

We had two mentors, Nigel and James, who took us through the process – they took us out to the Lonely Planet (an interesting story of a company that went entirely agile in every team) to show us the workings, and they worked through our issues with us. I have nothing but praise for these guys, they know their stuff:

OLYMPUS DIGITAL CAMERAOLYMPUS DIGITAL CAMERA

I need to point out that this was not their actual heights or what they looked like. I rather think James was affronted by this picture! hehe.

This is their company website: Lunatractor

Basically agile is a way of an attempt to cut out the pointless crap around a project, allowing the teams to run themselves, giving everyone a say at allocating their own work, making the workflow obvious, and doing small, continuous releases of working software so that there are benefits straight up (releases every two weeks, known as a ‘sprint’).  This way you actually start to get the benefit of project immediately, not wait months for requirements, and every two weeks, a reassessment of the next most important bit of work comes in.

The way we ran it was a modified version of ‘scrum’: the work was assessd, broken down into small do-able units, written out onto cards, which were stuck on ‘the wall’. Each bit of work was a ‘story’, and the stories went through development, testing, etc cycle.

An example of a story: “As a member, all my leave without pay must be factored into my service”. Then we’d take that and break it down into the tasks we needed to do and how long they would take. The devs would develop it and i would come up with test cases and a way of testing it.

‘The Wall’ was the source of truth, and anyone could come and look at it and see the stories was we were working on. If you moved a bit of work on, you physically moved the card to the correct spot on the wall. It was a really good way of keeping track of who was doing what. If you worked on a card, you put your avatar on the card (we all were represented by a different picture).

OLYMPUS DIGITAL CAMERA

At the start of every day we had a 15 minute stand up, where we discussed what we would be doing that day. We used to run our stand ups sitting down cause we were all lazy.

All the team sat together and conversations happened all the time about the work.  Sometimes there was cake. My team appear to be obsessed with morning tea. This is not a bad thing.

01011139

Work was nutted out on the whiteboard, lots of yelling and gesticulation happened, and everyone knew at all times what they were doing. We all leveled up in how to interact with the other people we worked with.

It was a great project to work on. Of course, not everyone liked this approach, and it did not suit everyone as it was very different in mental approach to very traditional software development (lots of specs and paperwork).

At the end of each sprint we did a retrospective : what we did well, what we should do better next time, what the problems were.  The first few sprints were hard, very very hard. There were a lot of arguments. We had some defections from the team. There were some bodies – we put their little avatars into the ‘graveyard’ bit of the wall when that happened. By the end we were churning out 8-10 fixes and enhancements every two weeks, which was an incredibly fast pace – and we got no return prod defects from our work. Something to be proud of.

OLYMPUS DIGITAL CAMERA

Also at the end of each sprint we invited all the stakeholders to come to a presentation, which was usually prepared with much hilarity that day – this is me and Nancy and Erica getting the powerpoint slides ready:

OLYMPUS DIGITAL CAMERA

This is Mick and Aaron doing their very amusing presentation to the stakeholders at the end of their sprint:

OLYMPUS DIGITAL CAMERA

I attempted to do a presentation once but my public speaking is ATROCIOUS. I actually forget what I’m talking about quite easily and I also say “fuck” a lot when I’m stressed. IT DID NOT GO DOWN WELL.

We did very well and we got the backlog of work done, we fixed defects we found on the way, it was an excellent process.

Ultimately though my company is not an agile based company, and the methodology was misunderstood and not adopted.  We hit a lot of problems working against the status quo – Prince II methodology (which to me seems to be just moving shit around spreadsheets but not actually producing anything at the end of it – PLEASE can someone tell me why I’m wrong if i am!).

There have been a few more projects that have been done agile methodology, also with success, but the value is not really recognized and i doubt there will be more.

This picture represents the fight of us against the status quo.

01011106

I would not mind working for another company that does agile properly one day, though that being said, I’m aiming to get out of doing software and get into doing art full time. So back to what they call waterfall but what is actually V-model software development for me!

Such a pity!

Such inspiration, at any rate.


As a postscript since this was written Avril let me know she’s working on new agile project, and things are changing for the better.

Agile Encore – Workshop and Talk – Nov 14th 2013

By | Agile, Disruption, Education, Lean | No Comments

I talked about one of our favourite clients BAUM Cycles at Agile Australia 2013 in the middle of the year – It must have been popular because I’ve been invited back for the Agile Encore in Melbourne on the 14th.  I’m also running a workshop in the morning before the afternoon session – Here’s an insight into what you’ll get !

Afternoon Talk – Agile, Lean, Broken Ribs and a World Champion

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.

Admiral Rickover (father of the nuclear submarine) understood this only too well and long before the Toyota Production Systems day he 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 organisations or management systems, get things done.” – Rickover

Genchi Genbutsu – Go and See.

How then do we do this when more than 90% of us are creating virtual things – intellectual property, software, design or products – not something you can drop on your foot?

One of Luna Tractor’s most interesting projects over the last year has been working with BAUM Cycles. Their bikes are widely regarded as the Ferraris of the bike world, ridden by world champions who pay their own money and line up like everyone else. In a small, sometimes hot, often cold and dirty factory on the North Shore of Geelong, they have been steadily shifting the operation of the entire business to an Agile and Lean process.

With a blue collar workforce, most factory language unprintable and the background noise a constant mixture of Triple M and machinery; some different approaches are required.  Hear real world lessons about Lean flow, physical stock management; Agile sales and customer service along with who ended up with the broken ribs.  Get a sneak peak into the new factory design that we are currently building also.

You can sign up and see the rest of the program here – www.agileencore.com/index.html

Morning Workshop

In addition I’m running a workshop in the morning covering a wide ranging background of  Agile, Lean and Systems Think as it can be applied across a whole organisation.  This session will be great for beginners and experience agilistas alike with a focus on the background, and philosophy of Agile, Lean and Systems Thinking as well as interactive discussions about how to practically start using these approaches right across your organisations – not just in IT.

Full Details and workshop sign up here – www.agileencore.com/workshops.html

PS: Use the code ENCORE-JAMES to save $100 on the workshop.

Agile Australia 2013 Reflections

By | Agile, Communication, Customers, Education, Lean, People | No Comments

It’s become a bit of a tradition for Nigel and I to write some reflections after the annual Agile Australia conference.  This year Nigel was stuck at home in Melbourne, so it’s just down to me.

I felt like the conversation was much more sophisticated this year.  Lots of people talking about Agile and Lean in the same sentence.  Lots of folks grappling with their whole end to end program, budget cycle and corporate cultures.  A recognition that iterative test and learn approaches are the future no matter what your size or market position.  After many years focusing on techniques, frameworks and patterns this year there was a new focus on values, culture and the human element.

5 years ago the conversation was basically: can this agile stuff even really work ? Now it feels like a whole new breed of people are wanting to understand and embrace Agile, and it feels much less cynical and defensive on their part this time. This is a promising evolution though it does mean I’m going to have to stop making jokes about a few companies like Telstra who have not only seen the light but are working bloody hard to change their course.

A couple of conference highlights for me:

Dave Snowdon – Cognitive Edge – Smart grouchy man; he hurt everyone’s brains… Understanding how we humans think and process information is really important.  Something Dave and his team are exploring is the idea of capturing what users want or are experiencing through micro narratives.  Stories.  If you want to know what your company is really like ask someone the story they would tell their best friend.

Ryan Martens – Rally Softare – An elegant and heartfelt call to action for engineers to think about how they can use their powers for good and not evil.  The world has many big and complex problems and if we can combine basic human empathy with our engineering chops and the scientific method, then maybe, just maybe we can make the world a better place.  Seeing an MRI machine turned into a pirate ship so that kids wouldn’t be so scared to go into it was a beautiful example of empathetic insight.

The reception for my own talk about applying Agile, Lean and Systems Thinking approaches to a small Australian high-end bike manufacturer was very gratifying too.  I’m not sure if the session was videoed, but I promise I’ll write about the story here soon for the people who missed it.  For anyone interested in seeing BAUM’s transformation in person just get in contact and I’m sure we can organise a field trip to Geelong.

Agile history article on ITnews.com.au – why the time is NOW for agile

By | Agile, Quote | No Comments

Vlamingh_ships_at_the_Swan_River,_Keulen_1796I was kindly invited to submit an op-ed for IT News’s week of features on agile in Australia, and took the chance to outline my opinion that agile will continue to reveal itself as a black swan for modern business.

You can head over there for a full explanation of black swans and the white lies that result from their discovery. You can also learn why I have put a 300 year old painting of Perth on our blog!

In a nutshell, the uncertain and sometimes brutal business conditions we face today demand a new approach, and we are lucky enough to have Japan’s vast lean industry experiment from the 1960s onward to learn from, as well as the pioneering work done by agile IT professionals since the 1990s.

However <sigh>, as James often quotes from Deming – ‘It is not necessary to change – survival is not mandatory’.

Shaping IT Organisations: CIO Strategy Forum presentation by Nigel Dalton

By | Agile, Lean, Organisation, People | One Comment

In which the 3rd Reich*, the Catholic Church, and Monty Python are resoundly thumped by William Edwards Deming in the race to design a healthy, productive IT organisation for the 21st century.

Third Reich example of extreme flat organisation structure

By the time this is published I will have presented the results of many hours research, debate and reflection on the design of modern IT organisations. Sadly, without actions and interpretive dance, the Powerpoint slides on their own don’t add up to much more than pictures. Invite me (or James!) for lunch sometime, and we’ll happily proffer an opinion on the subject.

The pivotal moment in the thinking process came when reading the new book from JoyceThe essential deming by joyce orsini Orsini, a deftly edited collection of Deming’s lectures, missives and thoughts from 1950 to 1992. A brilliant book, it is the closest you’ll get to Deming sitting with you and giving his opinion on a wide range of important matters. Including, organisation structures!

Deming’s simple idea (quoted in a 1992 presentation to General Motors) was to avoid traditional organisation charts in the form of hierarchical pyramids, and replace them with flow diagrams (aka value stream maps), and just put the people on the flow diagram as value was pulled by a customer. So simple!

“A flow diagram is actually an organisation chart. It shows people what their jobs are. How they should interact with one another as part of a system. Anybody can see from a flow chart what their job is. Take the chart, put the names on it. You belong here. Somebody else belongs here. Then anybody can see from the chart what their job is. And their work fits in with the work of others in the system.”

Compare that to the Hitlerian view of a flat organisation (so inexplicably popular since the 1990s, with ever-expanding numbers of direct reports), with this lightly edited paragraph from Wikipedia on the organisation of the 3rd Reich. The grey bits are the changed words. If this sounds like your IT department, run!

‘The CIO often deferred making decisions, avoided clear delegation and allowed subordinates to compete with one another, especially in the recent years. Therefore, a system of governance was formed whereby leading company officials were forced to interpret the CIO’s speeches, remarks and writings on company policies and turn them into programs and strategy.

Any manager could take one of the CIO’s comments, and turn it into a new strategy, of which the CIO would casually either approve or disapprove when he finally heard about it. This became known as “working towards the the CIO“, as the executive was not a coordinated, co-operating body, but a collection of individuals each trying to gain more power and influence over the CIO. This often made IT executive meetings very convoluted and divided, especially with the CIO’s vague policy of creating a multitude of often very similar posts.’

This is also an opportunity to put the many references given in the 30 minute talk, and used in the research, in one handy place. Enjoy.

Reading List

  1. The Management Century by Walter Kiechel III, published in Harvard Business Review, November 2012.
  2. The Essential Deming: Leadership Principles from the Father of Quality (2012) by Dr Joyce Nilsson Orsini. Available as a Kindle book, this is the only place I have read Deming’s theories on organisation structures and the negative impact of org charts.
  3. Value Stream Mapping – understand the theory of this special variant of process map
  4. Management 3.0 (2011) by Jurgen Appelo.
  5. Godwin’s Law by Mike Godwin, 1990. ‘As an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1.’
  6. Scaling Agile at Spotify (2012) by Kniberg and Ivarsson.
  7. Power to the Edge (2003) by Alberts and Hayes.
  8. Here Comes Everybody (2009) by Clay Shirky.
  9. The Principles of Scientific Management (1911) by Frederick Winslow Taylor.
  10. The Theory of Business Enterprise (1904) by the Thorsten Veblen (the witty economist who invented the concept of ‘conspicuous consumption’ among other things). Best read in Wikipedia.
  11. General and Industrial Administration (1916 in French, 1946 in English) by Henri Fayol. Had Henri not been French, and writing at a tricky time in world politics, his ideas might have spread sooner. Similar to Frederick Taylor in many ways.
  12. Conway’s Law by Melvin Conway.
  13. Servant Leadership – best read about in this chaotic Wikipedia entry which features American Robert Greenleaf’s work.
  14. Peter Drucker’s contribution to management and organisational literature in the second half of the 20th century was biblical. The HBR article above does a great job at summarising his influence, or you can buy this book on Amazon.
  15. The reference to the 3rd Reich organisation structure and model can be found here in its original form (not adapted for CIOs).

Is the impact of Agile just a Hawthorne Effect ?

By | Agile, Communication, Strategy | One Comment

L1001888The Hawthorne Effect is a human behavioural theory drawn by various social scientists from trials undertaken between 1927 and 1932 at Western Electric’s Hawthorne Works.

The trials found that improvements in behaviour, and productivity changes observed after adjusting a workplace, were in fact largely just the results of a placebo-type effect – any change seemed to cause improvement.

There were many changes trialled – the first (and possibly most important) were changes in lighting levels (‘the illumination experiment’) in a factory environment. The objective of the experiment was to find the optimum lighting level for productivity – the results showed that more was at work than just changing lumens, every change (up or down in brightness) caused an increase in performance.

Most theorists since have concluded that the improvements are caused by the act of measuring and engaging subjects.  If you missed studying this in your management 101 course, then read this article or take the slightly incomplete wikipedia catch up lesson and then continue reading.  Lets deconstruct the impact of this theory into its parts:

Measurement

We’ve already written about the impact of measurement before.  It’s also pretty well understood that humans perform against whatever KPI you give them, the way they do it may however be surprising or unintended.

Confirmation Bias

Then there is Confirmation Bias, basically the likelihood that you will both find what you’re looking for, and ignore stuff that you’re not.  Elegantly illustrated by this group of Radiologists who can’t find a Gorilla in their scans.  If a team expects a new process to be better, then their perception will likely match their expectation.

Empowered Staff

Finally the staff in the later trials, more focused on workplace layout and reward were engaged, they were part of the process.  They were made to feel special.  We’ve talked about this a fair bit too – though Dan Pink is more fun. Smart people are motivated by Autonomy, Mastery and Purpose. Pink was not the first to the conclusion that money was directly linked to productivity.

In summary, if you measure stuff, look for a change, and then make people feel special – surprise, surprise, you’re going to see a change!  Does this mean that some of the impact of Agile, the dramatic increase in staff engagement and useful productivity are perhaps just caused by the visual changes in the offices and agile rituals, but, in fact are just a ‘Hawthorne Effect’ ? In my heart, I have to say nervously, yes, at least to some extent.

Is this bad ? No.

Ok, but is the change real and sustainable? Yes, the changes and improvement in your team’s performance and culture are real.  Like all placebos, the source of the change might not be real, but the impact is.  If we can come up with better or different ways to achieve the same improvement then we should try them… any good agilista will tell you that anyway.

In the mean time I’ll leave you thinking about a sobering equation Nigel sent me as we’ve been debating this recently.

Hawthorne > Maslow + Deming

hawthorne effect workplace

Agile, Lean and Systems Thinking – What’s the Deal?

By | Agile, Lean, Strategy | No Comments

A Luna Tractor client asked me the other day, “What’s the relationship between Agile and Lean? How do you know which to choose?”  It’s a great question and the answer is actually pretty simple: most of the time you need to apply both. In fact we would add Systems Thinking to the list and suggest that you need to think hard about how to apply the right aspects of all three disciplines to your problem.  So how does it work?

Lean – How to do the least work while maintaining value.

Agile – Habits to create an adaptive, incremental development and learning cycle.

Systems Thinking – Solving problems by viewing the problem as part of a system, rather than a broken part.

What does applying all three look like?

All three value humans as a key part of the system.

All three value customers as the key driver of the system.

Use Systems Thinking to define your approach, use Agile habits to solve problems and use Lean priciples to tune and refine your resulting system.

What software people can learn from great Lego design – YOW 2012

By | Agile, Communication, Development, People | One Comment

Lego software design rule 1: design only in white bricks

At YOW! Australia in Melbourne I had the pleasure of introducing and getting to know John-Henry Harris, a product designer at Lego in Denmark. Originally from the UK, his passion for product design, and a love of Lego saw him land the job of many designers’ dreams at a young age.

His talk was about design and innovation, and I was struck by the parallels to the non-brick world – which is why YOW had him at opening spot on Day 1 of the conference’s agile stream of course!

John Henry Harris Lego dragons

Here’s 14+1 Lego design and innovation principles to consider (John Henry has kindly added a 15th in response to our blog post):

  1. Design using only white bricks: as you can see from the illustration above (my very own resident lego designer’s handiwork), making something look great with only white bricks is HARD. Your model immediately goes a bit flat, there’s no flashy accents of colour to rely on, and no detail – the essential form must stand on its own two feet. Then, when you get the design right, add colour a little at a time and ensure every colour adds some value. In software land, think Balsamiq over Powerpoint as your IDE.
  2. No new bricks – treat this constraint as a challenge to your inventiveness. Of course
    They look similar, but do quite different functions.

    They look similar, but do quite different functions.

    every designer wants new bricks developed to enable a special corner or moving feature of their model, but the cost of moulds and development is high, think tens of thousands. Now, Lego certainly isn’t shy of investing in new brick designs, as the Star Wars series shows, but every one must be heavily justified and be widely re-useable. Sound familiar to any Open Source guardians of the core application code? Every Lego designer also knows that somewhere in the world, their name is being cursed when a model rebuild is foiled by a failure to find the exact, rare, tiny 1 x 1 brick needed – the one with the hollow back and a rebated front side, rather than a stud.

  3. Always make options to test. John-Henry told us the story of a Lego technic bulldozerbulldozer model, where from Day 1 the team decided they would build two discrete options – a highly featured, and slightly larger model; and a smaller one, that used up a chunk of the design budget by adding a motor and some moving parts. The team felt confident that the test audience would choose the scale and functionality of the larger, non-motorised model over the mechanised version. Doubtless they even wondered out loud occasionally about the sense of going through the complete design process for 2 things almost the same, when one was clearly the superior product. The final result is above – mechanised won the day, against all predictions. Size ain’t everything.
  4. Involve your customers in design: Lego makes a habit of bringing in realLego-Emerald_Night_Train customers to co-create some products and solve tough engineering problems within other lines. In 2009 the Emerald Night train set was the first train to be made in many years from the standard Lego system, and AFOLs (Adult Fans of Lego) with expertise in trains were brought in to work out solutions for motor durability and help with engineering of the set. That is so much more than sending out a research team or conducting a survey on your website – do your products have enough goodwill and the love of your customers to ask them to be involved with design? Have you the humility to work alongside them? Chances are we’ll all spend big dollars on ‘consultants’ instead.
  5. Work in teams. Here’s a major overlap between Lego product design processes and agile software design and development. Multi-disciplinary teams are core to the innovation and design process in both places. There is a team space, shared and individual work environments, plans out in the open. I think our world of business agility is starting to understand the power of this – the Activity Based Working (ABW) movement in architecture is starting to build environments to suit a collaborative work style (with BankWest in Perth being one to see if you want your socks knocked off by futuristic socio-technical building design).
  6. Marketers and designers sit together from Day 1. It’s a subset of Principle #5 I suppose, but so often missed in software development projects. The diversity of personalities just adds to the creative environment, and much time is saved having the ‘go to market’ people in the room. This is grossly absent in most projects relying on software development to succeed. Marketing are too often the team on another level or in another building.
  7. Test with real customers – kids! A great story came up at YOW! to illustrate whether you really
    One of JHH's Creator sets (Fiery Legend) - showing one of the 3 dragons you can make. Re-use makes design so much tougher!

    One of JHH’s Creator sets (Fiery Legend) – showing one of the 3 dragons you can make. Re-use makes design so much tougher!

    know your customer, or whether you’re only making what your well-meaning product owner or business analyst has had inspiration to build for a perceived customer need. Testing Lego dragon designs (I think it was a dragon, might have just been a monster), the team waited anxiously to see of the efforts that had gone into the engineering of an upright walking beast had paid off. It had been a huge mechanical conundrum, constraining the leg joints with pieces drawn from sets across the group – a masterpiece in design. The end result was a shock to the team – to paraphrase the children’s choice: “why would we pick a dragon that walks, when this one fllliiiiesssssssss…” as the child picks up another model and simply swooshes it through the air in their outstretched hand.

  8. Take pride in building to a cost envelope. This follows on from Principle #2 to some extent, and  I reflect is core to many arguments I have witnessed in the past over the benefits of agile methods of working. The simplest resolution of the “how much will this damned thing cost me?” standoff between product owners, accountants and IT is to promise to deliver the highest priority features within an envelope of money. As Dave Thomas wisely once said: “budgeting is easy – simply find out how much money is your CEO willing to bet on this idea”. Building to a cost is an up-front constraint at Lego, and people’s energy goes into designing an innovative solution that kids will love, not fighting over budgets.
  9. Have coaches – coaches are part of the team at Lego, and designers get to spend time being a Technical coach or a Model coach. For many of us in agile-land, coaches are too often one row too many on a budget.xls file. How exactly do we expect to develop our skills at working with agility, which is a mindset founded on continuous innovation and improvement? Maybe to keep costs down, just one person on the team is nominated to read a book on agile, or get certified? Luna Tractor’s experience has been that your optimism will not pay off.
  10. Design rules come from deep user insight – if you are a Lego nerd like me, you
    Another JHH Creator set - 3 radically different cars from the one box of bricks.

    Another JHH Creator set – 3 radically different cars from the one box of bricks.

    will doubtless marvel at the instruction books, where no words are used to ensure universality of the document. But one thing you may not have noticed is a subtle product design rule around very similar parts being required in the same small build sequence. Say, a 1 x 6 and a 1 x 8 red brick. Not allowed! Why? Because a child searching for a 1 x 6, then a 1 x 8 brick amongst the tipped out packet of 200 bricks in a set is going to get frustrated, repeatedly finding and attempting to fit the wrong brick. Which to a young child looks like the right brick. Apple iTunes 11 developers, are you listing to this?

  11. The hardest products to design are the ones where re-use is mandatory. The Lego Creator series is a tough assignment. Essentially, 1 box of bricks, 3 different models within a theme required. With as few bits as possible left over after each model. Think code re-use is a challenge?
  12. Build with your left hand, or with gardening gloves. That is how far the Lego designers will go to emulate what it is like to be 4 years old and trying to pick up and manipulate the smaller pieces in the Lego sets (for kids just graduating from Duplo). In software, how often do we think of constraining our skill when using and testing our product? We’re all whiz-kid digital people, do we really imagine we can know what it is like to be a ‘normal’ person? When was the last time you explained search engine optimisation or the internet to a friend from a non-IT world?
  13. The Lego design team reviews the product – just like a retro/showcase, and you’d better be ready to have your say. With Lego, products may stay in design mode for months, and I dare say that it gets tedious, even for a Lego-nutcase to have to rebuild the same item over and over for weeks at a time, searching for better ways and faster, stronger engineering solutions. The team provides the context, the support and the feedback so that invention can be turned to innovation. Problem-solving is so often a team exercise in both our worlds.
  14. Every product can be analog and digital, so be open to options. The design team working on Lego’s Ninjago models used story-telling to develop characters and context for the individual mini-figures. Their clever solution to stimulating their ideas was to hire a cartoonist, who would sketch story boards and story lines and put them on the wall. Now, art imitates life, whichScreen shot 2012-12-16 at 4.23.45 PM imitates art, as the Ninjago TV series is a great success alongside the toys. Traditional merchandising turned on its head! Do you have the creative bandwidth to imagine games, video, books, and social media as well as your starting software product? Or is that someone else’s job in your company?
  15. Have fun – play is an essential part of the process of invention and innovation. You can see John-Henry talk on this subject at TedX here. I opened the day with a quote from JHH’s website: “We don’t stop playing because we get old, we get old because we stop playing” – George Bernard Shaw.

And when you’re as good at playing as John-Henry Harris, you might one day create something as awesome as this. Santa, are you listening?

1962 Volkswagon Campervan in Lego by John-Henry Harris.

1962 Volkswagon Campervan in Lego by John-Henry Harris.

Genchi Genbutsu – Go and See

By | Agile, Communication, Lean, Space | No Comments

ImageTaiichi 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.

Ground Hog Day

By | Agile, Disruption, Strategy, Technology | No Comments

I just saw this graphic of American Print Newspaper Advertising (adjusted for inflation) and had a strong sense of deja vu:

Exhibit A: Newspaper Ad Revenue in the US

Exhibit B: US Recorded Music Revenue in the US

Business Insider points to journalist Jay Rosen’s comment that the peak for Newspaper Ad sales lines up with the birth of blogging online.  I find it fascinating and terrifying that we see this same pattern of the rapid disruption of business models, with industries succumbing to seismic changes being repeated time and again across unrelated verticals.

The speed of the change can result in the digital companies that inherit the previous analogue dinosaur’s world only working in a market a fraction of the size of the old industry. The money, and the consumers, just go elsewhere.

Chaos theory shows us how small changes in the fundamentals can cause such different results in otherwise deterministic systems, and that the changed results are often so dramatically different that it is likely to be impossible to predict. Not even in your 5 year plan you paid consultants to write I’m afraid!

Nigel and I have thought about this quite a lot in the past when we invented our Dalton-Pierce Disruption Quotient.  Indeed it was one of the drivers for starting Luna Tractor itself.  Predicting these changes is one thing, but learning how to respond faster is really the only thing you can control. Resilience and speed to learn are the new competitive advantages.

The lifecycle times for industries and business models are getting shorter too. Maybe they relate to the build time of a dynasty or maybe something else – cultural inertia, stickiness or just a generational change.  Older, more traditional businesses (like newspapers, broadcast TV or music) may take 50 years to build and 10 years to decay.  Younger inventions like fax machines have already come and gone, along with many early dot comm successes (MySpace anyone?).

The early giants of computing are all fading fast or changing their business model. With Apple selling more iPads in the last quarter than any computer-making rival sold laptops or desktops, I’ll have a bet (with anyone that will take it) that computers are next … via Ars Technica

Exhibit C: Sales of Smartphones and Tablets vs Computers.

Apple and their iPhone commands around 80% of the profit from Smartphone sales while all the other makers struggle to sell units at any price (note Samsung is a minor exception to this, Apple and Samsung are the only games in town really, hence the large fuss over their recent court dealings).  Google tells us that we search more on our phones than on our computers now.  Where is the peak for Smartphones, and I wonder what will disrupt them?

WHY ?

By | Agile, Communication, Customers, Development, Disruption, Lean, People, Strategy | No Comments

At various times I’ve heard Fiona, Nigel and myself telling people “If you only adopt one Agile practice make it the retrospectives” … But why ?

The boards are useful, but they are really just give you a prompt when you talk at your stand ups, and those are just an efficient way to make sure everyone is communicating.  While the demos and showcases give some social incentive to produce real things and check your progress over a useful timeframe (weeks not months or years).  But … The retrospectives (or reviews), that for me is where the real magic happens.  If you never stop to check, to ask how things are going and question why things are the way they are, why you are doing things and what you should do next in response then you risk having  the veneer of an Agile process which is either just micromanagement on the wall, Waterfall or perhaps worst of all, no real plan at all.

Being Agile isn’t enough.  Being Lean isn’t enough.

It’s all to easy to build and do the wrong things very well and very quickly using these techniques.  Perhaps the single most important thing is that your CEO, your leaders, your product people and you need to understand, ask and articulate is WHY you’re doing things.

If it’s a statement about profit and growth, start running. The powerful WHYs come from passion and insights from your customer (or potential customers if you’re doing something new).

WHY –> WHAT –> HOW … Simon Sinek

There are two standout statements in Simon’s TED talk.

“People don’t buy what you do, they buy WHY you do it.”

“There are leaders and there are those that lead. Leaders hold a position of power or authority, but those who lead – inspire us. We follow those who lead not because we have to but because we want to, we follow those who lead not for them but for ourselves.”

Too many companies and individuals talk about what they are doing, the great ones talk about why.

Luna USA Field Trip: Kanban ice-cream – the case for limited whip?

By | Agile, Customers | No Comments

In the delightful Hayes Valley in San Francisco, you will find a myriad of little design shops, clothing stores and cafes. Cheek by jowl 3 storey houses line the streets, and with lovely parks and a 20 minute walk to the city, it is the chosen neighbourhood of the new San Francisco dot com generation and their offspring.

Which leads to an interesting business problem on a sunny Spring day. The best ice-cream in Hayes Valley comes from an ice-cream stand in a mini-park half way down the main street. And they make their ice-cream ON DEMAND. Yep, on the spot, from fresh ingredients.

‘Why the hell would you do that?’ I can hear you asking! Well, it is novel (it took the inventor years to perfect the process and the machines); the customers love it (kids marvel at the dry ice-powered machines and the smoke coming off them); there’s no wasted production; and it tastes great.

Four operators manage 4 machines, making the cones and small tubs of icecream in 4 flavours – 3 standard, and one special of the day. Each fresh batch fills 2-3 smallish tubs at most.

Now what is amazing is that as people wait for their ice-cream, there is hardly any whining, whinging, tears, eye-rolling, skirt-pulling, or toys thrown from (adult) prams at all. Everyone seems pretty calm, even though the queue is 20 people deep, and the waiting area is full. And we are waiting for ICE-CREAM!!!

Nobody is hassling the staff as to where their order has gone, and people are adjusting their expectations with sanguine anticipation.

How does this miracle of customer service occur?

Here’s their high-tech system – did you spot it in the first photo?

Four swim-lanes for flavours. Different coloured cards for flavours. The order written on the card. Names go on cards. Customers can read the cards and see where their order is up to in the queue – they don’t need to interrupt anyone to ask where their ice-cream is at!

Customers can adjust their order at the start based on trading off a smaller queue with a choice of flavour. Want it quick? Choose vanilla right now.

So the next time your customers are behaving like 3 year olds at an ice-cream parlour, check to see if your agile board is as good as Smitten’s.

Luna USA Field Trip: the lunar lander – minimum viable product

By | Agile, Space, Technology | No Comments

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.

Luna USA Field trip: more skunkworks reflections

By | Agile, Disruption, People, Strategy, Technology | No Comments

Like so many exhibits in the Smithsonian Air and Space Museum, this plane is not a replica, a copy, or a later model. This actual plane is the very first jet fighter produced by Lockheed Martin’s skunkworks team.

The 14 rules of the Skunkworks, written by Kelly Johnson of Lockheed Martin in the 1940s are are clear antecedents of the 2001 Agile Manifesto, and the Agile Principles behind the manifesto.

Kelly Johnson congratulates the test pilot for the new Lockheed Martin jet fighter, the same plane pictured above 60 years later.

James talks about Skunkworks in our YOW! presentation, which you can view here on the YOW! site.

Kelly Johnson, the leader of the Skunkworks organisation, had one core principle – everyone needed for the design, build, testing and launch of a plane would be in the team, and in the room. Engineers, pilots, welders, engine-makers, contractors.

This principle was brought to bear on the Allies’ big business problem in 1943 – the Germans had developed a jet fighter, capable of 50% more speed than a British Spitfire and the famed US P51-D. Eschewing the usual ‘big design up front’ period for a new plane, they went to work in a hangar and 143 days later were flying the first US-manufactured jet.

One of the secrets of the speed to market of the design was the way the plane was constructed. The tail piece, which contains the engine, could be folded back in several simple panels to reveal the entire jet unit for servicing or replacement, allowing rapid changeover and trying alternate designs.

The customer problem. For solution, see above.

At the Smithsonian, they have the problem and the solution arranged side by side in an exhibition honouring the jet engine and the Lockheed Martin’s amazing new approach to product development.

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

By | Agile, Disruption, Strategy, Technology | No 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 | Agile | No 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.

Quote of the week

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

Recent Luna Posts

Become Remarkable.