Monday 18 August 2014

Daddy DevOps

2350073q9huagsinx

I found out this week I'm going to become a Dad.

It's a strange mix of emotions from excited, to terrified, to panicked and happiness.

Not too dissimilar to undertaking a big new project, scoping out how complex it is, getting close to go-live and then delivering it :)

[if any one you say I should use Agile processes for childbirth go to the back of the class - having a baby is definitely Waterfall]

At the moment I have time on my hands, which is probably one of the reasons I blog.  Time also gives you the room to think and ponder.  And because I spend all day, every day talking about DevOps I tend to think about it even in my downtime (and sleep) which is fairly plentiful despite a busy day job.

With my partner away this weekend, bored of playing on the Xbox and all my friends busy/married/parents, I've done a fair bit of sitting around of late.

I got around to thinking about how DevOps might compare to parenthood and I think there are some good analogies there.

My goals of being a good Dad are:
  1. Ensure that the family is provided for
  2. Ensure the health of my child
  3. Ensure that the baby is happy
  4. Ensure my partner is happy and supported
  5. Ensure that the family are safe
My partners goals are probably very similar so we shouldn't have to worry about pulling in different directions too much.

So that's cool, we have 2 different parties (Mum and Dad) who's goals and incentives are aligned and will work together to accomplish them.  The missus might not know it, but she's soon to be living DevOps!

I want to be a good Dad (and partner) and I've been thinking about what I can do as an individual to contribute towards our shared common goals?  And how do I make it easier for my partner to achieve her goals?

Commonly, DevOps teams turn to automation in order to break down the silos between them and meet their common goals.

If I could automate the changing of a nappy that would help!

I'm not sure I can automate nappy changes (I'd be very rich if I could).  Does anyone know if Puppet have a Pampers module?
    
    nappy { '/baby/bottom/':
      ensure => clean,
      owner  => 'parents',
      type => 'huggies',
      source => 'crib',
    }

Alright so I'm going a little off topic here.  My point being that we have two different resources who goals are the same (i.e. ensure the health and happiness of little Johnny).

The stereotyped Dad in the 1920's that went to work and had little to do with bringing up the child is a good example of a silo.

I've gone to work, it's your responsibility to look after the child - it's not my problem


Apart from the fact I want to be involved and I want to help my other half, I'm incentivised to help as much as possible because if I contribute then ultimately the happier we'll all be.

That's DevOps.  Changing your behaviour in order to meet shared goals.

Super excited.  Lets just hope the delivery isn't Continuous.

Saturday 9 August 2014

Motivations of the techy

I spent an hour the other day with the team discussing what their personal motivations were for working at the company.

The team is a mix of contractors and permanent staff.

The idea was two fold. Firstly, by understanding their motivations I would be a better manager and could help incentivise them in the right way. Secondly, by revealing their ambitions they would be motivated to produce metrics which would help them achieve their goals.

These metrics are key to proving the business value of the team and will help prove its success and extend its influence (which are my personal goals).

I assumed that everyone (especially the contractors) would say money is a key driver for them. I was wrong.

Everyone and I mean everyone, talked about company culture as one of the prime reasons they work where they do.

Interesting.

It makes sense I guess. If it was all about $$$ then they might be doing more lucrative and money focused roles. Maybe that's too simplistic? I guess people (including myself) want it all but are more prepared to sacrifice money in the search for happiness.

I've only ever worked in an IT role but I know bankers, brokers and finance types and for the majority of them it's about the bucks.

No real end point to what I'm saying except to say you need to understand what motivates your team in order to incentivise them. That sounds super obvious but it was a little light bulb for me.

Thursday 7 August 2014

Finding the right consultancy is hard

There are lots of different types of IT consultancies; big, small, modern, old fashioned, expensive, even more expensive...

I have to admit a bit of a mistrust when it comes to most large consultancies and in fact I'm generally not a huge of fan of outsourcing come to think of it.

