Tag

DevOps

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.

The Truth about DevOps

By | Development

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

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

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

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

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

So here’s what it really is:

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

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

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

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

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

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

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.