This workshop is ideal for around 3 groups of 5, but it can accommodate more groups and slightly larger groups.
To provide a safe environment to explore the deeper ideas of DevOps with a realistic scenario that participants can relate back to their own department and team situations. Participants will leave the workshop with one of either:
- Ideas of things to implement within their own teams
- Desire to rebuild the workshop specifically for their team/organisation and run in house
What is it?
Groups of 5 will be given a business scenario which will present a variety of different symptoms of issues and problems, from bloated build times, failure to deliver for the business, high churn rates and various others. They will then be taken through the workshop in the following steps:
- Identify route cause by classifying in the CAMS quadrant (Culture, Automation, Measurement, Sharing)
- Identify the biggest root cause area from the CAMS quadrant that has the largest negative impact
- Come up with different ideas of what could be done in that area
- Identify the top 3 experiments to take forward based on the criteria of cheap and high value
Groups will typically identify Culture or Sharing as the main problem, with measurement typically coming next. Automation is often the last thing that people focus on. This is usually a revelation to participants as this tends to go against the typical misconceptions around DevOps. Those teams who do select Automation can usually be challenged on their choice and result in selecting a different option and start to view Automation more as a side effect, and core focus only once the other areas are resolved.
This is especially useful for CTO, CIO and Dev Managers who are often expected to already know what these concepts are and often struggle to get a clear picture of what the concepts really are due to the nature of their positions.
This can also be incredibly useful for tech teams, junior right through to senior, as it will enable them to change their focus to build a good culture and consider the measurement and sharing aspect. It is at this point that Automation really starts to shift from a core focus, to a tool in order to support Culture, Measurement and Sharing. It is important to note thought that whilst Automation supports, in and of itself it is useless without the direction of Culture, Measurement and Sharing. Even with Continuous Integration, without the direction of Culture and Measurement to help identify what the right things to build are, and what a good build looks like, not to mention the culture around including testing early, then Automation can quite quickly cause a lot of noise and deliver very little, albeit consistently (in most cases).