Skip to main content
Category

Development

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.

 

 

 

Stop and Watch – Coaching for behaviour

By Agile, coaching, DevelopmentNo Comments

 

Attending the Melbourne Lean Coffee meet up a couple of weeks ago I picked up a little coaching gem from an attendee that I’m keen to try out, despite it hinging on a sporting metaphor for work, which I’m usually strongly opposed to – teams working together is rarely akin to a game of two halves.

The story in question came from Lean Coffee attendee  Daniel Ploeg, who was amongst a whole bunch of parents being coached on how to coach a junior soccer team by observing an expert coach and the example goes like this:

The kids were milling about playing and the expert coach noticed one kid running into ‘open space’ this is something you apparently want to encourage in your soccer players as it creates opportunities to collect passes.

Daniel’s instinct was to encourage the good tactics by shouting out ‘Well done Tommy!’ to the player while play continued however the expert coach did something else. He stopped the whole practice game, and explained to all the players what Tommy was doing and why it was good, he then restarted the game telling the players to watch how Tommy was running into open space.

This created more ‘level up’ opportunities in the following ways:

– Tommy was positively rewarded for his behaviour as all players had stopped to focus on his good tactics

– All players were able to see the ‘ideal’ tactics in action and could therefore mimic the same behaviour themselves

– When the game re-started all players started to running into ‘open space’ themselves; the entire team’s level up opportunity was increased in this moment

– And the final kicker – pun intended – all players saw that trying aspirational tactics is rewarded with positive recognition in this team

 

Applying this model to the world of work as a coach of delivery teams really got me thinking. How could we implement that ‘stop and watch’ behaviour when coaching teams of people and how could we use this approach to encourage the modelling of positive behaviours at work?

I can think of a few scenarios:

– At your daily stand up you could mention a behavior that you saw the previous day, and ask the person to talk or show the team right after the stand up.

– In any of the team sessions you run you can be looking out for contributions that are desired behaviour, stop the action to acknowledge the contribution or even ask for the contribution be repeated for the group so everyone picks up that behaviour

–  If you’re a person that likes to mix approaches to your Retrospectives, you could ask the team to identify good behaviours (coding, planning approaches, work practices or collaborating) that they have seen during the sprint and spotlight those individuals asking them to elaborate on that behaviour for the team.

– And what about stopping everyone in the middle of their day to spotlight something great?  “Hey! Great thing happening over here everyone! Come and check out what your team member is doing!” Perhaps that would be a bit disruptive, but maybe not? I can imagine a lot of teams I work with mentioning  this kind of thing in a Slack channel as a somewhat quieter alternative.

Do we shy away from stopping the action in order to focus and amplify great behaviours at work? How might that be preventing the team from building on desired behaviours? Will that stop a team dare to achieve aspirational goals? Are you brave enough to stop the flow of output in order to create a learning opportunity?

As a coach and a leader it can feel counter intuitive to single out individuals, I often hold back not wanting to create competition that I feel can be detrimental to team gel, but the expert soccer coach example illustrated more positive ways to achieve this and level up the whole team in the same moment.

Since then I have set my radar to observing positive behaviours in team settings, why not try it, and go one step further; Stop and Watch those behaviours with your team?

My final take-away from the session was how ‘levelled up’ I felt attending the Melbourne Lean Coffee and how I increased my knowledge both by observing and listening, and also by contributing my ideas, that were formed into new ideas, and built upon on the spot. I highly recommend you add these kind of sessions to your own curriculum of learning.

Melbourne Lean coffee meet-up https://www.meetup.com/Melbourne-Lean-Coffee/

The Luna MBA 2014 Update

By Agile, Development, Disruption, Education, Lean, OrganisationNo 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

Inspired by Agile – A guest post from Avril Jean

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

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.

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.

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

By Agile, Development, Lean, Space, TechnologyNo Comments

As the lunatics in charge of the Luna Tractor, James and I are fortunate to spend time with the 25% of Australian agile professionals who actually give a shit, who we often meet at industry conferences. The smarter among you will have realised I’m rudely suggesting  that 75% of so called ‘agile professionals’ don’t actually give a shit, which sounds harsh until you hear my benchmark number for traditional business people (waterfallers, 5 Year Planners, CMD+CTRL freaks) who give a shit – more like 1/100 or 1%. Maybe in some cases 0.1%, depending on the institution.

