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!

Subscribe for Email Updates:

Categories:

Tags:

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

Contact Us

Request for additional information and prices

AgileSparks Newsletter

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

This website uses Cookies to provide a better experience
Shopping cart