Tag

communication

Challenger 1986: NASA’s most explosive retrospective.

By | Agile, Communication, People, Space, Technology | No Comments

Space Shuttle Challenger in one of the most famous (and chilling) space photos of all time.

As I read this week’s Telegraph obituary of a great American rocket scientist, I was moved to thinking about how we deal with the whistleblowers and truth-tellers in an agile world.

How can we strike a balance between encouraging transparency and realism, while managing the impact on the morale of tight-knit teams from Negative Nigels and Whining Winifreds?

I’ll be the first to say that the command and control culture of committed waterfallers (like NASA) is a fast track to secrets being kept, and problems being swept under the carpet. When “failure is not an option” on a project racing toward a fixed launch date, with scope being secretly trimmed off Gantt charts to ensure compliance with public commitments and budgets, and all-nighters pulled by tech heroes, we are just hiding failure.

Is agile any different? If it is effective, yes. But agile zombies, with their card carrying undead marching into retrospectives and standups ritually chanting out their obligations so they can get back to their desks as quickly as possible, is probably just as bad as waterfall.

This tragic tale of an ignored voice is a stern reminder of the consequences of avoiding talking about engineering issues.

When I arrived at Lonely Planet in 2007, and proceeded to shut down a failed waterfall-delivered website program, the HR team had already initiated a training program called Effective Conversations. It seemed uncomfortably basic and quaint in intent – teaching people to get good information across quickly and confidently when in meetings, in casual conversations, one on ones, or in the lunch queue.

A month later, I knew it was gold – I had yet to find a person who did not say “I knew that would happen”. People had just not managed to get the complexity and interdependence of the hairball of product and architecture problems across to Steering Committees and executives. And after a few public scoldings for being naysayers, they learned to shut up and soldier on.

Edward Tufte tackled this same issue of communicating complexity for NASA after the second major shuttle program disaster – Columbia in 2003. This $7 report from his website is one of the best training guides for agilists to invest in around effective written communication.

The constraints put upon Boeing and NASA engineers to explain the complexity of the situation where chunks of insulation had broken off the booster rockets and damaged the heat protective tiles on the leading edge of the wing, using Powerpoint slides with bullets points and a constrained number of words per line, was too great. The wrong decision was made to not space walk and inspect the damage.

I wonder if that was a ‘didn’t work’ or just a ‘puzzles us’ in a retro sense? Either way it signaled the beginning of the end for the second great chapter of the USA’s space exploration efforts. If you are facing an ever increasing complexity in your product and IT architecture, our advice is to put as much investment into improving everyone’s communication skills as you are any engineering effort.

Buy your copy of Edward Tufte’s handbook from his website here.

Eating our own Dog Food

By | Agile, Development | No 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:

Space, Communication and Distraction – Questions from Agile Australia 2011

By | Uncategorized | No 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.

Lonely Reflections

By | Uncategorized | No 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.

Great Agile Workspaces: Conclusions

By | Uncategorized | No Comments

This post is the conclusion to my series on creating Great Agile Workspaces, so if you just landed here, read these posts in order first:

  1. Introduction
  2. Physical Spaces
  3. Communication
  4. Distraction and Multitasking

Conclusions

Agile is a powerful methodology for building great software, but it’s just one part of the system in which we and our teams work.  Space, communication and distraction have a big impact on the net productivity we can generate.

Space: Focus on building a physical environment that feels good, promotes team work and yet gives enough isolation and separation between individuals and teams – the best environments have diversity, including quiet space for problem solving.

Communication: Embrace high value forms of communication and work on your culture to weed out low value, or negative styles.  Be intentional about how and when you communicate.

Distraction: Some distractions are inflicted upon us and some are caused by poor habits. Our capacity to create things once we get in the zone is amazing.   The right space, communication culture and a lack of distractions are essential to enabling the zone.

Sadly the depth of field of a workplace is not controllable like the magic of a camera - all people are susceptible to interruption and distraction.

Essential References and Further Reading

Joel’s Field Guide to Developers – Developers and Workspaces

DeMarco and Listers’s seminal Peopleware – Teams and Productivity

Susan Maushart’s Winter of Our Disconnect – Distraction and Multitasking

Great Agile Workspaces: Multitasking and Distractions

By | Uncategorized | No Comments

A very basic agile workspace - high knowledge sharing, but high potential for interruption.

