Requires System Thinking
DevOps creates a process (system) where by the development team and IT operations teams communicate issues, define priorities, complete work and report outcomes. DevOps grew out of the necessity that development and IT operations teams understand who is doing what and when each team is ready for the other to take action. Before Dev Ops was created, development teams typically threw their work “over the wall” to an unprepared operations team. Expectations were unclear and timelines were not communicated. A general sense that the other team was irresponsible or did not care, was in the forefront of the relationship. This often led to even weaker communication resulting in poorer customer satisfaction and quality of service.
The goal here, is to give Scrum Masters a high-level view of the Operations side of the system. How the development and operations teams agree on who does what, keep each other in the loop and report their current status and issues, may be covered in future posts.
Value Proposition
DevOps builds a culture of collaboration between teams that historically rarely interact. This interaction is supported by establishing working agreements, daily Scrum of Scrums and information dashboards detailing the system where by work is completed.
Typical DevOps System
“Inspect and Adapt” your system as you discover and address constraints. You may need to consider various Agile Frameworks along your journey, but keep it simple. I have had a lot of success using Kanban as in his example.
- Create a backlog of issues reported by any team (development, customer support, senior management).
- Consistently prioritize this backlog based on predefined categories of urgency agreed upon by the reporting parties.
- Each DevOps member takes the top issue and begins work on that item.
- Based on the system in place the team member either completes the task or passes the task to another in the work flow.
- The process moves along a predefined path until completion.
System Example
Kanban board showing the following columns:
- Ready
- In Progress
- Done
Basic Metrics
- CT or Cycle Time (average time items flow through the system from beginning to end.)
- WIP or Work in Progress (amount of items flowing through the system from the first to last task)
- TH or Throughput (average rate at which items leave the system — reach completion
Basic Formula
(one or the other)
- TH = WIP / CT
- WIP = CT * TH
Helpful Diagrams & Charts
- CFD or Cumulative Flow Diagram (Reports the cumulative flow of issues through the system. Quickly reveals delays or constraints.)
- Cycle Time Scatter Plot aka Control Chart (Reports issues or groups of issues “out of bounds”. Quickly exposes issue types which take longer than planned.)
Why Track the Numbers?
As with all Agile methods or frameworks, DevOps greatest attribute is to “inspect and adapt”. The purpose of all metrics is to …
- Convey a general understanding of the system.
- Support transparency throughout the system.
- Expose constraints.
- Offer the development and IT operations teams an opportunity to update the system for greater efficiency.
Typical Mistakes
No WIP Limit: Each process (step) along the system should have a WIP Limit. This keeps issues from piling up. If too many issues collect in a column, the team typically looses focus of the priority and items are not finished on time. The quality of the service is reduced and customer satisfaction suffers.
Unwilling to change system: If issues are consistently late and priorities not respected, the system may require an update. An understanding that no system is perfect and will require consistent improvement, increases efficiency and ultimately customer satisfaction. The key is to keep the system as simple as possible.
Conclusion
As you mature along your Agile journey, you will gain a skillful eye at identifying systems that produce valuable customer outcomes. DevOps represents another piece of the system where we can apply Agile values such as, individuals and interactions over processes and tools and responding to change over following a plan.
Additional Resources
- Actionable Agile Metrics for Predictability by Daniel S. Vacanti (explains the importance tracking the numbers for predictability.)
- Large-Scale Scrum: More with LeSS by Craig Larman and Bas Vodde (crash course in systems thinking.)
- The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt and Jeff Cox (presents compelling argument for “systems thinking” and continuous improvement)
Training (Southern California)
- Additional Agile Training & Certification by Rocket Nine (LeSS and Kanban)