DevOps Overview for Scrum Masters

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.

  1. Create a backlog of issues reported by any team (development, customer support, senior management).
  2. Consistently prioritize this backlog based on predefined categories of urgency agreed upon by the reporting parties.
  3. Each DevOps member takes the top issue and begins work on that item.
  4. Based on the system in place the team member either completes the task or passes the task to another in the work flow.
  5. The process moves along a predefined path until completion.

System Example

Kanban board showing the following columns:

  1. Ready
  2. In Progress
  3. 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

Training (Southern California)

About Larry

Passionate, experienced Agilest with a love for Scrum and Kanban. Huge fan of Lean, Theory of Constraints and of course the Toyota Production System. Avid learner. Deeply influenced by the works of Jeff Sutherland, Ken Schwaber, Eliyahu Goldratt, Jeff Patton and countless others. Active in both the PMI and Agile communities in Southern California.
This entry was posted in Recent Posts, Scrum Master Stuff and tagged , , , , , . Bookmark the permalink.