Skip to main content
search
All Posts By

James

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.

December 11, 2011
Love0

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:

December 6, 2011
Love0

LUNA SPACE TRIVIA: The Buran

By SpaceNo Comments

Another wonderful set of photographs published by the quirky www.cracktwo.com inspired me to share another tale from the Russian Space Program. The late 80s saw one of the most interesting and the single most expensive space program ever undertaken by the Russian Space Agency: the Buran spacecraft, a reusable space vehicle created as an answer to the US space shuttle program. The Soviets were concerned about the possible military applications of the US shuttle and its ability to launch large payloads into space. This view was compounded by US profitability analysis which required roughly weekly launches to be economically viable. Cold War fears of space-based lasers or nuclear weapons drove the Russians to copy the American space shuttle in an attempt to maintain strategic parity.

One unmanned Buran launch occurred on November 15, 1988 and for 22 years remained the only space shuttle to ever perform an unmanned flight and landing, another testament to the Soviet technology and ingenuity. Ultimately the program was cancelled at the collapse of the Soviet Union, and as it became clear that a reusable launch space vehicle was in fact much more expensive per launch than the cheap and reliable Soyuz spacecraft that had been in use since 1966. There is of course some irony that as the American shuttle program has now been shut down it is the Russian Soyuz craft supporting the ISS and there have even been discussions about reviving the Buran program. To this day the Baikonur Cosmodrome in Kazakhstan remains the busiest space port in the world.

Oh yes I nearly forgot, in good Luna Tractor tradition our stories normally have some lesson.  Today the moral is this: just because your major competitor is doing something, doesn’t mean that it’s always a good idea for you to copy them and do it as well.

November 21, 2011
Love0

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.

November 15, 2011
Love0

Don’t be this company

By UncategorizedNo Comments

We spend most of our time teaching people how to work differently, adapt, innovate and evolve their businesses; but we also always want you to ask yourself why. Today’s lesson comes from Scott Adams from the frighteningly realistic Dilbert comics. As an aside, I recall Scott talking early on as he wrote the comic about how no matter how outrageous he tried to make it, he always had readers emailing him to say “my company is just like that”. Now he just uses fan emails and true stories as his inspiration.

5 year plans

Five year plans are a great thing for a leadership team to do. You take your best and brightest away somewhere nice with an inspiring view, you talk, strategise, plan and argue late into the night. There is a great sense of security in having a detailed map to steer your ship. It feels good with all the ideas and debate coming together to give your board, teams and shareholders certainty about the future.

There is just one problem … plans are only guesses. To all the readers who committed to 5 year plans in 2006, can you please dig them out and let us know how your strategy to handle the introduction of the iPhone, the iPad, and 800 million consumers using a walled garden called Facebook as their primary online experience has played out.

Stop trying to guess what the future will be and instead accept the uncertainty is the only thing which is certain. Make your best guesses, adopt ways of working which are flexible as you learn new things and focus on solving the problems you know about and can understand, instead of dreaming about flying cars.

October 18, 2011
Love0

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)

October 12, 2011
Love0

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

October 11, 2011
Love0

The Aurora from the International Space Station

By UncategorizedNo Comments

Click the image to watch the video.  The source is www.spaceweather.com but you can’t link to individual stories on their home page so I’m going to copy it here too.

“AURORAS UNDERFOOT: Solar activity is picking up, and no one has a better view of its effect on Earth than the crew of the International Space Station. During a geomagnetic storm on Sept. 17th, astronauts recorded a must-see movie of auroras dancing underfoot.  Note how the underbelly of the space station glows green from the reflected light of the auroras below. Also, in the distance, Sirius the dog star and Orion the Hunter can be seen rising feet-first into the night sky.

The storm, which registered a moderate 6 on the 0-to-9 K-index scale of geomagnetic disturbances, was caused by a coronal mass ejection (CME) hitting Earth’s magnetic field. It was just a glancing blow, but with CMEs that is often enough to spark bright auroras over both ends of Earth. The space station was flying over the southern hemisphere at the time of the display. Observers in the northern hemisphere saw it too.”

September 22, 2011
Love0

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.

September 21, 2011
Love0

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.

August 21, 2011
Love0

The Lockheed Martin Skunkwork

By UncategorizedNo Comments

