#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.
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!
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
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.
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).
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:
- 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)
- Whether organisations actively and regularly seek customer feedback and incorporate this feedback into the design of their products
- 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:
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:
- The right leader, the right Product Owner
- The right work, with everyone being really clear on the work and being empowered to do it.
- The right team with the right people needed to do the four types of work
- The right tools for the job
- The right environment to do work
- The right practice and measures to do and improve work
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 – firstname.lastname@example.org
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)