#Insanity Ep3: Max Out Power (DevOps Processes and Measurement)

Max out Power is insane… each exercise is 30 seconds on and 15seconds off. 30 seconds of explosive actions and 15 second recovery with a 30 second rest every 5 mins.

https://youtu.be/ZGAUq8UMUFg

Max Out Cardio and Agile

Don’t forget, yesterday you did Max Out Cardio – you muscle system is already tired and you are aching in places you didn’t know existed. You also had the best night sleep in ages and you have got out of bed, laid out your fitness mat and have pressed play… You crazy person, you!

I relate this exercise to the some of the practices of Agile. I wrote a previous set of articles under #AStoryofDevOps, specifically one about the practices of Agile called Jedi.

In Agile practices, the work is clearly defined by the Product Owner and the team are protected and allowed to focus on the work each day with minimum distractions. They are protected, facilitated and encouraged to be as productive as they can by by the Scrum Master. Each day, the team stop for 15 mins for situational awareness and to make sure they have everything they need to perform the right work that day. Every couple of weeks, the team stop, review, reflect and plan for the next sprint.

This workout is like that, Shaun T is the product owner and the exercises are defined. The people in the video are our team – we can relate to them. We work out hard for 30 secs and rest and reflect for 15 secs. After 5 mins, we stop, grab water, think about what we have just done and prepare for the next 5 mins.

There is no time to get interrupted or think about the football, work, shopping or anything else – the time in training is intense and your body and mind needs to be as efficient as possible. You are really clear of what you need to do and you have trust in Shaun and the programme and you have given just enough time to take stock, recover and repeat. Finally, you can feel and see the results every day.

"Its not until you get tired that you see how strong you really are" Shaun T

DevOpsGroup Discovery

In a previous article, I shared how the DevOpsGroup Discovery Process work and that as part of the partnership with DORA, the following capabilities are understood; People, Measurement, Technical and Culture.

Max Out Power brings into play Process and Measurement capabilities predominantly. Shaun T prepares you for the way the programme works, gets you into the routine and more importantly get you thinking about your body and your life.

Process Capabilities

The software industry has borrowed many ideas from lean manufacturing which improve the way we work. Examples include: decomposition of work (allowing for single piece flow) and streamlining change approval processes. More information on the impact of these can be found in the 2018 Accelerate State of DevOps Report

  • Visibility of customer feedback: Visibility of customer value is the degree to which feedback from customers is gathered and broadcast to teams, and then implemented in products. DORA research has found that whether organisations actively and regularly seek customer feedback and incorporate this feedback into the design of their products is predictive of IT Performance.
  • Understanding of value stream: This represents whether teams have visibility to the ow of work from the business all the way through to customers, from idea to customers, including the status of products and features. DORA research has found this has a positive impact on IT Performance.
  • Small batches: This represents the ability of the team to slice work into small pieces that can be completed in a week or less. The key is to have work decomposed into small features that allow for rapid development, rather than developing complex features on branches and releasing them infrequently. This idea can be applied at the feature and the product level (An MVP is a prototype of a product with just enough features to enable validated learning about the product & its business model.) Working in small batches enables short lead times and faster feedback loops.
  • Team experimentation: Team experimentation is the ability of developers to try out new ideas and create and update specifications during the development process – without requiring approval from outside of the team – which allows them to innovate quickly and create value. This is particularly impactful when combined with working in small batches, incorporating customer feedback, and making the ow of work visible.
  • Change approval process: Our research shows that a lightweight change approval process that is based on peer review (pair programming or intra-team code review) produces superior IT performance to using external change approval boards (CAB).

Measurement Capabilities

These include the use of metrics to make business decisions and monitoring tools.

  • Monitoring: Monitoring is the use of data from application and infrastructure monitoring tools to take action and make business decisions. Take note — this isn’t just the use of these tools to page people when things go wrong.
  • Failure notification: Failure notification is the proactive monitoring of system health based on threshold and rate-of-change warnings to enable teams to pre-emptively detect and mitigate problems.
  • WIP limits: The use of work in process (WIP) limits to manage the ow of work is well known in the lean community. When used effectively, this capability can be used to drive process improvement, increase throughput, and make constraints visible in the system.
  • Visualisation of work: Visualisation of work is the use of visual displays like dashboards or internal websites to monitor quality and work in process (WIP).