A group within an organization given a high degree of autonomy, unhampered by bureaucracy, tasked with working on advanced or secret projects, is now commonly referred to as a skunkworks. The term comes from Kelly Johnson’s team at Lockheed Martin which was formed to build the P-38 Lightning.  It was isolated and protected from the rest of the organisation; this one team went on to design the U2, A-12, SR-71, F-117, F-22 (just to name a few iconic aircraft).

“Many times a customer would come to the Skunk Works with a request and on a handshake the project would begin, no contracts in place, no official submittal process.” (ref)

So I find myself wondering, why we don’t always work like this ?

There are 14 key skunkworks rules at Lockheed – this is my TLDR version. (Too Long, Didn’t Read).

  • The leader must be given autonomy, reporting into the highest level of the organistion.
  • Minimal but thorough project management and reporting.
  • Engage the absolute minimum number of ‘good’ people (emphasis on absolute).
  • Continuously monitor ROI, maintain basic projections.
  • Trust your partners/contractors, don’t drip feed, or nickle and dime them.
  • Test, Test and Test.
  • Reward people for skills and excellence, not the size of their empire.
  • Build trust; trust your team and trust your partners.

Does this sound familiar Agilists ? Have faith, this stuff works and we have some of the coolest planes ever built to prove it.

August 8, 2011
Love0

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 ?”

August 2, 2011
Love0

A Photographic History of the Space Shuttle

By UncategorizedNo Comments

As the last shuttle flight landed a few days ago it seems like a good time to post this magnificent set of photographs via the quirky site www.cracktwo.com – A couple to wet your appetite and a link to the full series is at the bottom.

Columbia lifting off April 12, 1981

On the back of a 747 being transported back to the Kennedy Space Center.

And that’s a long way down, see the rest of the series at Crack Two

July 25, 2011
Love0

Dan Pink – The Genius Hour

By UncategorizedNo Comments

It would be fair to say Nigel and I are pretty big Dan Pink fans (ok fanboys) – His articulation of what motivates people is a constant reference and reminder, both personally and one we often recommend to others.  It’s HERE  from TED and HERE as a clever cartoon in case you have been under a rock and missed it.

We are also massive fans of Hack-A-Thons, Fed-Ex days, 20% time etc – but it is always a challenge to introduce to organisations.  Today he reports on a great little innovation by Jen Shefner, the Genius Hour – 60mins each week where she (the boss) does her employees job to give them 60min to be autonomous and awesome.

Maybe you can’t get a whole day out with your team, but surely you can find everyone an hour.  When you empower your team they will surprise and delight.

July 18, 2011
Love0

Space, Communication and Distraction – Questions from Agile Australia 2011

By UncategorizedNo Comments

One of the great things about presenting a set of ideas at a conference rather than as a blog post is getting interactive questions.  Here as some of the ones I can remember from Agile Aus 2011 from my session on Space, Communication and Distraction.

How do you keep physical and electronic Agile boards in sync ? 

My short answer to this would be that you don’t.  Invariable you end up with one or two people, often a project manager who diligently updates the electronic system to match up with the physical board.  The trouble is most of the time nobody, not even the threatened auditor is ever looking at the electronic system.  There is also something very powerful about the cheap, quick and democratic nature of paper cards.  Anyone from the CEO to an intern can understand, update and engage without needing a login, or remembering to look.  Also even with the largest screens available a physical wall can always be bigger.

What about distributed teams?

Yes, with a distributed team you’re going to have to go electronic, and change your habits to make it work.  Physical or electronic boards can both work, my point I guess is really just pick one – don’t sit on the fence.

Do people need individual desks?

Yes, even in highly collaborative environments, or development teams where much of the work is done at pairing stations it’s important people feel like they have some space which is their own.  Good teams, tend to decorate and customise their space the more they bond as a unit.  The same behaviour is true of individuals – we spend a huge number of our waking hours at work, shouldn’t it be a bit personal ?

Do people need their own computer workstation (in the context of a photo showing lots of pairing stations) ?

Again, I think the answer is yes.  Even if you are working at a pairing station, a small laptop to check emails, lookup reference online or write documents etc is still important.   Often good pairing station setups are reset each night back to a known configuration to create a stable development platform, that’s not very conducive to a personal computer environment.

Where do the testers sit ?

With the developers.

Where do the ops guys sit ? (Ok I’ll admit nobody asked this one, but it’s a good question none the less).

With the developers.

Do you think the lack of personalisation in open plan is a problem ?

Yes.  There is nothing worse than coming to work and feeling like a resource, not a person.

So what IS the ideal environment ?

Individual workspaces around the outside of collaborative workspaces (pairing stations and small meeting / workshop spaces plus a larger collaborative / social meeting space.  I need to get some LEGO men and build a model  of this.

How do you sell changing the environment ?

Happy, efficient teams are productive.  Good environments are a draw card for existing and potential employees.  But really, it’s about making your staff happy.  Happy people want to work hard.

June 24, 2011
Love0

Luna Links – Backflips, Work Schedules and Generalist Developers

By UncategorizedNo Comments

Why Is a Triple Back Flip on a Bike So Difficult? – Wired mag has an amazing video of a triple backflip on a BMX as well as a great explanation of why it’s so hard, and how to do it. (Luna Recommendation: Don’t eat your lunch while you watch).

The Marker’s Schedule vs the Manager’s Schedule – An oldie but a goodie from Paul Graham, relevant after my session at Agile Australia 2011.  Essential reading if you’re a manager of knowledge workers.

The Greatest Developer Fallacy Or The Wisest Words You’ll Ever Hear? – An interesting view on the negatives of generalist developers.  When I read this I’m reminded of a friend studying at Cambridge who has a year to figure out the question for her PhD, let alone the answer.  We don’t tend to go deep into things anymore, and that’s a bad thing – there is a great reference in there to the 10 years or 10,000 hours to mastery stuff too, but I’m going to save that for a real post soon.

June 17, 2011
Love0

Lonely Reflections

By UncategorizedNo Comments

Please forgive a some what more personal and indulgent post today; having worked with the team here over the last few months to make the complex and difficult decision to move LP’s online business to London I knew inevitably my own role here would be impacted.  Today is my last day at Lonely Planet and so I can’t help then but reflect on the last 12 months, in many ways working here in such a diverse, complex Agile environment has confirmed and refined many of my existing philosophical prejudices about building things, teamwork and productivity.

People need to be your #1 concern – Focus on hiring smart people who fit and enhance your culture.  Make sure you understand what motivates them.  Don’t be blinkered with building teams of people who are just like yourself, value diversity.

Agile is fantastic when it’s working well – When it’s not it can become a soul sucking zombifying grind.  Don’t be fooled, ‘Watergile’ isn’t some awesome hybrid that matches the promised (but rarely delivered) certainty of a traditional big up front design waterfall process with the flexibility and motivation of continuous delivery and improvement from the Agile world.

Conway’s Law is inescapable – Accept this and make sure you structure your application to suit your organisation or vica versa – trying to restructure one without restructuring the other is the road to misery and dysfunction.  If you have the luxury of a green fields development then be acutely aware that the way you structure your organisation will inevitably influence your architectural choices.

Having more than 6 developers working in one team is a crucial threshold – As you scale larger than this many of the positive collaborative team dynamics which you have taken for granted up to that level of scale will start to come unstuck.  This is something we need to consider and write about in some depth soon – there are important implications when you consider this dynamic and Conway’s Law at the same time.

DevOps is worth it – Right now there is an air of hype around DevOps which reminds me in many ways of the way people talked about XP or Agile in the early days.  It’s important to look beyond this and understand the fundamental change that’s driving the DevOps movement; Ops isn’t about installing linux and configuring network interfaces anymore, virtualised environments, automation, monitoring and deployment all require the same engineering approach that writing good code does.  Getting your developers working with your operations staff unlocks powerful knowledge sharing both ways.

Certainty and control doesn’t come through measurement and governance – There are 13 different Agile teams working within Lonely Planet, each has their own flavour adapted and optimised over time.  Some teams apply lots of traditional project governance, some teams apply classic agile governance (burn downs, burn ups as well as tracking velocity etc) and some teams take a very organic light touch approach. I haven’t observed any positive correlation between governance methodology and the success of a team.

 Space, Communication and Distraction – Agile is all about communication; routines and rituals which encourage teams to communicate, tackling issues and problems as well as sharing and learning from success. Our communication culture, physical environment and attitude to multitasking and distractions are less obvious levers which can have a profound impact on our teams and how effective they can be – Lonely Planet has allowed me to observe and work with a variety of teams, styles and approaches solidifying 10 years of puzzling over this one coming to some useful conclusions. 

I’ll miss my colleagues, working for a brand I love and Jimmy’s food in the cafe.  Next week I’m off to Agile 2011 to talk about Space, Communication and Distractions and then puzzle over what’s next.

June 10, 2011
Love0

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.