Working towards Sustainable Pace in Scrum, SAFe and Kanban

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

Aiming towards Sustainable Pace

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” – The Agile Manifesto Principle

“programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime.” – Extreme Programming

An unsustainable pace is unhealthy. It contributes to burnout, quality issues, and unpredictable results.

If you are an agile leader – do you know whether your teams are currently operating at a sustainable pace? Do you care? Would you rather not know because you’re afraid of the answer?

Measuring Sustainable Pace

Beyond having a general idea of the sustainability of pace, perhaps it would help to have a concrete KPI related to it?

If we use the language of OKRs, maybe something along these lines:

Objective Achieve a healthy sustainable pace

KR1 – People working reasonable hours AMB (as measured by) hours per week

KR2 – People happy about their pace AMB continuous survey 

KR3 – Plans don’t assume unsustainable pace AMB ability to achieve forecasts without resorting to unsustainable pace measures

Forecasting towards Sustainable Pace by inspecting sustainability of past pace

The last KR relates to the planning/forecasting approaches we use in agile. Agile approaches leverage empirical planning approaches. They look at the past (Yesterday’s weather) to try and forecast the future. Whether it is PI Planning, Sprint/Iteration planning. Whether by looking at Velocity, Throughput, or Cycle/Flow Times – most approaches tend to ignore how these past results were achieved when using them to predict future capacity.

For example, if our velocity in previous Sprints was 15-20 points, we will probably take on about 15-20 points. But what if these 15-20 points required a herculean effort that wasn’t sustainable?

Similarly – if we just concluded a PI in which the ART achieved a Program Predictability Score of 85% we will be tempted to assume we have a pretty serviceable approach to planning/forecasting. But what if this required killing it through nights and weekends and skipping any sort of Innovation in the IP iteration? Where does this come into the calculation?

If our cycle/flow times are 7-10 days 85% of the time we will be tempted to set that as an SLE (Service Level Expectation) to ourselves. But does that make sense if this was achieved while working 60 hour weeks?

Planning/Forecasting using a Sustainability Factor

What I’m advising teams/organizations I’m working with is to consider the “sustainability factor” when considering any past results for the purpose of forecasting the future and adjusting accordingly. This isn’t trivial. It requires making sustainable pace an explicit “citizen” of the measurement dashboard and conversation.

We have learned that speed and quality are related. We now understand that inappropriate speed might be at the expense of quality, so we look at a balanced scorecard of speed and quality. Moving forward, we need to add pace sustainability to this scorecard and to the conversation around how much work does it make sense to forecast.

A metric I’ve been toying with is Weighted Predictability/Sustainability:

Predictability(Un)SustainabilityWeighted
80%150%53%
80%100%80%
60%100%60%
100%150%67%

As you can see here, achieving reasonable predictability scores is weighted down by the unsustainable pace required to achieve them. so a score of 80% is actually weighted down to 53%. This 53% is what should be used for future planning purposes. For example in SAFe I&A and PIP.

Moving Forward – Treating Pace Sustainability as a first-class citizen

First, we need to come up with a good name for this metric / KPI. Flow Sustainability? Pace Sustainability? Work Sustainability? Burnout Risk?
Are you explicitly measuring anything related to Sustainable Pace? Do you have goals around it? Do you take it into consideration when planning? Please share in the comments!

Categories:

Tags:

Systems Thinking
Jira
Agile Release Planning
Kanban
Value Streams
Agile Community
ATDD
Lean Software Development
Kanban Basics
SPC
Pomodoro Technique
Acceptance Test-Driven Development
QA
Built-In Quality
Lean-Agile Software Development
Agile Assembly Architecture
Risk-aware Product Development
Lean Agile
Agile Release Management
Managing Risk on Agile Projects
TDD
Test Driven Development
Professional Scrum Master
ScrumMaster Tales
Continuous Deployment
Continuous Integration
An Appreciative Retrospective
Scrum With Kanban
LeSS
Presentation
Agile Games and Exercises
System Team
AI Artificial Intelligence
Nexus vs SAFe
Covid19
Agile Marketing
Program Increment
Games and Exercises
Scrum Master Role
Introduction to Test Driven Development
Agile Contracts Best Practices
ARTs
System Archetypes
Sprint Retrospectives
Agile India
RSA
BDD
Operational Value Stream
GanttBan
Portfolio for Jira
Principles of Lean-Agile Leadership
Managing Projects
Lean Agile Organization
System Integration Environments
Jira Plans
Agile Delivery
Elastic Leadership
WIP
Kaizen
Development Value Streams
Frameworks
Kanban Kickstart Example
Agile Product Ownership
Quality Assurance
Agile Development
Certified SAFe
Daily Scrum
Lean and Agile Techniques
Engineering Practices
SAFe Release Planning
NIT
Kanban Game
Story Slicing
PI Planning
ALM Tools
Release Train Engineer
ATDD vs. BDD
Agile Games
Planning
Agile Techniques
Lean-Agile Budgeting
Scaled Agile Framework
Tips
Legacy Enterprise
DevOps
Sprint Planning
Advanced Roadmaps
Professional Scrum with Kanban
Releases Using Lean
Lean Startup
ROI
Implementation of Lean and Agile
SAFe
Kaizen Workshop
Achieve Business Agility
Change Management
Artificial Intelligence
Software Development Estimation
lean agile change management
Process Improvement
Business Agility
Enterprise DevOps
Atlaassian
speed @ scale
Scrum and XP
Agile in the Enterprise
Entrepreneurial Operating System®
Webinar
Agile Program
What Is Kanban
Lean Agile Management
Kanban 101
Agile Risk Management
IT Operations
A Kanban System for Software Engineering
Legacy Code
LAB
Jira Cloud
The Agile Coach
Applying Agile Methodology
Perfection Game
Rapid RTC
Large Scale Scrum
Nexus Integration Team
Amdocs
RTE Role
SAFe DevOps
Nexus
Product Ownership
Nexus and SAFe
Agile Outsourcing
Agile Product Development
Reading List
ART Success
The Kanban Method
PI Objectives
Scrum.org
AgileSparks
Effective Agile Retrospectives
Scrum Guide
Risk Management on Agile Projects
Lean and Agile Principles and Practices
Lean Risk Management
Spotify
Scrum
Scrum Values
Agile Project
Hybrid Work
Introduction to ATDD
Agile Project Management
Manage Budget Creation
Continuous Improvement
Continuous Delivery
speed at scale
Code
Lean Agile Leadership
Agile for Embedded Systems
Agile
Lean Budgeting
Professional Scrum Product Owner
Iterative Incremental Development
Nexus and Kanban
Agile Testing Practices
Limiting Work in Progress
Accelerate Value Delivery At Scale
Slides
POPM
Agile Israel Events
Agile Mindset
Scrum Primer
Continuous Planning
Agile and DevOps Journey
Coaching Agile Teams
EOS®
Agile Exercises
Scrum Master
Agile Basics
Agility
Risk Management in Kanban
Product Management
Video
Self-organization
Sprint Iteration
Software Development
AgileSparks
Logo
Enable registration in settings - general

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

academy@agilesparks.com

WELCOME

to our new website

WELCOME

to our new website

This website uses Cookies to provide a better experience
Shopping cart