Gounding DevOps and Continuous Delivery

Andy McGrath Coaching, Coaching Page News, News

As we work with organizations looking to adopt a more continual ability to deliver software, some patterns start to emerge.  Once we start moving the thinking around DevOps and Continuous Delivery, the groups we work with are able to start making more tangible changes.  While they aren’t ‘Etsy’ yet, they are establishing a solid foundation and moving their ability forward.

  • Shift default thinking from ‘Test Everything‘ to ‘Make Things Testable
  • Move from ‘Automation‘ to ‘Removal
  • Focus on ‘People Communicating‘ instead of ‘Standards / Committees of Excellence

Testability over Tons of Testing

Yes, you need to have good testing practices in place if you want to be able to build and deliver safely.  Arbitrary goals around coverage or increasing test cases are meaningless and solving the wrong problem if initially your product simply isn’t testable.  Can you recreate states consistently? Can you control the data you want to test, along with the connectivity, versions, and dependencies?  If you don’t have a repeatable, testable space to have testing happen, testing more compounds the problem.

It’s Less About Automation and More About Removal

Without automation, the cost of doing tasks in small batches becomes unwieldy.  Yes, automation is needed.  Automating your current state of environments is usually the wrong approach.  When teams look at what it takes to be comfortable delivering a product slice – the varying levels of tests and dependencies – and focus on that first instead of the ‘environment / server’ more interesting conversations happen.  We can start looking at removing redundancy and removing complexity before we automate.  Automating complexity is a fool’s game, removing unnecessary complexity makes meaningful automation easier.

Get People Talking Instead of Committees Decreeing

We want all of our teams to be doing the same thing, using the same tools, in the same way.  The thought process then is naturally to have a committee that determines the best way to use said tools and pushes them down.  There are two large problems there – you want continuity in the tool usage, but the problems aren’t the same.  One team is a producer, another a consumer, another independent, another legacy. Problems need contextually aware solutions.  The second problem is the removal of ownership of solving the problem from the team dealing with it.  Instead we want to have teams working together, sharing ideas, and continually evolving their toolset in the context of their needs.

With these three simple changes, organizations start spending less time with big DevOps initiatives and more time building an environment that supports the ability to learn about their product continually.