We tell ourselves lies about our ability to multitask and handle distractions, especially the younger generations.  Things like, oh kids these days have grown up with all that technology, their brains are wired differently as they chat, watch youtube and do their home work.  Our instinctive behaviours remind us that our brain rejects distraction. For instance, to really zero in on a faint sound in the distance we instinctively stop moving, shut our eyes, and focus entirely on listening carefully. Your brain does not multitask when it’s time to really pay attention.

I’ll often work from home when I’ve got something hard I need to just get done, it’s quiet and nobody can interrupt me (obviously if your home is full of kids, dogs and noise this need not apply to you).  How often have you said  or heard something like this ? “I come in early because that’s the best hour of the day” or perhaps “I come in late and stay back to get my work done” or simply, “I don’t come into the office when I’ve got real work to do”?

Email, Facebook, Twitter, Instant Messanger etc…

Donald Knuth has a wonderful webpage on his Stanford faculty webpage about email – this is my favourite section.

“Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. I try to learn certain areas of computer science exhaustively; then I try to digest that knowledge into a form that is accessible to people who don’t have time for such study.”

He goes on to describe how he likes to communicate in batch mode, once every three months.  Three months might be a little too long for most of us, but do we really need to check our email every three minutes ?  Come on, hands up if you click the send/receive button sometimes, even when your email checks every minute by default.  Facebook, Twitter, Instant messenger and pretty much all forms of electronic communication can be a major distraction if we as users of them don’t manage and mitigate it.  If you need to focus, turn them all off.  Don’t be tempted to just ‘check in’ or you risk losing short term focus or worse, ending up chasing a tangent to the task you really ought to be focused on.

There is a culture in some workplaces of needing to be always online, in a chat room or IM, instantly available to solve problems.  When there is genuinely an urgent problem – these systems work really well – but they command a high price in productivity, especially for developers.

Alistair Cockburn on Drafts

Alistair Cockburn has a great explanation in “Communicating, cooperating teams” to describe unwanted distractions created by co-workers in the office environment – Drafts.

“On the other side of their bank of cubicles sat the call center people, who answered questions on the phone all day. They also benefited from overhearing each other. But, and here was the bad part, the conversation of the call center people would (in his words) “wash over the walls to the programmers’ area.” There was a “draft” of unwanted information coming from that area.”

Beyond the nodes and contracts problems of large teams and large open workspaces, distracting drafts from other teams working near yours can be a major productivity drain. You only need to walk around an office, stand and listen to figure out if you have this problem.  If you can hear more than one or two simultaneous conversations at any stage, I think you’ve got a problem to solve.

The Winter of our Disconnect

A book about a single mum and her kids in Perth turning off all the screens in their house for 6 months might seem like an unusual place to find an epiphany, but that’s what happened to me.

Susan Maushart’s book, the Winter of our Disconnect is part diary, part drama and part scientific journal on the topic of distraction.  The stories of how addicted she and her kids are to being constantly connected, socially up-to date and online provides an uncomfortable mirror to most of our own lives.  Please buy a copy and read it.  It challenged some of my beliefs and cause me to face up to some deeper truths which I think I already knew were true about the cost of multitasking and distraction on the ability of our brains to perform.  Seriously, just buy it and read it.

Ultimately there are three kinds of distractions

Necessary ones – communication by definition requires some level of distraction from our deep cognitive tasks.  But … it’s also essential that we talk, design and work together to function as effective teams.  So while we should be sensitive to others when we do distract them, we shouldn’t shy away from it.

Self inflicted ones – Email, Twitter, Facebook, instant messenger and the telephone.  These are all things we can choose to turn off, ignore or just not have the first place.

Unnecessary ones – Cockburn’s Drafts,  music, selfish co-workers and poor environments all generate distractions which don’t add value.

Focus on having the best necessary distractions and eliminating as many of the self inflicted and unnecessary distractions from your work environment.  Finally, Conclusions.

Great Agile Workspaces: How we Communicate.

By | Uncategorized | No Comments

There’s more to software productivity than the physical environment.  Communication is equally important. A developer may be in the zone and writing perfect code, but if they are writing the wrong code because they’re isolated then we haven’t done anything to help productivity.  Frequently sharing information is essential to every project, and there are quite a few distinct levels:

  • Structured communication – Planned meetings, stand-ups and retrospectives.
  • Information radiators – Agile boards, build status lights etc.
  • Ad hoc but intentional conversations.
  • Osmotic sharing, serendipitous or ad hoc but unintentional conversations.
  • Tacit learning.