2018 State of DevOps Findings

In the Accelerate 2018 State of DevOps Report, Lean Product Management is re-enforced with the characteristics that comprise Lean Approach to Product Management:

  1. The extent to which teams slice up products and features into small batches that can be completed in less than a week and released frequently, including the use of minimum viable products (MVPs)
  2. Whether organisations actively and regularly seek customer feedback and incorporate this feedback into the design of their products
  3. Whether development teams have the authority to create and change specifications as part of the development process without requiring approval

Enabling the team to slice work up, incorporate feedback through creating and changing specifications is key to developing great products that deliver value, early and often.

This is then delivered by a cross-functional team:

“The concept of cross-functional teams is central to many Agile approaches. According to the Scrum Guide, ‘The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organising and cross-functional… Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.’ In Extreme Programming Explained: Embrace Change (Second Edition), Kent Beck and Cynthia Andres write, ‘Include on the team people with all the skills and perspectives necessary for the project to succeed.’ Indeed, we found that low performers were twice as likely to be developing and delivering software in separate, siloed teams than elite performers.” Accelerate State of DevOps Report 2018.

The below show how Lean Product Management predicates Service Delivery and Operational Performance and therefore Organisational Performance:

Practical Application

Like Max Out Power, in high performing Software Teams, you will be receiving feedback from customers (yourself), you will understand how work (workouts) are done, you will deliver work (workouts) in small batches, you will have room for experimentation (pushing harder, pacing certain exercises, working out different times of day) and there is no waiting or approval to get work approved (no gym, no travel, no membership) – get up… get it done!

You will monitor the right things (heart rate, weight, bicep, thigh, stomach measurements, etc.) and respond when you think there is an issue (stop, rest, drink), you will fail but then you will recover (Max Out, record your time, carry on), You will have WIP limits (you can only do what’s in the workout, nothing else matters) and your work is visualised (Shaun T is in your face and you can see the progress monitors on the screen).

You do the work, you focus on the work, you review and reflect, and you measure improvements.

So, where do you start? In my opinion, you need the following:

If you need help, Contact DevOpsGroup to conduct a DevOps Discovery underpinned by the DORA research and assessments and let us help you understand where you need to improve – team@devopsgroup.com

More in this series:

  • #Insanity Ep1: Insanity Max 30 (DevOps: Stability AND Throughput)
  • #Insanity Ep2: Max Out Cardio (DevOps Performance Benchmarking)
  • #Insanity Ep3: Max Out Power (DevOps Processes and Measurement)
  • #Insanity Ep4: Max Out Sweat (DevOps Technical Capabilities)
  • #Insanity Ep5: Max Out Strength (DevOps Culture)
  • #Insanity Ep6: Friday Night Fight (Scale)

Raj Fowler

I am a natural, enthusiastic and authentic leader who understands the impact of IT as a differentiator for business performance and how organisational culture directly influences IT and business performance. With a strong appreciation of the changing technology environment, I have spearheaded a transformation of organisational ‘ways of working’ through adoption of the philosophies and principles that underpin DevOps, Agile and Lean. As a result, I have a track record of delivering operational excellence whilst improving IT agility, security and responsiveness enabled through close business relationships, technology-led thinking and inspirational leadership. 3 years ago we delivered about 50 to 100 changes per annum across about 80 business systems, all of which we managed using our standard plan, build and operate practices. Change was difficult and the transition from project to service was painful. I lived the opening chapters of the Phoenix Project on a regular basis. I now manage over 100 business systems and we categorised 7 of these as Products which include ServiceNow, Salesforce, Cognos, SuccessFactors, SharePoint. SAP and Bespoke Applications where we have established Product Teams. These are teams that build and support Product using DevOps philosophies. As a result, we delivered over 2500 changes last year whilst at the same time improving the service by 30%, improving customer satisfaction and employee morale. Using the "you build it, you support it" (Amazon) mentality, change is no longer a big event but a normal everyday occurrence and the usual spikes of incidents are no longer there, in fact with each change we deploy, the incident volumes reduce! Teams are not only delivering new features but are cleaning up their code and removing technical debt with every release. As a result, we have made a significant impact to the efficiency of our internal functions which in turn helps the competitiveness and profitability of the enterprise.

Have Your Say: