Getting to Better Problems (AgileShift conference)
0 likes178 views
Tim Haagenson and Allison Pollard, experienced in agile methodologies, are leading transformation initiatives aimed at improving software development processes at American Airlines. They focus on enhancing continuous integration, reducing testing cycles, and overcoming challenges tied to a deeply coupled monolithic code base. Their approach includes the use of the Improvement Kata model, emphasizing automated deployments and ownership of testing by product teams.
Getting to Better Problems (AgileShift conference)
- 1. Getting to Better Problems An Approach to Continuous Improvement
- 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
- 5. Transformation Roadmap Challenges Photo by Muhammad Haikal Sjukri on Unsplash
- 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
- 11. Grasp The Current Condition
- 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
- 13. Next Target Condition Two deployments per week No one has to work extra hours to make it happen
- 14. 18By Mike Rother THE IMPROVEMENT KATA MODEL Conduct Experiments to get there Deploy Weekly Two Deployments Per Week Deploy When Ready 1 2 3 4
- 15. We Had Many Obstacles
- 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.
- 17. Progress
- 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
- 19. Looking Back: Transformation Roadmap vs. Improvement Kata Photo by Bud Helisson on Unsplash
- 20. Contact Us Tim Haagenson Timothy.Haagenson@gmail.com @thaagenson Allison Pollard Allison.Pollard@improving.com @allison_pollard www.allisonpollard.com
Editor's Notes
- #8: 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”
- #9: 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
- #10: Engaged Part of the solution Autonomy, mastery, purpose Different outcome Work emerges Always progressing / seeing value
- #12: 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
- #13: Talk about how the Challenge is long term thinking and borders on the absurd.
- #14: A challenge so bold that people laugh when they hear it
- #16: Value stream mapping
- #24: How do they compare? Personal Transformation along the way “embarrassed by the big ideas I had 3 years ago” type exposure