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.

Epiphanies

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!

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!