I've seen consultancies (charging astronomical rates), send 6-7 consultants to an engagement when 1-2 were required.  Why?  Ramp up the revenue of course.  How can you be expected to hire a company who aren't incentivised to do the best thing for you?

The aforementioned then tell you need to buy  software X from them in order to solve problem Y.   Again, self interest and a fundamental misalignment of incentives between you and them.

Lots of consultancies come in and tell you what you knew already, along with a Gartner magic quadrant to let you know what you should be doing in the future (its not hard to find out yourself).  OK, so some validation is nice once in a while but the majority of consultancy engagements I've worked on I've have wanted to solve real world issues and not death by SmartArt and PowerPoint.

Just tell me what buttons to press!

Perhaps I should point the finger back of blame back at myself and I haven't led the engagement effectively enough so that I achieved the results I wanted. However, at a squillion pounds a day you'd think they would get to the root of what you are trying to achieve pretty quickly.

I'm tarnishing the whole consultancy trade here and to be honest of course there are some good ones; they are just hard to find.  I tend to work better with the smaller consultancies, although I've had some really good engagements with ThoughtWorks.

Another pattern with the big consultancies is that they are staffed largely by consultants who are good at theory but haven't really ever lived the jobs they are talking about.  How can a consultant that's worked his way up the ladder from university ever tell me about how to structure my unit tests?  Or the best way to structure my automated deployment?  You need battle scars sometimes.

What has this got to with DevOps?  Well I guess if you are an Enterprise who wants to move to DevOps your natural reaction might be to find a correspondingly large consultancy.

Personally, I'd start really small and hire a really good focused team.  Don't engage on some 7 figure consultancy engagement.  Build a small team and grow success organically.

Wednesday 6 August 2014

Why Continuous Delivery doesn't go far enough


My team “owns” (ensures that they are supported, provides best practises) a number of different tools and technologies in the DevOps space including:

  • Puppet Enterprise
  • IBM Urbancode Deploy
  • Jenkins
  • Teamcity
  • TFS
  • SVN
  • Artifactory
  • Selenium
  • Octopus Deploy

...and numerous others.

That’s quite a long list for a Continuous Delivery tool chain (made worse by natural Java and .net divides).

Tools that don’t integrate become silos of their own and encourage a divide between different disciplines (such as Dev and Ops).

It’s important to see the aggregate efficiency of your delivery pipeline and having a thousand different tools involved makes this difficult.

  • How many regression tests do we do a day?
  • What is the ratio between bugs captured in CI against those in SysTest?
  • Is there a relationship between the speed of a build and the number of deployment we do in a sprint?
  • Etc etc

Only by capturing these metrics can we improve our efficiency by highlighting and attacking bottlenecks.

Continuous Delivery is a process to improve the delivery of software change into production. 

For me that doesn’t go far enough.  Are we saying we don’t care about it once our changes have gone live?

We have this nice, shiny Continuous Delivery pipeline to deliver value to the business – usually in the form of increasing revenues somehow.

So, ultimately it’s not really about builds, testing and deployments.  It’s about what impact our change team makes to the bottom line.

For example...
  • What is the relationship between regression tests carried out in Systest and the number of errors that appear in production?
  • What is the relationship between production errors and revenue collected?
  • What is the relationship between how many story points we put in a sprint and the sentiment of our customers?
For me, this is the ultimate expression of DevOps.  We are aligning our delivery capabilities and processes in order to meet shared goals (in this example increased revenue).

I’m currently designing a proof of concept with Splunk to collate all these different types of metrics from the many  environments and tools we have in the delivery pipeline.   We should then be able to understand the different relationships between the capabilities in the team and the decisions we make.

Isn’t it powerful to have data which says to the business “stop putting too much change in a sprint”?  

Or that prioritising new features over technical debt is counterproductive to the bottom line?

I don’t expect that this will be an easy thing to accomplish and we can only infer these types of relationships.  However, the potential benefits are huge.