Skip to main content
Category

Communication

Bell Labs – Innovation

By Communication, Development, Disruption, Organisation, People, Strategy, TechnologyNo Comments

I fear this will not be a popular blog post, for two reasons: one it’s too long and two it raises some inconvenient truths as we consider how to drive more innovation in our organisations. I am however on a sabbatical reading and thinking hard about these things… Experience is what you get when you didn’t get what you wanted.

Beginning with Alexander Graham Bell’s invention (and monopoly making patent) of the telephone it’s hard to point to a group outside Bell Labs that have been more responsible for shaping our society today (granting that the Xerox PARC Labs took the torch and ran with it as the flame at Bell started to die out in the 70s) we’re talking about the group of humans that invented telephone, valves, electrical cables of all kinds, radar, the transistor, microwave, the unix operating system, lasers, optical fibers, CCD chips and celluar mobile networks and on and on.

Curious isn’t it – a telephone company and a photocopier maker have defined the information age. Also interesting is that Bell Labs perhaps even more so than the PARC group at Xerox were very keen to understand how to measure and turn innovation into a process. Sound familiar?

“Of its output, inventions are a valuable part, but invention is not to be scheduled nor coerced”; experimentation was to provide an environment for “the operation of genius” – Harold Arnold, the first leader of the new R&D group talking about his team.

By taking a long-term, first-principles, research-based approach to innovation the Bell Labs did indeed discover, invent and innovate nearly all the fundamental building blocks we now take for granted as routine technologies driving the information age. There were a number of distinctive and consistent elements of the Bell Labs system:

1) The distinction between theorists and experimentalists. The most effective research groups combined both skill-sets, and they rarely sat with one individual.

2) Co-located and cross-functional teams. Kelly (the bloke in charge) was combining chemists, physicists, metallurgists, engineers, theoreticians and experimentalists. The leaders of these new structures were unconventional too: younger, bolder; not just the longest serving or more ‘senior’ member of the group.

3) There were no closed doors. Total transparency was expected, as was a willingness to help a colleague if required, no matter your level.

4) Progress was made by groups, not individuals. There were of course a few brilliant minds across nearly a century but like most good stories, a few heroes take the credit for a large group of people working effectively together.

5) Two principles…
i) If you haven’t manufactured the new thing in substantial quantities, you have not innovated.
ii) If you haven’t found a market to sell the product, you have not innovated.

The term ‘innovation’ dates back to the sixteenth century in England. It described the introduction of a new idea relating typically to philosophy or religion. By the mid-20th century we begin to see the words innovate and innovation applied to technology and industry.

If an idea leads to discovery, and if discovery leads to invention, then an innovation is the lengthy transformation of an idea into a product (or process) suitable for widespread practical use. Almost by definition, a single person, or even a single group, cannot alone create an innovation.

The early days of any innovation are typically underwhelming, even demoralising. The first valves were very difficult to make, not durable and not always reliable. The first transistors (a device we take for granted in their many millions in all our every day electronic devices) were very difficult to make, not durable and not always reliable.

Even the lawyers at Bell were trying to ‘quantify’ or find the patterns in their innovations. They only found one consistent pattern – their staff with the most patents (signed over on day one for a crisp $1) had breakfast or lunch with Harry Nyquist. Harry wasn’t the source of specific ideas; it turns out he was just really good at asking good questions.

Let’s also consider for a moment the non linear nature of invention. Shannon, an employee of Bell Labs who wrote “A Mathematical Theory of Communication,” (better described by Scientific American as ‘the magna carta of the information age’), went on to study chess-playing computers in 1949 (before computers were invented): a fairly frivolous pursuit for a telephone company. In his own words: ‘what if we might create machines capable of logical deduction?’

Back to their process. Broadly, the ‘system’ at Bell was divided up like this. 1) Research. Scientists and engineers creating a reservoir of completely new knowledge, principles and materials, methods and art.
2) Systems engineering. Using the new knowledge to look at how to integrate the possible, plausible, necessary and economical ideas.
3) Manufacture. Engineers developed and designed new switches, transmission system and so on from groups 1 and 2.

