Skip to main content
Category

Uncategorized

Reflections on Agile in Australia

By UncategorizedNo 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!

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.

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.

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.

How they found Lunokhod 1 – still contributing to science

By Moon, TechnologyOne Comment

Any article on the internet that contains a photo as brilliant as this deserves promoting – but this one by Ariel Bleicher on IEEE from September 2010 is especially amazing, and contains the story of scientists rediscovering the little moon tank that could, and putting it to work again.

Just to add a weird twist to the story – the Lunokhod 2 moon rover was bought by this guy in 1993. Wonder what this one is worth?

Lessons from a Martian Mission

By UncategorizedNo Comments

NASA has just announced the end of the Spirit Rover mission on Mars after no successful contacts since it’s last communication on the 22nd of March 2010. Not a bad effort for what was planned as a 3 month mission starting in January 2004.  There are some great lessons that come out of these missions.

1) Their goal was simple and easy for everyone to understand – “Wear the rovers out exploring, to leave no unutilized capability on the surface of Mars”

2) Their planning was Agile – As the rovers lasted longer and longer the mission team kept rewriting their play book and planning new experiments – “What we initially conceived as a fairly simple geologic experiment on Mars ultimately turned into humanity’s first real overland expedition across another planet.”

3) Sometimes the greatest discoveries come in the most unexpected ways. After the front right wheel stopped working it started to act as a plow when the rover went into reverse; This unplanned ‘feature’ dug up bright white soil enabling one of the most exciting discoveries of the mission, pure silica deposits just under the surface indicating that previously the conditions required for microbe life existed.

You can read more here about Spirit and Opportunity, perhaps NASAs most successful and cost effective missions ever.

Getting a job *should* be hard.

By UncategorizedNo Comments

Today I gave a reference for a long time colleague and friend, most of the time the questions people ask when checking CV references are barely more sincere than the standard 4 questions real-estate agents ask when checking potential tenants. It’s a fait accompli.

A real employment exam: this 1964 photo shows a NASA scientist testing astronaut John Glenn’s inner ear balance mechanism by running cool water into his ear and measuring the effect on Glenn’s eye motions.

This time was different, it took 20+ min and they asked deep probing questions. We quickly got beyond the basics of establishing my colleague was capable and moved into questions about the best environment, growth areas and how to get the best out of this person. These guys really cared about getting the right person, but also that the job was right for them as well. They also wanted to know how to make it the best possible engagement for everyone. For them hiring was a long and through process which required a significant commitment from everyone involved, myself included.

When you audition to join the Berlin Philharmonic Orchestra, widely regarded as one of the very best in the world you play the equivalent of a full recital in front of the entire orchestra. It’s very very hard to get in, but when you do, everyone knows how hard it was and knows you’ve earned your place. After all, they were part of the group that picked.

If you’re hiring staff, be ruthless – it should be hard to get in. Stop and think about how much time you spend with an individual making a decision which has consequences (good or bad) which both you and your potential employee will live with for many years to come. Is a 45 min interview with someone from HR and one manager really enough ?

I often hear discussions of how arduous the hiring process at some companies is, and how it turns people off from applying. Google is (in)famous for it’s complicated and exhaustive hiring process. Turning people away because the process might be hard is a good thing. As a potential employee if you’re not prepared to invest a few hours, maybe even a few days in finding out if a job is right for you, are you really excited enough about working for the company ? Wouldn’t you rather know that everyone who you might be working with has had to step up and deliver against the same set of challenges, interview and interrogations.

Getting a job should be hard.

Great Agile Workspaces: Conclusions

By UncategorizedNo 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 UncategorizedNo 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 UncategorizedNo 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: The Physical Environment.

By UncategorizedOne Comment

The physical space we work in impacts on the way we feel, interact and how productive we are. 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 ?

Perhaps your office reflects your culture ?


Zappos

Or maybe your product ?

Our office at RedBubble

Or your design aesthetic ?

37 Signals

How about my ideal work space …

http://www.biscade.com/office/