The British cabinet war rooms - agile wall, all the comms you need, the right people in the room, iterating by the hour in 1936.

Economics lesson aside, being invited to YOW! 2011 to present was a real highlight for us. James and I gave a 45 minute talk on the history of coincidentally agile-like practices over the past century, and how they have contributed to some great innovations (particularly in the engineering and space fields, our favourites), as well as some Class A ass-saving.

YOW is reputed to be a developer-centric affair, with a speaker roster even including several actual inventors of famous programming languages (check out the superstar roster here), so as the resident economist I was fairly nerve wracked! Should non-developers even go to YOW? Is it just too geeky and engineering focused? My experience is absolutely yes, you MUST go to YOW – per Martin Fowler‘s signoff at Agile Australia 2011, we are all complicit in software development now, and gathering an understanding of that craft is vital.

A speaker like Mike Lee might go over your head if you are not an engineer for 5% of the time, but he chooses to focus as much on issues like learning and intellectual property protection as development language choice (and he is damned funny while he’s at it). Someone like Kevin O’Neill from Melbourne prides himself on keeping it comprehensible for everyone, without losing the pointy stuff, and the joy of invention and discovery. The big kahunas like Simon Peyton Jones are talking as much about the history, sociology and philosophy of software engineering as they are lines of code. Meanwhile the Linda Risings and Mary Poppendiecks are there for everyone to learn from.

You can easily pick a path through the YOW! program that takes in the more social and cultural side of software engineering and working in teams (these are passions for organiser and founder Dave Thomas) as well as some more general interest code and development talks, and if ever there was an environment where it is safe for non-coders to ask dumb questions – it’s YOW!

It’s actually the developers who need to worry about their reputation in front of their peers – just say “hey, I’m not an developer, but I’d love to learn how that works in simple terms so I can understand…” and you will have an erudite, clear answer in no time.

Good software engineers love their work, and want other people to love it too.

We’d also love to see a few more software developers and testers at Agile Australia 2012 in Melbourne at the end of May, joining the lively community of product managers, agile coaches, lean gurus, analysts, iteration managers, project managers, thinkers, vendors and practitioners who gather there each year.

A great example of our agile community’s need to think more holistically was raised by Mary Poppendieck and Linda Rising at YOW, who both called  “bullshit” on agile’s current obsession with teams of 7 +/-2 people (read devs, testers and a scrum master) as ‘optimal’, when organisations that deliver products to end customers clearly involve everyone from the person on the phone to customers at the front desk, all the way to the intern. Teams of 30-70 are way more normal and work just fine, so stop obsessing about your tiny team at standup being the whole agile gang. That mirrors our experience at Lonely Planet for sure.

If you didn’t manage to get to YOW! in 2011, or as always seems to happen, were forced to choose between sessions, the majority of the papers are up on the site, and most of the presentations were video recorded – check out the YOW Eventer website put together by the Cogent crew in Melbourne for the video over the next days – there’s a couple up already including ours.

Craig Smith with Mary Poppendieck at YOW 2011 Brisbane - the gold standard 'hard act to follow' at a conference

A copy of our slides (with still images replacing the video we showed in Melbourne and Brisbane) can be viewed online here: Luna Tractor YOW 2011 Decades of Agile

YOW! is a multi-media affair, so naturally there’s a podcast – produced by two of the Australian agile community’s bright young things, Craig Smith (who blogs here when not

Breakfast at Brew Cafe in Brisbane - sensational

coaching and inspiring agilists) and Renee Troughton (who has a great site called The Agile Forest). This was done in a fab (very Lonely Planet) little cafe called Brew in Brisbane, so the background noise is fairly busy, and we discussed (I suspect that should read ‘Nigel talked about’ – Ed. JP) a vast range of topics around agile, Lonely Planet, consulting and change.

You can listen to that podcast here, and of course it’s available on iTunes: http://www.theagilerevolution.com/episode-19-luna-tractor-with-nigel-dalton

My very best impression of the French gallic shrug - perhaps in reponse to Charles' line of questioning on whether Microsoft could be agile 😉

And finally on the media front, Microsoft’s Channel 9 conducted interviews of many of the speakers at the conference.

You’ll find them all on their prolific and rich tech-focused website, while my own epic 30 minutes of righteous crapping on about everything agile, Lonely Planet, and offering unqualified advice to Microsoft about becoming agile can be accessed right here.

See you all next year.

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

By Agile, Development, Lean, Space, Technology4 Comments

We spoke at YOW this year on the topic of innovation and agile over 6 decades, highlighting the Agile and Lean principles we see in space and engineering projects. From the 1930s we talked about the Cabinet War rooms and that deserves a whole post of its own as we continue to expand our understanding of how physical spaces enable and impact the people and results.  From the 1940s we talked about Lockheed Martin and their Skunkworks which we’ve written about before.  From the 1950s we looked at some of the magnificent engineering created by that same Skunkworks team… The Agile movement may only be 10 years old, but the principles and the evidence that it works goes back way further than that.  We’ll write more reflections on YOW itself at some point, but today you get one of the lessons that most appeals to us.

The U-2 Spy Plane

When the U-2 first flew in 1955, it was an accident.  A high speed taxi test saw it rolling down the runway at 70 knots at which point its sailplane wing generated enough lift and it took off into the air unexpectedly.  At the other extreme, its cruising altitude of 70,000 feet is referred to by pilots as coffin corner; at this height its stall speed is a mere 10 knots slower than its maximum speed.

The balance is so critical on the U-2 that the cameras had to use a split film setup with reels on one side feeding forward while those on the other side feed backward, thus maintaining a balanced weight distribution through the whole flight.

The plane is incredibly difficult to land because of the lift cushion under the wing as it comes close to the ground.  It lands on two inline ‘bicycle wheels’ and the wing tips also land and skid on the ground on titanium plates.

Perhaps the most amazing U-2 fact, and the reason we consider it such a testament to great engineering, is that it’s still in active service today.

The SR-71 Blackbird

This is the fastest and highest flying air-breathing aircraft ever made (only rockets can go higher or faster).  It has a maximum speed unspecified above Mach 3.5 (3.5 times the speed of sound) and a maximum altitude also unspecified but in excess of 85,000 feet.  At Mach 3.5 you’re covering 1km per second and the engines are sucking in 3 million litres of air every second – an average human breaths in that much air in a year.

The construction of the plane is pretty special too, with 90% of it being made from titanium.  At Mach 3+ the surface of the plane heats up to 500+ degrees.  The wet patches you can see on the wings and central spine in this photograph are caused by the fuel leaking out of the expansion joint ‘gills’ in the plane.  Until about Mach 2.5 when the plane heats up and expands, the SR-71 leaks fuel constantly.

While the Concord can do the transatlantic London to New York flight in about three and half hours, the SR-71 is the way to go if you’re in a hurry.  It holds the record at just 1 hour 54 min.

My favourite SR-71 story comes from a pilot in the book Sled Driver: “One day, high above Arizona , we were monitoring the radio traffic of all the mortal airplanes below us. First, a Cessna pilot asked the air traffic controllers to check his ground speed. ‘Ninety knots,’ ATC replied. A twin Bonanza soon made the same request. ‘One-twenty on the ground,’ was the reply. To our surprise, a navy F-18 came over the radio with a ground speed check. I knew exactly what he was doing. Of course, he had a ground speed indicator in his cockpit, but he wanted to let all the bug-smashers in the valley know what real speed was ‘Dusty 52, we show you at 620 on the ground,’ ATC responded. The situation was too ripe. I heard the click of Walter’s mike button in the rear seat. In his most innocent voice, Walter startled the controller by asking for a ground speed check from 81,000 feet, clearly above controlled airspace. In a cool, professional voice, the controller replied, ‘ Aspen 20, I show you at 1,982 knots on the ground.’ We did not hear another transmission on that frequency all the way to the coast.”

This article from Gizmodo about flying the SR-71 is required reading.

In a world of throw-away appliances and software it’s a salient reminder that great work, great engineering lasts a long time.  The Skunkworks team was isolated and protected from the rest of the organisation; this one team designed over 30 planes including the U2, A-12, SR-71, F-117, F-22 – just to name a few iconic aircraft.

Eating our own Dog Food

By Agile, DevelopmentNo Comments

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

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

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

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

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

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

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

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

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

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

Before:

After:

LUNA CASE STUDY: A health insurance start-up.