The handoffs between the three departments, however, were often (intentionally) quite casual – part of what made the labs ‘a living organism’. Physical proximity was everything; people had to be near one an other. Phone calls alone wouldn’t do.

A system carefully curated

As much fun (and cultural benefit) as there is in a hack day, it can’t be your innovation strategy. Also, innovation doesn’t best happen in a secret lab (unless that lab has ALL the people required for the whole end to end – perhaps Apple or Lockheed Martin). There does need to be a critical mass of talent; very very rarely do big innovations come from a single individual. Sometimes a revolutionary idea, yes, but not ultimately delivered as an innovation.

We’ve written about this before: too often we are focused on iterative improvement, not innovation. I’m reminded of my favourite quote:

“The problems of the world cannot possibly be solved by skeptics or cynics whose horizons are limited by obvious realities. We need [people] who can dream of things that never were.”

– John F Kennedy

Full credit to Jon Gertner’s ‘The Idea Factory’ for an insightful history of Bell Labs.

 

 

 

Collaboration Here There and Everywhere

By Agile, Communication, Lean, Organisation, People, remoteNo Comments

There’s nothing I like better than using a physical wall to make a team’s work visible and communal, indeed one of our most popular blogs is about the physical working environment and it’s impact on team communication.  

Luna Tractor’s predilection to the realm of the physical world and our obsession with beautiful stationery often leads us into passionate debates on using physical walls versus digital tools for visualising work.

It may however interest readers to know that ‘back in the day‘, (a phrase I can now confidently associate with the dawn of Agile software development as it’s been over two decades!), as soon as digital tools were available to manage things like User Story cards, we (and by we I mean I) jumped onto them immediately. Most ‘agilistas’ around that time were fast adopters of new ‘Agile project management tools’, many of us were fighting objections that you couldn’t possibly manage a software project without some kind of digital tool. I can’t tell you how many MS Project plans I saw with a bunch of two week iterations wedged into them like a neat set of stairs. As well as being a bung tool for project management, we had found yet another task it seemed to fail at — Agile project management. 

Putting aside the tooling debate, an even hotter topic is that of co-location and Agile teams.

An increasingly common workplace trend is orgs extending flexible work conditions to their people. A lever of engagement and also a gesture of human decency, more companies are becoming ok with regular work-from-home, and also work-wherever-you-choose arrangements. Like all of you out there, we can see the world changing, and organisations becoming not only more customer-centric, but more human-centric and valuing the individuals working within ‘The System’. 

As proud Systems Thinkers we are joyed by this, but we are working for a number of clients that are too often panic stricken when they perceive that the collaboration that we advocate and teach, comes with undertones of ‘everyone back to the office’ and over eagerness to index towards the ‘co-located’ principle of the Agile Manifesto.

In fact, it is possible to interpret three principles of the manifesto; numbers 4, 5 and 6 as contradictory, and almost discriminatory in their nature. 

#4 “Business people and developers must work together daily throughout the project.”

What if the team cannot be together daily, are they not an Agile team?

#5 “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Why couldn’t we trust the team to chose their own environment and be where they want to work that’s most productive for them instead of demanding co-location?

#6 “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Will people who chose remote working be damned with a moniker of less efficient and effective in our Lean and Agile ways of working? Are Systems Thinkers opposed to remote team working? And can remote flexible workers never be successful at Lean and Agile ways of working?

Luna Tractor advocates high levels of collaborative and collective work, for solving complex problems. Why? 

We understand the challenge of conveying tacit knowledge and learning to a virtual world.

It’s a common belief that knowledge is something that can be represented in words, visualised in pictures and taught, however this isn’t always the case. Tacit knowledge is by it’s nature difficult to communicate. Tacit knowledge is deeply rooted in action, commitment, and involvement.

