Tuesday 23 December 2014

DevOps - what does "good" look like?

I've blogged a lot about my definition of DevOps and what it means to me.

I've always thought it much larger than "Dev" and "Ops" and that there isn't really an end state - it's an ever changing idea that will adapt to meet the needs of the business.

That said, I'm asked quite often what "good" looks like?  How do you know you are on the right path?

For me DevOps is a primarily a cultural idea.  If the culture is right then the technology and people will follow.  I talk to a lot of people who see this word "DevOps" and reach out straight to technology.  DevOps isn't another word for automating Cloud servers...

In order to an effective "DevOps" organisation I think you need 4 main pillars:

  1. Culture - does the culture of your company promote collaboration, self improvement etc?
  2. Process - you need to have processes that support different silo's working together to achieve a fast pace of change
  3. People - if you don't have the right people then it doesn't matter how great your technology is.  People and culture are very linked but I've tried to separate them here to demonstrate qualities that individuals hold vs values that the company holds
  4. Technology - what are the building blocks you need to be a mature DevOps enterprise?

The following is very much my view of what "utopia" looks like.  The truth of the matter is that DevOps means different things to different people depending on what you are trying to achieve.  For example, you absolutely don't need to use public Cloud to achieve DevOps.  However, I do think it's a good pattern to promote working on high value tasks (rather than undifferentiated heavy lifting**) and using a common change process between development and Ops teams.

This is where I want my company to get to...


Culture
  • Measure everything, always
  • Individuals have empathy for the rest of the team (i.e. they don't pass the buck)
  • Shared goals and incentives
  • Don't reward the fire fighter, reward the fire preventer
  • Reward innovation and challenging the status quo
  • Don't punish people when they try something new but fail
  • There is no IT and "business".  IT as much "the business" as the sales people.
  • Seeking to break down silo's
  • "It's not my job" doesn't exist
  • "Its my server/code/network/database" doesn't exist
  • Individuals are empowered to make decisions
  • Top-up management rather than top-down


People
  • Restlessnes (relentlessly looking to improve themselves, others, processes etc)
  • Good technical ability across a broad skill set (understand as much of other people's jobs as possible)
  • Everyone can code and use version control
  • Everyone understands the test triangle
  • Dev-test pairing
  • Organised in small product focused teams rather than technology silo's (align teams to the business not the technology)
  • Common incentive schemes
  • Favour automation and repeatability above anything else
  • CIO/CTO are DevOps biggest guardians & SME's and seek to destroy anything that affects that  culture
  • Natural face-to-face influencers rather than endless emailers
  • Natural sharers of information
  • Take an interest in their specialism outside of work (i.e. go to conferences and take part in the wider community)

Process
  • Agile
  • Continuous Integration
  • Continuous Delivery
  • Lean
  • Fail-early, fail often
  • Release management team are facilitators of change not guardians of change (i.e. they try and aid change rather than stopping/slowing it)
  • All change (I mean all) goes through the pipeline from left to right (dev, test, acceptance, production)
  • Knowledge sharing and "just enough" documentation is part of the process
  • Measuring success and failure is part of the process
  • Retrospectives are part of the process


Technology
  • TDD/BDD everything (including Puppet etc)
  • Everything is in version control (code, automated tests, server config etc)
  • Release automation tooling
  • Convergent desired state tooling
  • Cloud (private or public but the ability to spin servers up on demand)
  • The same trending, monitoring & alerting solutions available through nonprod & prod 
  • Application Performance Management
  • Service Virtualisation
  • Continuous Integration
  • Continuous Unit tests
  • Continuous Service level tests
  • Continuous GUI tests
  • Performance testing

If you can get half way to delivering all of that then I think you should be in a very good place indeed.

It's a long hard journey if you are a traditional Enterprise.  Nothing worth achieving was ever easy though!

I'm outta here for what proved a fantastically successful 2014 (personally and work).  2015 is a massive year too for me but good luck in whatever you have planned ahead.

Happy Christmas to you all!

J
xx



Wednesday 3 December 2014

DevOps Rugby



I spoke at IBM DeveloperConnect a while back talking about DevOps and how it relates to what I'm doing in my current company.

That isn't particularly interesting in itself.  The really interesting thing was at the end of the day where I was well and truly blown out of the water by the key note speaker.

The key note was held by Kyran Bracken MBE (http://www.kyran.co.uk/) the World cup winning, ex-England rugby scrum half.

Firstly its impossible to compete against someone who has won the rugby world cup and captained the national team in your favourite sport.  In fact, I came away thinking I've never accomplished anything in comparison.  Soul destroying!

Kryan talked at length about the role of a manager vs. a leader, the importance of challenging convention and taking risks.

It was an hour speech so I won't document it all here.  However I thought the 3 things above are relevant to the world of DevOps.

Manager vs Leader
In a well functioning DevOps function, the team is empowered to make decisions.  You don't need a manager telling people what to do and how to do it.

However, you do need a leader.  Someone that wants to creates the future and inspires others to join him/her on a journey.

The leader welcomes risks because no one ever accomplished anything great by playing it safe.

Both Martin Johnson and Clive Woodward were leaders.  Martin because he inspired people and Clive because he challenged so many conventions...

Challenging convention
The only way to improve things is to take the status quo and change it/improve it.  You can't get better standing still.

The Leader facilitates these challenges and encourages them.  Its very healthy to look at what you do and critique it - even if it works really well as the current convention.

Don't rest on any laurels.

Before the World Cup England had a good team but in order to get that extra 1% from somewhere they needed to challenge long held conventions.

Most teams before mainly worked on training to improve their attack.  However, through statistical analysis found that teams with the best defense tend to win games.  They then spent a much greater proportion of time working on defense.

Traditionally, rugby player wore heavy jerseys like this:




They are really heavy when wet, don't let the body breathe and are easy to get a grip on them. The 2003 World Cup team were the first to champion the skin tight Lycra ones that everyone wears nowadays.


Taking risks
Trying new things can be seen to be risky.  However if you want to separate yourself from the competition you need to take risks.

Clive Woodward had the team training their eyes and working on other new techniques that may have been derided if they hadn't won the World Cup.

If your team doesn't take risks or is punished for every failure then they will never move forward.  Taking risks should be encouraged and not penalised if it doesn't work.  Learn from those failures and move forward.