Ever feel discouraged by the impediments, setbacks, and struggles that come from leading change? If you created a backlog to address each challenge, would it seem a mile long? Allison and Jason share the improvement kata model so you can lead groups in focusing on the next problem to solve and owning change for themselves.
Continuous improvement is a journey rather than a destination. Come hear examples of how an improvement kata approach has enabled change at the team and organizational levels through small actions. Learn how you can apply katas in your organization.
2. Tim Haagenson
Tim Haagenson has over 10 years of
experience in software development and
dedicated his career to agile ways of
working.
As a developer and technical lead, he has
played a part in transforming development
teams at multiple companies, resulting in
their ability to deploy value daily.
Tim continues to learn a tremendous
amount about lean product delivery, and he
enjoys sharing his experience with others.
Tim is currently a technical coach helping to
lead delivery transformation initiatives for
American Airlines.
3. Allison Pollard
Allison Pollard helps organizations create
Agility by building trust between business &
IT, leaders & teams, and within teams.
As Technical Director for Improving, she is
a curator of agile frameworks and change
methods who coaches leaders and teams
to improve work relationships and enable
better delivery.
Allison is also a Certified Professional Co-
Active Coach, a foodie, and proud glasses
wearer.
4. What are we transforming?
Full stack developers
QA performed by
developers
Design Thinking to focus
on customer outcomes
Requirements as testable
hypotheses
Technical Squad Leads
lead the team
Test Driven Development
Pair programming
Organize teams by product
instead of project
Continuous integration
and delivery
Product team manages new
development and operational support
Standardized tools
pipeline
Cloud Native Architecture
Modernize technologies
New SRE/DevOps
automation role on team
6. Photo by Lindsay Henwood on Unsplash
Towards
Continuous
Improvement
7. Our Problem – Release More Frequently
1. Massive problem to solve
2. Deeply coupled monolithic code base
3. Long manual testing cycles
4. Multiple approval stages
5. Dozens of teams contributing
6. Years of investment attempting to reach the goal
7. Perpetually “two years” away from solving it
8. 12
THE IMPROVEMENT KATA MODEL
Kata1 (方) – Suffix Meaning "Way of Doing"
Conduct
Experiments
to get there
Grasp the
Current
Condition
Establish
your Next
Target
Condition
Get the
Direction or
Challenge
1
2
3
4
The Improvement Kata model comes from research into
how Toyota manages people, which is summarized in the
book “Toyota Kata” by Mike Rother
9. Our Challenge
When a developer submits a pull
request their code is in production
within 1 hour and every step of the
deployment process is automated
10. 14By Mike Rother
THE IMPROVEMENT KATA MODEL
Conduct
Experiments
to get there
Grasp the
Current
Condition
Establish
your Next
Target
Condition
Deploy
When
Ready
1
2
3
4
12. 16By Mike Rother
THE IMPROVEMENT KATA MODEL
Conduct
Experiments
to get there
Deploy
Weekly
Establish
your Next
Target
Condition
Deploy
When
Ready
1
2
3
4
16. Experiments
1. Centralized change approvals from 3 systems to reduce waste
2. Trained teams to add release notes to change requests
3. Shift Left on Testing – Product teams own more of the testing
4. Remove one staging environment
5. Train performance testing team to build their own environments
6. Remove one signoff requirement that is a bottleneck
First target condition reached with process changes
only.
No new code was required.
18. Other Examples
Development team
wants automated tests
to complete in under 10
minutes
Leadership wants to
connect with their
people more effectively
Product teams want
easier access to data
How do they compare?
Transformation Roadmap example
Do all the things
Changing the plan is expensive
What’s the goal / desire? Why?
Transformation_Strategy_final for roadmap items bereft of “Why”
Looks and feels to come into a roadmap team
“doing the job”
Leaders are out by the end
Roles going in shape the outcome
Churning on prioritization / where to focus / struggle to get traction and see progress
Engaged
Part of the solution
Autonomy, mastery, purpose
Different outcome
Work emerges
Always progressing / seeing value
Set the stage, why is this important? Many teams integrating, charging into the brick wall of QA and IQA, 3 weeks long, pulling code back derails the train…
Automation takes too long, ownership of it doesn’t belong in team
Moving to product teams, minimizing dependencies, but still a monolith
Talk about how the Challenge is long term thinking and borders on the absurd.
A challenge so bold that people laugh when they hear it
Value stream mapping
How do they compare?
Personal Transformation along the way
“embarrassed by the big ideas I had 3 years ago” type exposure