I had the privilege of presenting my DevOps experiences, based on a talk I delivered at the devconf event in South-Africa earlier this year.

The trip started with a scenic, but foggy Seaplane flight from the Vancouver harbour to Victoria. See Foggy trip to Victoria DevOps Meetup for a few eerie pictures :)

The core of the discussion was around the five (5) HABITS we learned about during our DevOps journey - Customer Focused, Shift Left, Team Autonomy, Production First Mindset, and Infrastructure as a Flexible Resource. The first four are Agile DNA strands that are inherited by DevOps. The last two are where DevOps really lights up.

Quick Reference Poster - DevOps Habits

You can find the meetup deck here or on our meetup GitHub repo.


The four epiphanies I mentioned:

  • CUSTOME FOCUSED - Feature flags are extremely valuable and powerful … if used correctly and technical debt is managed. Feature flags are not intended to hide code in production that is not production ready.
  • PRODUCTION FIRST MINDSET - The 2AM wake up call is the best motivation for a production ready mindset. Pull any engineer into an early morning live site incident a few times and the quality bar is magically raised.
  • TEAM AUTONOMY -  Cross-functional teams who own and take responsibility for features from ideation to deprecation, are the ones that collaborate and delight their customers the most. They are also represented in 2AM calls the least :)
  • SHIFT LEFT - Automation and performance are key to convince engineering teams to embrace SHIFT LEFT practices. Once engineers see the value and realize that greater quality results in less live incident calls, they will evangelize the practice for you. It’s all about the 2AM call!

Key HABITS discussion points:

  • We need to be customer focused.
    - Listen to and delight our users
    - Measure key performance indicators (KPI)
    - Experiment to maximize learning and influence value
  • We need to have a production first mindset
    - Remediate at root cause level and be transparent with cause and resolution
    - Automate and version everything
    - Everything is and happens in production!
  • With autonomy comes great responsibility
    - Feature team owns feature from ideation to deprecation
    - Management owns the WHAT + WHY  - engineering owns the HOW
    - Transparent collaboration amongst cross-functional teams and leadership
  • Shift Left!
    - If we raise the quality we can ship, get feedback, and react quicker
    - Higher quality results in less 2AM calls and an increase in delighted users
    - Pull request encapsulates prod-ready features and protects the target branch

Top questions

I'll update this list as more discussion threads are spun up post-meetup.

Last updated on 2018.10.22

  • Are there more printouts of the posters we had at the meetup?
    I left a pile of printed posters with the meetup organiser. Let me know if you're unable to get a copy and I'll make sure I get a copy to you.
  • What's the ratio of developers and testers in a typical DevOps teams?
    Team size is optimally 6+-3, up to 12 in a co-located environment. There is no developer:tester ratio in a cross functional team. Every member is an engineer who switches into whatever mode is needed by the team.
  • Are all engineers able to be cross-functional and self-organised?
    A cross functional team consists of T-shaped members who complement each other with a breadth of experience and skills (horizontal), and depth in some(vertical).  Not every engineer is willing to or able to be cross-functional, which means that you may experience a churn of engineers, losing those that cannot adapt and winning those that can. It's a team effort!
  • Why is the Pull Request a pivotal quality bar?
    The pull request is not a regular "let's commit and review my code" feature. A pull request encapsulates a feature or bug fix that is production ready. It validates that the feature builds, passes all automated unit tests, security, compliance, and other scans, complies with the organisation's governance, the team's definition of done, and is approved by human approver. The code may be feature incomplete, but must be production ready.

Thanks everyone for a great evening and the vibrant discussions. A special thank you to Brent reed for hosting the event!