From an Agile perspective office spaces have an impact on a number of key factors.

  • How it makes you feel.
  • How it encourages positive social interactions.
  • How it enable communication.
  • How it manages distractions.
  • How it enables productive development.

Lots of communication and a high level of development productivity are often in tension and balance needs to be struck.

I’ve worked in nearly every conceivable office environment over my working career. I’ve had a number of private offices, massive open plan call centre style environments and I’ve also worked in the stereo typical startup garage.  There is a strong trend, particularly at larger companies towards open plan offices.  I believe this is a mistake.

Private offices are great when you need focused time to get hard thinking tasks done, or you need to make phone calls or have lots of adhoc meetings – in many companies they are also a status symbol reserved for senior management.  Small collegiate workspaces, typical at startups or creative agencies etc are perfect for idea sharing, collaboration and create a fun and friendly workspace.  But they can also end up being being loud and distracting when it’s time to put your head down and write some code. I’m not sure large open plan environments are  ever a good answer and here’s why – It’s about nodes and contracts.

A team of 3 people, has to maintain 3 lines of communication, or three social contracts.  As the team grows to 5 people, the number of person to person, or node to node interactions jumps up to 10.  That means more time spent keeping everyone in the loop and up to date.  As the team grows to 10 the number of contracts is more than 40.  Quite clearly this style of person to person communication isn’t very scaleable.  Imagine an open plan workspace with say 100 staff, the social contracts break down.  You loose the benefits of lots of connected personal communication between everyone, but you suffer all the negative impacts of noise, interruptions and distraction generated by that many people.  It also becomes necessary to resort to all hands meetings and so-on as it’s not practical to run a standup with that many people.

So what does the ideal environment look like ?

I think the answer is the smallest possible number of people in separated but accessible spaces that still allow everyone working on the same ‘thing’ to work collaboratively together. What does this look like in practice ?

Here’s one very successful setup for us at Lonely Planet.

This is how our Lonely Planet Operating System team of 20 people works.  It’s broken into 3 major groups of people, each working on their part of the project, or their ‘thing’.  We have one big long bench where 8 developers work mostly in pairs, and near by them are some of their primary customers, the SMEs.  We moved all the product, planning and generally loud talky people away a little bit.  These guys are not far away, but it’s a big improvement from when they were dotted among the development team.  There are a number of small meeting rooms and a dedicated quite working space with a few development machines and whiteboards etc.  Finally there is a dedicated planning / war room which has whiteboard paint on all the walls, it has a constantly changing view of ‘the plan’, ideas for future development and the day to day agile board on it’s outer wall.  There is of course regular communication between all three groups, but the primary and constant communication is restricted to on topic conversations within each group.

So small groups of people working closely together, quite spaces and shared spaces.   You might need to think carefully about how to break down some of your big ‘things’ to ensure the number of nodes and contracts is sensible; and that, leads nicely into my next theme: Communication.

Great agile workspaces – balancing space, communication and distraction.

By UncategorizedNo 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.

Luna Guest: “You are NOT a Software Engineer!” by Chris Aitchison

By Uncategorized3 Comments

You are not a Software Engineer. You do not build skyscrapers. You do not build bridges.

You grow gardens.

You are a Software Gardener.

Do you try to plan your gardens in such detail that you know where each leaf will be positioned before you plant a single seed? Do people expect estimates (or are they promises in your organisation?) on exactly how many flowers will have bloomed in one years time? Do you have a bonus tied to that? Things that would be perfectly reasonable to plan for a skyscraper seem a little ridiculous when you are talking about a garden.

You probably have a good idea of what your garden should look like a week into the future. You might even have a rough idea of the shape you expect it to be in a year from now. But you have no idea of where each branch, leaf, stem and flower will be a year from now, and if you say you do then you’re really only guessing.

If you were building a bridge or a skyscraper and you told me, before you began, that you knew exactly how it would look when it was finished – I would believe you. If you told me that you knew to some insane degree of accuracy how long it would take to get to ‘finished’ – I would believe you again. That’s how Engineers roll. Tell me the same thing about your garden and I’m gonna call bullshit. Tell me you are going to make it grow faster by hiring more gardeners and I’m gonna laugh at you.

So why do so many gardens fail, yet so many skyscrapers succeed? With a few exceptions, the technique for building a skyscraper is similar whether you are in Europe or you are in Singapore. Gardens do not work that way. Every garden is different because the environment it is in is different. Even gardens that are within throwing distance of each other can have wildly different soil. That is why the lowest bidder can probably build the same bridge as the highest bidder, but your company can’t grow the calibre of gardens that Google can grow.

Remember that time when someone in your company unsuccessfully used an Agile gardening methodology, and then went around saying that it was horse shit that doesn’t work? Well horse shit does grow gardens, it just wasn’t enough to save your garden. Your garden was probably dead before it started – a victim of the climate of your organisation. Were you trying to grow a rainforest in the desert? You can’t just plant the same plants as Facebook, Flickr or Twitter and expect them to take root regardless of the quality of your gardeners or the climate of your organisation.

Unlike a skyscraper, your garden will grow weeds. It will never be ‘finished’. Just because you stop spending money on it doesn’t mean it is finished. If you stop weeding your garden the weeds will eventually smother it, and soon a re-plant will look easier than a pruning. The environment around your garden will also always be changing, and a neglected garden will become harder and harder to keep alive.

In most countries, Engineers need a license to build a bridge. Gardeners have no such government-mandated quality control. Unfortunately, the quality of your gardeners is going to have a bigger influence on your gardens success than any other factor – so you’d better be good at picking the wheat from the chaff. Only an experienced gardener really knows another good gardener when they see them. Someone who has merely managed gardening projects will have no idea what they should be looking for (though they won’t know this). So if you are not a gardener, but need to recruit good gardeners, then quickly find an experienced gardener you trust to vet your candidates. You can’t learn gardening in a classroom, so remember to focus on gardens your candidates have grown before, rather than how much gardening theory they learned at school (which nearly always won’t be applicable to the climate you are growing in anyway).

The engineering metaphor has had its time in the sun, and maybe it even used to be accurate, but now it really only serves to help non-technical people have unrealistic expectations about how software gets built.

I am a Software Gardener.

So are you.