Experience, observation and research tells me the following two things are true:

  1. Writing Software, designing things, planning and strategy are deep cognitive tasks which require extended periods of focus to perform at a very high level.
  2. Communication is a distraction or interruption for deep cognitive tasks.

If we’re looking to create the best possible agile system, we need to consider carefully which communication modes we embrace, and what we reject.

We should encourage high quality forms of communication:

  • Face to Face conversations.
  • Group Stand-ups.
  • Whiteboard design sessions.
  • Team lunches, drinks, social events.
  • Agile boards, build lights, progress success metrics.

While avoiding low quality or distracting forms of communication:

  • Group Emails, especially email chains.
  • Paper specifications.
  • Instant Messenger.
  • Campfire / IRC / Team Chat Rooms.
  • General office chatter around workspaces.

Carefully embracing high quality serendipitous communication:

  • Overhead snippets around your workspace.
  • The ‘water cooler’.
  • Adhoc group problem solving or design sessions.

The most effective team I’ve worked with had a strong, if unwritten code of conduct about the way team members interact and communicate, respecting the value of productive blocks of time as well as plenty of time interacting both professionally and socially – this code was firmly cemented into the daily routine, with periods of communication and periods of quiet work.

The day starts with coffee, email, jokes and then stand-up around the Agile board.  Then there is a period of solid and fairly quiet work time until lunch; team members interact if they need too, but the goal is to balance distraction with productivity.  Everyone eats lunch together and the conversation nearly always comes around to some problem on that needs solving on the project.  Afternoon is solid for a while, but tails off at the end as people get tired and lose concentration – this is often a good time for group administration tasks like estimation.  Very often there is a social drink a few times a week.

When I worked at Ericsson there was a deeply ingrained culture about they value of communication and the importance of being face to face.  There were certain things that were acceptable to share via email, others required a phone call,  but all important or personal interactions were expected to be conducted face to face – even when that often required getting on a plane.  Not environmentally friendly, nor perhaps very cost effective, but it sent a strong single about the importance of being considerate about how we communicated.  I wish I could say there was such a strong sentiment about senior staff turning up to meetings on time!

I don’t pretend for a minute that this is something new – Lister and DeMarco have been talking about this since they wrote Peopleware in the late 80s and XP talks about managing communication and space via Caves and Commons.   Physical space is important, and communication is important – the final thing I want us to think about ties these two themes together, the price of distractions and multitasking.

Great agile workspaces – balancing space, communication and distraction.

By | Uncategorized | No Comments

This is a sneak peek at some of the ideas I’m going to talk about at Agile Australia 2011 in June (I’m open to ideas and feedback of course)

The core of Agile is all about communication.  Its routines and rituals encourage teams to communicate and plan as well as tackling their issues and problems as they share lessons from their achievements and failures. Our physical environment, communication culture and our attitude to multitasking and distractions are less obvious levers which can have a profound impact on our teams and how effective they can be.

In my mind the whole Agile movement is really just one part of answering our key question, how do we build great software that delivers real value ? I think the answer boils down to creating the right team, process and environment; this requires four things.

“Be obsessive about only hiring the best talent” – Me
Motivate them through “Autonomy, Mastery and Purpose” – Dan Pink
Recognise that “Culture eats strategy for breakfast” – Peter Drucker

Now we come to core of my topic, something two of my heroes have been talking about since they wrote Peopleware in 1987:

Have the “Correct environment, method, and structure” – Tom DeMarco and Tim Lister

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.  I often have this quote from Deming rattling around in my head as I look at problems at work.

“95% of the performance of any organisation is attributable to the system and only 5% the individual”

So over the next few posts I’m going to look at three key parts of our ‘system’.

The Physical Environment.

Jan Banning has captured these wonderful photographs of Government Officials in their office around the world.  Take a look at them and then stop for a minute. Imagine your ideal office … what would it look like ?

How we Communicate.

There is more to software productivity than just removing distractions. Communication is equally as important. A developer may be in the zone and writing perfect code, but if they are writing the wrong code because they are isolated then we haven’t done anything to help productivity have we ?

How we Multitask and Manage Distractions.

Our instinctive behaviours remind us that our brain rejects distraction. For instance, to really zero in on a faint sound in the distance we instinctively stop moving, shut our eyes, and focus entirely on listening carefully. Your brain does not multitask when it’s time to really pay attention.

Stay tuned for some ideas and answers.

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.