By Agile, Development, Disruption, Lean, People3 Comments

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

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

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

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

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

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

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

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

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

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

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

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

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

Luna Guest: “Talking to Your Customers” by Justin French

By Development, PeopleNo Comments

Talking to your customers is crucial to the success of your product. Call it Customer Development, User Centered Design or Market Research, just make sure you’re doing it.

It’s not hard to do

Find a customer, or a potential customer, and start talking. If you’re nervous or lack the confidence to do this one-on-one (you’re absolutely not alone), grab your product manager, designer, tech lead, CEO or anyone else in your team and do it together. Reduce the formality and ceremony over a coffee or a beer. Start over email, on the phone. Invite your most trusted customers to talk among themselves in a private email group.

Starting is far more important than how you start. I don’t need to prepare too much either – it’s pretty easy to get people to talk about themselves and their work.

What not to do

Don’t talk about features. Asking them what features they want (or letting them push the conversation that way) is a complete waste of time. There’s two predictable outcomes, both of which should be considered negatives:

  • You walk away with a checklist of stuff you need before they’ll buy
  • The customer walks away with a list of reasons not to buy your product

What to do instead

Ask them about their job, tasks, workflow, process and constraints. Ask them how they get stuff done. Ask them what they do, not what they need. The outcomes from this are far more positive:

  • You know if this is the sort of customer you want to help.
  • You build empathy for this customer.
  • You have a much deeper insight into the customer’s true needs.
  • You have real scenarios to draw upon and real problems to solve.
  • The customer builds a relationship with you and your product far beyond the software.
  • The customer talks directly with someone who can shape the product.
  • The customer invests time in your product, and has an interest in it’s success.

If you must talk about features, always dig deeper. Shift the conversation away from the implementation to the reasons behind it. Instead of talking about that epic reporting widget they need, talk about why they need it, and how that helps them get stuff done.

Push them to articulate the problem, rather than prescribe the solution. It’s your job as a product designer to aggregate and consider the problems from many customers and design your own solution. Yes, it’s your product, you design it.

After listening to the problem, you may already have features that can help. This is awesome! You’ve just avoided a conversation about “missing features” and showed them how your product can help them right now.

If you find a real gap in your product, don’t instantly promise a feature to fill it. Instead, promise to spend time thinking about it. Ask them if they’d mind a follow-up conversation (if this is important to them, they’ll be excited to help).

“What they do” is far more valuable and interesting than “what they want”.