(From http://chrisaitchison.com/)

Luna Links – Africa, Microsoft and Myspace plus Tron

By Uncategorized

The True Size of Africa (A visualisation) – I can’t help but have a flash back to the organisation of cartographers for social equality on the West Wing.

Did The Microsoft Stack Kill MySpace ? – This post, plus the original case study by Robert Scoble is long but essential reading for anyone involved in a large technology project.  If you can’t get through it because facebook, blogs, sms, twitter and the internet have destroyed your attention span then read this cheats version of the article instead, there is lots of important stuff in there though.

Tron Legacy Special Effects – Beautify imagery and effects for the movie with some insights into how they were made.

Akin’s Laws of Spacecraft Design

By Uncategorized

Akins has collected a wonderful set of laws for Spacecraft Design, most of them are equally relevant for other engineering projects.  Just be glad that rule 40 doesn’t apply to your project.

1. Engineering is done with numbers. Analysis without numbers is only an opinion.
2. To design a spacecraft right takes an infinite amount of effort. This is why it’s a good idea to design them to operate when some things are wrong .
3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.
4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.
5. (Miller’s Law) Three points determine a curve.
6. (Mar’s Law) Everything is linear if plotted log-log with a fat magic marker.
7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.
8. In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.
9. Not having all the information you need is never a satisfactory excuse for not starting the analysis.
10. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along.
11. Sometimes, the fastest way to get to the end is to throw everything out and start over.
12. There is never a single right solution. There are always multiple wrong ones, though.
13. Design is based on requirements. There’s no justification for designing something one bit “better” than the requirements dictate.
14. (Edison’s Law) “Better” is the enemy of “good”.
15. (Shea’s Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.
16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.
17. The fact that an analysis appears in print has no relationship to the likelihood of its being correct.
18. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.
19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you’ve screwed up.
20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.
21. (Larrabee’s Law) Half of everything you hear in a classroom is crap. Education is figuring out which half is which.
22. When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)
23. The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.
24. It’s called a “Work Breakdown Structure” because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.
25. (Bowden’s Law) Following a testing failure, it’s always possible to refine the analysis to show that you really had negative margins all along.
26. (Montemerlo’s Law) Don’t do nuthin’ dumb.
27. (Varsi’s Law) Schedules only move in one direction.
28. (Ranger’s Law) There ain’t no such thing as a free launch.
29. (von Tiesenhausen’s Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.
30. (von Tiesenhausen’s Law of Engineering Design) If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist’s concept.
31. (Mo’s Law of Evolutionary Development) You can’t get to the moon by climbing successively taller trees.
32. (Atkin’s Law of Demonstrations) When the hardware is working perfectly, the really important visitors don’t show up.
33. (Patton’s Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.
34. (Roosevelt’s Law of Task Planning) Do what you can, where you are, with what you have.
35. (de Saint-Exupery’s Law of Design) A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
36. Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.
37. (Henshaw’s Law) One key to success in a mission is establishing clear lines of blame.
38. Capabilities drive requirements, regardless of what the systems engineering textbooks say.
39. The three keys to keeping a new manned space program affordable and on schedule:       1)  No new launch vehicles.       2)  No new launch vehicles.       3)  Whatever you do, don’t decide to develop any new launch vehicles.
40. Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there’s no partial credit because most of the analysis was right…)
(source – http://spacecraft.ssl.umd.edu/akins_laws.html)

Conway’s Law

By Uncategorized

While Nigel has you thinking about how you govern your agile projects I want you to spend some time thinking about a man by the name of Melvin Conway.  In 1968 he made this observation:

“…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

I often paraphrase this as:

“Your system’s architecture will match your org chart”

Even with the flattest, non-hierarchical org structure the way you organise your teams, even the way they are physically situated leaves a lasting finger print on any technology platforms you build.  If you have three teams which are fairly autonomously building a large system, don’t be surprised to find three different applications communicating via a series of APIs.  If you have a geographically distributed team, expect to find highly modularised systems with lots of code focused on decoupling.  If you have a large monolithic development team you’ll find a large monolithic application.

This is especially true of agile projects where decisions about your platforms are not taken by a command and control style group of enterprise architects but instead handed to the builders of individual components.  Often when talking about org design I hear something along the lines of this … “There is no perfect org structure, so this one will do” … while I think the first part is true, take a moment to think if the org structure is going to breed a sustainable platform architecture before you decide if it will do.

“Any darn fool can make something complex; it takes a genius to make something simple.” – Albert Einstein.

Changing to Agile – a messy metamorphosis

By UncategorizedNo Comments

Nigel Dalton speaking at Agile Australia 2009 on Changing to Agile

A picture I have used often to talk about the journey to Agile ways of working shows a series of beautiful chrysali hanging from a branch.

The audience are generally lulled into a serene state as they presume I’m saying the change will occur silently, secretly before their eyes.

But the purpose of the image is to illustrate a wonderful quote from Pat Barker‘s Regeneration Trilogy, a remarkable story tracing the treatment of officers returning from the hell of World War 1’s front lines at the Somme with bizarre injuries that see them struck dumb, wracked with pain when they have no wounds, and generally insane. The men are treated by a Dr Rivers, who experiments with radical new approaches to reach inside the men’s minds to where the damage has been done.

“Rivers knew only too well how often the early stages of change or cure may mimic deterioration. Cut a chrysalis open, and you will find a rotting caterpillar. What you will never find is that mythical creature, half caterpillar, half butterfly, a fit emblem of the human soul, for those whose cast of mind leads them to seek such emblems. No, the process of transformation consists almost entirely of decay.”

My point is that if you get overly-analytical on the state of your transformation to Agile’s better, smarter ways of working, you (or gasp, your program office heaven forbid!) will likely find a mess. Give it time – the agile butterfly is going to take at least a year.

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.