For example, I may study Turkish language by reading a book and practicing a lot, but living in Turkey for two months had me conversing with Turkish people — even though there was a lot of hand waving going on. I can study the attributes of great leaders but I won’t pass muster as a leader without the opportunity to experience leadership myself. I can cultivate my own view of what is aesthetically pleasing but I cannot easily transfer that ‘eye’ into another person. Languages, leadership, aesthetics all fall into categories of tacit knowledge, and along with the desire for innovation, emotional intelligence, body language, intuition and humour, we tend to stack these challenges up as more reasons to front up to the same office with your co-workers every day. 

Or… are we just being lazy about it?

Look around a little and you’ll find companies that are reaping the benefits of not only allowing remote and flexible working but openly promoting and embracing this workplace trend, these are companies that have also embraced the collaborative working practices of Lean and Agile.  How are they doing it and what are the factors that are making them successful? I’ve been fortunate enough to work at a couple of these companies.

In 2016 I worked at REA Group, the digital giant behind successful property website realestate.com.au. They have been presenting at conferences for years on the innovative ways they integrated distributed development into their Agile software development operation. Working with around 100 developers in Xi’an in China, their teams have virtual portals into their space via large screen ‘always-on’ video connections. They consciously invest in creating positive team culture by funding travel back and forth during the year and all manner of fun joint activities like virtual cake for birthdays and celebrations. To see these teams when they get together physically, it’s akin to witnessing a family reunion, the team members speak of each other as treasured friends. 

In my team at REA Group we had a developer who had to relocate to Sydney for family reasons. We didn’t want to lose her and asked her to trial remote working. Pleasingly she did and still does a year later, visiting Melbourne every month or so. Since then the same team has had a member working remotely from Russia, and one that has been working from all over the world as he tours with his fiancé — a member of Cirque du Soleil. I was really impressed with the whole team’s attitude to problem solving and making it work in order to retain their valued team members. I remember a time when they were all in the office together, practicing remote communication by working in different parts of the office holding their retrospective over video conferencing. 

I also spent some time working at Envato, they have a unique culture and are very publicly ‘not fussed’ about where people work, this gives Envato an amazing hiring edge. As well as a ‘Work from Anywhere’ in the world policy they enjoy employees dotted throughout regional areas of Australia. 

There’s nothing like immersing yourself in a problem to solve that problem; that means try, try and try again. Experimentation with tools, techniques and remote etiquette is rife at Envato.  When you enter their Melbourne hub for a meeting, you naturally assume someone will be attending remotely in a Google Hangout. The entire building is kitted out for frictionless communication over video conference, the most you might lose is a minute if someone has to drop out and rejoin a conversation.  Forcing yourself to partake in being remote provides empathy for other remote teammates and  makes you become very good at solving problems (even remote problems), remotely.

Another way Envato becomes super skilled at remote working is something so simple it’s sophisticated. Regular disciplined practice and behavioural role modelling. Leaders throughout the organisation ensure they are remote some of the time, it’s written into team working agreements. It’s clear to all that it is supported culturally and people are trusted, remote workers are not relegated to feeling like a poor underclass and Envato enjoys high retention and engagement as a result.  

I also attended a wonderful talk at LAST Conference in June 2017 ‘Synchronous communication is overrated’ where Thoughtworker Kelsey Van Haaster shared the issues and joys associated with working with her team of five globally distributed support team members, who between them service a workforce of 5,000 globally distributed users. Kelsey’s research and approach is thorough and results inspiring. Her experiences echo the importance of investing in culture building for teams. It was interesting to hear the team are friends on social media platforms outside of work, a solution for incidental office chatter, that increases the human bonds of connection.  

Perhaps we should be advocating to other technology giants about increasing the pace of technology change to support remote working?  I’m on record as being impatient to attend daily stand-ups as a hologram. Some of these companies would do better to place their efforts into solving those challenges of communication instead of calling everyone back to the office, as IBM has recently done.

There are a heap of technical tools available in the world now that can help you accelerate and improve remote collaboration — they exist and are being well and truly used all over the world, they are evolving and they will increase in number as more organisations experiment with remote working. Get in touch with us to understand more about how to utilise these tools and apply collaborative techniques to remote teams who want Agile and Lean ways of working. A big hint would be to start with company Culture and Working Agreements before you try and solve Stand-ups and User Story Cards.

Even if an organisation has the motivation and drive to invest in evolving technology solutions to support frictionless remote working for your teams, the more critical question is: Can organisations make the cultural leap to trust employees to work remotely? Fabiano Morais Delivery Coach, also from Envato, gave a terrific presentation ‘Global Nomads’ at Agile Australia 2017 and LAST conference, on how mobility is shaping the futures of people around the world, and how more organisations are pushing autonomy down to teams.  To quote Fabiano “It turns out when you trust people, they start to trust themselves”. 

Whether or not you have the technology investment or cultural foundation to support flexible and remote working, I can confidently assert that you definitely have the problem solving DNA inside your organisation to make it work, for what are human beings if not natural at solving problems of communication?

(This blog was written in two cafés, in the lobby of a large building, on the train, on my sofa at home and at a beach holiday house; everywhere except an office.)

A nuclear submarine without orders

By Communication, Organisation, PeopleNo Comments
img_8959

A visit to Baum Cycles – Darren Baum, fellow bicycle fan David Marquet and JP.

We know innovation often happens in unlikely places and creativity thrives on constraints. Last year one of the great people we spent some time with was retired nuclear submarine captain David Marquet. I don’t want to spoil the whole story, for that you need to read the book. But … within the confines of a long metal tube full of people and a nuclear reactor which stays underwater for 3 months at a time he ended up learning a bunch of really important stuff about people, models of leadership and how we move on from command and control.

“Leadership has changed from command and control to engage and enrol” — Steve Denning

Convincing leaders that we need to move on from command and control is the first step. Sometimes that’s easy, sometimes it’s hard. The next part, the changing part is always hard. If our people and organisations are conditioned to work in a strict heirachy then it’s not as simple as just giving that structure up and ’empowering’ everyone to make their own decisions. Like any new skill we need to learn how to work in a new way a little bit at a time.

David describes this challenge for leaders as slowly giving up control as you build capability and context in your teams. One of the practical approaches they developed was a model of communication called the ladder of leadership. We don’t start by trying to take the other person we’re communicating with (boss or subordinate) the whole way, but just to step one run up the ladder.

the-ladder-of-leadership-capt-marquetI ask my boss – “Tell me what to do about the problem with marketing ?” – instead of telling me what to do my boss says “Tell me what you think about the problem with marketing ?” … And so-on up the ladder over time and interactions until I’ve built up the capability and context to make a good decision independently. Engaged and enrolled.

Technical and Non-Technical Capability: which lever are you reaching for?

By Communication, PeopleNo Comments

If you’ve read the news recently, you may well have been struck by the tragic absurdity of TransAsia flight GE235, which crashed shortly after take off.

42 people died after Captain Liao Jian-Zong accidentally shut down the plane’s sole remaining engine after the other engine failed on take off – an occurrence common enough to be specifically trained and tested for at regular pilot certification. Black box records reveal the pilot’s last words to have been: ‘Wow. I pulled back the wrong side of the throttle’.

Contrast this with 2009’s flight US1549, where Captain ‘Sully’ Sullenberger successfully ditched a much larger aircraft in the Hudson River, with no loss of life.

View YouTube clip

Both pilots had extensive military experience and technical training in the skills to safely respond to the emergencies facing them – so what went wrong?

Read More

Agile Australia 2013 Reflections

By Agile, Communication, Customers, Education, Lean, PeopleNo 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.

Is the impact of Agile just a Hawthorne Effect ?

