This document discusses continuous improvement at MYOB. It defines what an "awesome" way of working entails, including delivering high quality outcomes quickly, having self-organizing teams that are happy and engaged. It also discusses assessing the current processes, which include practices like refactoring, pair programming and metrics like cycle time, lead time, and customer happiness. It recommends collecting cycle time metrics to identify improvement opportunities like inconsistent story sizes, work in progress limits, and forecasting. Reducing high cycle times could involve clearer story definition and acceptance criteria.

1. Continuous
Improvement at
MYOB

2. Definition of Awesome
(aka Understand the Direction, or ‘How do we want to work?’)
❏ Delivering high quality, valuable customer outcomes quickly is embedded in the
way we work
❏ Teams are truly self-organising
❏ Teams are happy, healthy, engaged and enjoying their work
❏ Teams have a culture of experimentation, creativity and innovation
❏ Teams are aligned around a common vision and objectives, and progress towards
these is visible and transparent

3. Definition of Now
(aka Grasp the Current Condition, or ‘How do we work now?’)
❏ Refactoring
❏ Pair Programming
❏ Definition of Ready
❏ Definition of Done
❏ WIP (Work In Process)
❏ Iteration length
❏ Automated Acceptance Tests
❏ Continuous Integration
❏ Continuous Delivery
❏ Continuous Deployment
❏ Cycle Time
❏ Lead Time
❏ Number of defects
❏ Throughput
❏ Unused features
❏ Team happiness
❏ Customer happiness
Process Metrics Output Metrics
We need
this data!

4. Step 1: Collect Cycle Time Metrics
❏ How long does it take for stories to be delivered?
❏ Many improvement opportunities can be derived from cycle time data
❏ High variability (e.g. some stories take 1 day, some take 20 days)
❏ Become more consistent in the way work is defined and broken down
❏ Keep WIP consistent
❏ Leading to…
❏ Managers can use empirical data for more predictable delivery forecasting,
rather than relying on crystal ball gazing by the team
❏ Reduced stress on the team
❏ Increased transparency and trust with stakeholders
❏ High cycle time (stories typically span weeks)
❏ Create clearer story definition and/or acceptance criteria (Definition of Ready)
❏ Explicitly slice stories vertically and vigorously
❏ Define acceptance tests up front as a team to clarify user scenarios
❏ Leading to:
❏ Simpler stories, more options and lower risk
❏ Shorter feedback loops for faster learning and delivery of customer value
❏ Reduced delays such as hand-offs, story defects, other queues and
dependencies on people outside of the team
❏ Low cycle time is generally a good sign, but if it’s really low (e.g. < 1 day) we may be
measuring task cycle times and not end-to-end user scenarios

5. To Do Doing Done
= 1 elapsed day
Easy to add a dot
at daily standup,
or just update
the data daily in
a spreadsheet
Story 1 Story 2 Story 3 Story 4 Story 5
Elapsed days 2 3 1 1 2
Days
Stories
Step 1: Collect Cycle Time Metrics
We need
this data!