(Re-posted with thanks to Justin from http://www.justinfrench.com)

Agile Roadmaps, Agile Planning and Topical Storms

By Agile, Development, People, TechnologyOne Comment

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

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

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

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

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

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

The real legacy of Steve Jobs

By Agile, Development, People, Technology

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

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

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

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

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

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

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

Not just an IT thing

By Agile, Development, Lean, People, TechnologyOne Comment

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

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

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

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

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

Better or just Different ?

By Agile, Development2 Comments

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

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

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

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

When you should do nothing – maximising the performance of knowledge workers

By Agile, DevelopmentOne Comment

Most of the ideas we write about are well supported by research, leaders in software development and business or at the very least are well established as best practice.  Instead today I want to write about a personal theory of mine, which is still very much developing but I think is important enough to share.

The training program for nearly any serious athlete these days is planned around the ‘season’ of their chosen sport, then their most important events and they work back from that to ensure they are in ‘peak’ condition at the most important times of the season.  As they build up to these peaks their program will push them through a series of harder and harder training sessions, building up fatigue and forcing the body to adapt to support the increased stress (essentially driven by our fight or flight reflex).

The body doesn’t get stronger during the workouts though, it’s actually being stressed and broken down during these sessions.  When an athlete stops to rest, eat and sleep the body has a chance to rebuild and adapt; because of the stress it’s been under the body adapts and prepares for the next time by building strong, faster muscles, etc.

It seems logical then that the best approach is to steadily increase the training load each session and over time get stronger and stronger and stronger.  In practice this doesn’t work. Athletes stop improving, they burn out and become injured or sick from the constant stress they are placing their bodies under.  There are two things at play here.  The first is that by training hard enough to stress their body and cause the positive adaptation they are also building up a debt of fatigue which eventually becomes too much for the body to overcome causing sickness, injury and burnout.  The second is that due to the consistent pattern of stress the body adapts, the workouts may become a little easier, but the athlete improves more and more slowly.

Enter periodisation, a process developed in the Eastern Bloc countries and now widely adopted by athletes the world over.  With periodisation a year, the macrocycle, is broken into a series of blocks, often four week mesocycles which are then composed of a number of week long microcycles.  Each mesocycle will include week long microcycles of training (increased stress), and most importantly a microcycle of recovery.  This cyclical approach allows the athlete to stress their body, but also to have periods of recovery allowing their body to reach a new peak of performance as it rebuilds and sheds fatigue.  This new peak then feeds into the next cycle, allowing them to undertake more stress, train harder and over the macrocycle increase their performance to levels unobtainable by a stead state training program.

Now let’s turn our focus to an Agile software development process; the routine and rhythms of a sprint process remind me a lot of an athlete’s training microcycle.  Week in, week out we kick off the sprint, have daily stand-ups, write code, test code and have a demo and retro at the end of the sprint.  Then next sprint we do it all again.

A common pattern I’ve observed with teams who adopt Agile is that around the 3 month mark they start to loose faith.  At the start the buzz of something new, a different way of working and the rapid feedback and transparency let the team quickly improve their performance.  But after a while the sprint to sprint performance increases slow, or even stop, and yet the team is working just as hard each sprint.  Often times the team’s performance will even drop off as they grow weary of maintaing all the habits for no noticeable improvement.

Does this sound familiar to the earlier example from the athletes?

Why are intensely focused working groups (often conducted off site from your normal office) so productive and satisfying? If it works so well why don’t we work like that every day? Why is it that often the best ideas come at unexpected times, under the shower, out for a walk or on holidays for a week or two?  Why do software developers seem to work so intensely sometimes and yet spend so much time going around and around on a problem getting nowhere, or surfing the web and staring into space ?

I think these things are just examples of accidental periodisation by knowledge workers and my theory is that the human brain is just like the human body in the way it can be trained and leveraged for maximum performance.   While ad hoc training programs can work well for athletes a structured program will nearly always deliver a better, and more importantly consistent result.  My hypothesis is that these same principles of training apply to the human brain and there are lots of practical ways to apply this for knowledge workers but I’m already overtime on this post… so I’ll save those stories for another day.

The Truth about DevOps

By Development

DevOps seems to be the new cool kid on the block lately, especially in Agile circles.  New user groups are popping up and it’s a fashionable topic to talk about at conferences; Many of the more leading edge consultancies are working hard to establish themselves as having creditable practices in the space.  Right now DevOps feels like Agile did 10 years ago.

Here’s the first paragraph from the top hit in google, it is of course from Wikipedia …

“DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for development (applications/software engineering), technology operations and quality assurance (QA)”

… and it’s 100% wrong. DevOps isn’t a process; Unlike Agile, DevOps doesn’t have a neat set of rituals to build the habits and enable the right communication and feedback cycles – perhaps we need to invent some.  There are definitely some things like co-location which help, and getting everyone coming along to one daily standup isn’t going to hurt. But, you can do those things and fail to create DevOps.

Here’s another thing it’s not, Continuous Deployment.  Releasing your software regularly and having an automated build and testing pipeline is another good process, it creates good habits and it does create closer ties between your developers and your ops group; But it’s not essential to DevOps and it doesn’t ensure you’ll have DevOps.

So here’s what it really is:

  • Developers caring about deployment and production systems.
  • Ops caring about the development of new features.
  • Developers with access to production systems, monitoring and deployment processes.
  • Ops engaged with feature development from the start.

It’s about creating a team of engineers, rather than a team of developers and a team of operations folks.

DevOps is just a neat new word to describe how little companies have managed their development and deployment for years – If you don’t have many people and you don’t have lots of departments then your developers get involved in deployments, and if you’re lucky enough to have a dedicated ops person then you can be sure they will be working with the development team as well, usually on the database and back end parts of your system. In bigger companies it’s not as simple, bigger systems mean more complex platforms, more sophisticated network configurations and database clusters.  As projects get bigger it’s only natural, even essential that within your engineering team there are specialist roles.  UI/UX specialists, back end, API and model specialists and DevOps is about engaging staff who would have previously been part of your ops team.

Just like Agile, DevOps means taking a leap of faith and seeing how things work out.  Here’s how to start, get a developer to sit and type all the commands to deploy one of your system with an ops person looking over their shoulder – I promise you they will be coming up with ways to automate your deployment by the end of the day.  Next time you have a performance problem, get your ops folks to pair with the developer working on it, matching up data from your system logs and monitoring system with the active code.
Just today I enjoyed watching a ‘developer’ and an ‘admin’ working together to shave 20% off the run time of our full test suite in 30 min just by building a shared understanding of what was required and tuning the platform together.

“‘Devops’ is a movement of like-minded sysadmins and developers interested in bridging the artificial gap between our camps. It’s impossible for sysadmins to do their job without reading or writing code, and developers need intimate systems knowledge to scale their software.

The walls between us are being broken down — it’s time to start learning from each other.” – www.devopsdownunder.org

Why you should try a Hack-A-Thon

By DevelopmentOne Comment

In product and software development organisations there is very often a deep sense of needing to justify all the time we spend working on things.  I catch myself doing the mental arithmetic: is what I’m doing now really ‘adding value’? This is not such a bad thing; we should be striving to create value and generate profits… But I think there is an unintended side effect. Often this desire leads to product development and governance processes that can make development feel like a carefully planned military exercise.  Orderly, neat, no colouring outside the lines but probably not how you would choose to spend your weekend.

Street Performers in Trafalgar Square - People are amazing, unlock their creativity and see what's possible

A Hack-A-Thon (Fed-Ex Day, 20% time or Howhardigras) is a great way to break this culture and remind yourself that passion and invention are powerful and yet often intangible forces that really should try and tap into.  Here’s how you do it:

The Rules:

1) Everyone gets 24 hours.
2) At the start everyone has to give a 1 min pitch of what they are going to try and do.
3) At the end everyone has to give a 5 min presentation of what they made or learned.
4) (optional) Beer and pizza should be served.