By Agile, Communication, StrategyOne 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

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

By Agile, Communication, Development, PeopleOne 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, SpaceNo 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.

WHY ?

By Agile, Communication, Customers, Development, Disruption, Lean, People, StrategyNo 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.

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.

From Insight to Strategy to Innovation – while standing at the Toyworld Checkout

By Communication, Customers, Disruption, People, Strategy2 Comments

Listen up lean and agile thinkers. This is a simple illustration of the kind of things that make innovation and strategy easy – a gift from someone on a toy shop counter that probably earns less than $20 an hour. Are you this smart? This brave?

With a 10 year old in my household, it’s little wonder I am a fan of Lego. From my own childhood memories, to their inspiring recovery from a near death business experience (after their long-standing patent for bricks expired) just by listening to customers and innovating the product accordingly, it is all good.

One of their recent products puzzled and infuriated me though. It is a single Lego minifigure in an opaque cellophane packet – ideal for for party bags for kid’s birthdays; the child at the checkout who MUST spend their pocket money on something (and they are cheap, $4 to $5 each); or perhaps the serious collector to get some custom mini figure accessories and body parts.

Yet, you can’t see which one of the 16 in the series you are going to end up with.

I will thus confess to having spent far too much time at many a big store’s Lego counter with Mr 10, eyes shut, feeling the packets to detect the slightest variation in the components to figure out if the character is Jane Torvill (uncool!) or Toxic Space Engineer (cool!).

Children’s (and collecter of greater years, ahem) ingenuity and social network savvy soon solved it – for Series 1 and 2 they quickly figured out the bar codes were different and published the key. So Lego moved the goalposts, using a single bar code and a system of dots on the packaging to differentiate figures in Series 3. The kids cracked it again.

Series 4 onwards you have no chance of detecting the difference from the packaging. The secondary market on eBay for these figures erupted, and the popularity of the series continued to grow. Business is booming. Yet I’m still grumpy about it. Why?

Why did Lego want the figure to be a surprise? Was that part of their strategy for the product? Perhaps I will never know, and Mr 10 and I quickly became disenfranchised by the whole thing.

So imagine my surprise, when dropping into Toyworld Palmerston North in NZ last week to find the Lego minifigure packets on the checkout counter, with each figure individually labeled with a hand-written number against the official Lego key. “You can’t do that”; “that’s naughty”; “that’s against the rules” were all thoughts that leapt into my rule-obeying lizard brain. Flabbergasted, I managed to regain enough English language ask why they’d done it.

And for the readers who are struggling with why the hell I am writing about toyshops, this is called INSIGHT and is the most valuable commodity you can possess when developing something new. It is Dan Pink’s ‘purpose’ and Simon Sinek’s ‘why’ in the words of a 20 year old shop clerk:

“I just saw the looks on the faces of the kids – so disappointed that they got a cheerleader when they wanted a deep sea diver, and the conflict they had, knowing they had to be grateful, but had chosen a useless gift”.

Now, agilists, here comes the STRATEGY bit – how will you do something about that problem your customer savvy product owner has found a really sharp insight about:

“Did you get an official cheat sheet from Lego on how to do it?” I asked.

“No, no – there isn’t one. We just had time while on the checkout and watching the door, so we checked each one individually, just like the kids would do.”

INNOVATION simply comes from making this a habit now, knowing things like there are only 2 robots in the latest boxes of 100 or so mini-figures, and thinking about which of their customers might really value that robot.

“The hair on number 3 in that set there is cool for making Call of Duty characters” trots out Mr 10 to the girl behind the counter. “Really? My brother is so into Call of Duty – he’ll love that one”. Minifigure #3, the uncool, pyjama-clad kid with the teddy bear just went from ‘can’t shift’ to ‘can’t keep in stock’.

That is called GROWTH.

If you’re smart, you’ll be down to Toyworld in Palmy and hire that lady on the counter for your agile innovation team. She gets it 100%.

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.

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.