Tag

Australia

LUNA CASE STUDY: A health insurance start-up.

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

Reflections on Agile in Australia

By | Uncategorized | No Comments

James and I were both on the roster of speakers at Agile Australia 2011 this year. There were some great presentations over the 2 days, the highlight for me being Martin Fowler’s closing address on the profession of software development in the 21st century. His point was simply “we are ALL software development companies now, so you need to understand some technology basics”.

It resonated for me having led the charge over 4+ years on the journey from Lonely Planet proudly proclaiming it was “not a technology company” in 2007 (thus they’d seemingly outsourced everything that had a green LED light on it) to one where our digital and publishing businesses both revel in having high levels of technology competency on the teams.

If you have not heard Martin talk about technical debt, software complexity and development abandon this blog immediately and read these 3 blog posts:

Martin Fowler of Thoughtworks delivers the final address.

Technical Debt 101

Technical Debt quadrant diagram

The design payoff line (aka the line of regret)

Having attended Agile Australia for the last 3 years, I was amazed to see the change in the profile of people attending, and how rapidly agile is taking hold in Australia.

The plaintiff cry was pretty much “we’ve been doing agile for a year now, but we still feel the pull of gravity back to the world of 5 year plans, business cases and large teams working on projects where the design is done up front – why is agile such hard work? It’s not fair!”

That matches our own experience at Lonely Planet – year 2 can be pretty agonising as some team members lose the faith (having suffered a failure or two); a lot of ‘hiding Harrys’ have their shortcomings at prioritising product features and joining the dots at standup every day exposed; the scrum zombies get a foothold; and in our case, romantic memories were revived by finance of life under waterfall governance being somehow more certain in its outcomes. “Certain to fail” I was forced to point out at times, pulling out our $6m clock.

My advice? With stakeholders, stop talking about agile and start talking Lean at this point. Focus on measuring value, eliminating waste, improving flow of work, building what the customer has pulled, and speed of delivering to customers. Talk about ‘time to cash’ and start measuring customer outcomes. Put those metrics up on the board alongside the points delivered and burn down charts. Focus and talk about being great, not being agile.

James Pierce

James spoke on the subject of agile workspaces – a topic on which there is very little written. A lot of dangerous fallacies exist about open plan offices that can impinge the success of any transition to agile working methods. It is not all about rows of desks with paired programmers yammering away to each other – you need carefully designed quiet spaces and well thought-out dynamics. From the level of questions that ensued, this is a topic that needs further expansion.

Nigel Dalton

I presented a series of case studies on agile product development – using examples of a number of Lonely Planet stories where things had not gone as planned, and linking those results back to where we overlooked some key agile principles like customer input, releasing early and testing.

I was delighted to score tweet of the day with my flippant “every time you draw a gantt chart a fairy dies”.

Jean Tabaka provided Day 2’s opening with a stern reminder that the agile community has its destiny in its own hands, and essentially should stop whining and start building. That means all of us!

Never employ someone who left their last job because they stopped learning

By | People | No Comments

Imagine a typical job interview situation. Bright young thing (BYT) in the chair opposite you (as the hiring manager) with a resume to die for, 2 open source hackapps in the local market, they’ve survived the pair programming test with your wiliest developer, and you’re secretly very happy with the skills and experience you are about to steal from a rival in a limited pool of technical talent.

So you pop one final question: “tell us why you are thinking of leaving your current employer?”

If they shoot back “well, I’ve really stopped learning there”, the interview is over. Do not hire that person.

Now in the current over-cooked Australian market for tech and product talent, you’d say I was crazy and irresponsible to offer that advice. Let me offer my defense.

People leave their education and take the skills they have gained to their first employer. The mixture of their personal traits (intelligence, customer focus, self-motivation etc), skills gained from academia, and background enable them to slowly master the work at hand with plenty of guidance. Soon enough though, the job gets stressful, repetitive, and money becomes an issue. So they jump. First job syndrome.

At job number 2, the workplace is different. Nobody knows precisely what our new hire doesn’t actually know, and with the likely change in corporate culture, along with expanded duties and responsibilities (to justify that pay rise) they will likely get along meeting expectations on the skills they brought with them. They will spend a lot of energy just fitting in with the new people, and may well apply their limited skills to the new tasks and environment and think they are learning new stuff. But they get tired, are a bit too busy with their social life to read much, and the work starts to feel a bit repetitive.

Soon enough, maybe a year later, maybe two, they jump ship to you for more money and ‘opportunity’ (or whatever you put in that job advert ;-). And they give you the dreaded line “I stopped learning there”, making them sound ambitious and intelligent all in one go.

Now, when did they actually stop learning stuff? Last week? Last job? The one before that? Or at University? For me, ‘I stopped learning’ is a lame-ass excuse and a mealy-mouthed  defense to a recruiter. Learning starts with the individual, it is their own responsibility. In this world, it is almost impossible to stop learning give universal access to information. It is cheaper than ever through e-books, blogs, tweets, and ahem web pirates. And if they’re from an agile employer, something is badly wrong – they should be learning every time they have a retro or pair program.

Past behaviour  is definitely the best predictor of future behaviour.

I suggest a follow-up question, which gets to the heart of the problem in a tight labour market might be ‘what have you read lately that helped you in your job?’ or ‘what have you found interesting on the web lately in your field?’

No good answer, no hire.  Nerf them on the spot.

Subscribe to the Luna Newsletter

Quote of the week

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

Recent Luna Posts

Become Remarkable.