Simple eh!  Now this is the bit where you’re going to feel uncomfortable. Don’t have a theme; don’t try and guide or cajole your crew to work on things with a ‘business value’; please, please do the opposite.  Encourage your team to experiment with things that have nothing to do with their day job or write something in a language your company doesn’t use.  Trust me on this and trust your people.

Having done this with countless teams I am still surprised each and every time at just what is possible in 24 hours.  Sophisticated iPhone apps with backend integration finished and ready to upload into the iTunes store.  Sysadmins teaming up with UI developers to overhaul interfaces based on what the admin knows from obsessively watching web-server logs.  Developers learning a completely new programming language and writing significant applications with it.  Product features which would never get through the rigours of a regular governance process and yet go on to be hits with internal and external users.

Allow your teams 24 hours, set them free and you’ll be amazed what they can do.

You are what you measure

By Agile, DevelopmentOne Comment

When you put a volt meter into an electrical circuit to measure the voltage difference between two points the internal resistance of the meter itself changes the circuit and impacts the reading. The best volt meters are designed to have very very high internal resistance, but in all circuits the resistance of the volt meter changes the circuit and impacts the measurement (circular yes!); in sensitive low voltage circuits where accuracy is most important the impact is greatest.

One of the agile development teams I’ve worked with decided that they would use the number of cards as their measure for planning, velocity and by implication productivity. Each iteration the cards from the last release were proudly pinned to the wall and counted. An interesting pattern emerged over a number of iterations: the number of bug cards completed went up, and up and up.

We spent a great deal of time trying to work out where our development, testing and release process was going wrong that we were seeing so many old bugs. Were we finding old issues with more thorough testing? Were the developers being lazy? Or was the work we were tackling just much tougher than previous projects? It turns out that the explanation was in fact very simple. Previously developers found and fixed bugs as part of their development tasks (this is quite normal), now they were writing these up as cards and running them across the board through the full prioritisation and QA process. Consciously or subconsciously the developers had been sent a signal that the number of cards was being measured, and thus they responded to and optimised their process to meet that benchmark. Issues which would have been fixed quickly while the developer was deep in their context now became tasks of their own, a much more expensive and unnecessary process.

Perhaps a better title for this post might be ‘Only measure what you truly wish for’. This is a topic which we’ll surely return to again and again, but I’ll leave you with a quote I write into the front of every one of my notebooks to remind me of a valuable truth.

“Not everything that counts can be counted, and not everything that can be counted counts.” – Albert Einstein.

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.