LeSS Adoption Preparation References




 

LeSS Talks: May 22: Darwin Theory of Agile Coaching Evolution, with Ron Whitebread



Learn how one company iterated on their coaching approach – from experimentation to big consulting “transformation” to systems thinking enablement (transitioning from being supported by one of Big 5 consultancy companies, with their “push agile” model,  to a reputable, boutique agile coaching and training company) – to become more effective in achieving desired outcomes, what pain points each approach was trying to address, and how to become more relevant to the business side of Agility.

Understand how three different ecosystems played into how our focus and approach kept evolving to fit the prevailing context of that period – the environment, goals, pros/cons and reflection on those outcomes for each approach used.

Ask About LeSS Training & Coaching

04/11 – LeSS Talks: Branching Strategy and CI/CD in Agile Development, with Thierry de Pauw




Materials | Speaker’s Site

Main Take-away Points:
  • “Developing in isolation can help an individual go faster but it does not help a team go faster. Merge time and rework cannot be estimated and will vary wildly, and the team can only go as fast as the slowest merge.” – Steve Smith
  • “A spike solution is a very simple program to explore potential solutions. Build the spike to only address the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away.” – Don Wells
  • “The objective is to eliminate unfit release candidates as early in the process as we can …You are effectively prevented from releasing into production builds that are not thoroughly tested and found to be fit for their intended purpose.” – Jez Humble and Dave Farley
  • “Feature Branching is a poor man’s modular architecture, instead of building systems with the ability to easy swap in and out features at runtime/deploy-time they couple themselves to the source control providing this mechanism through manual merging.” – Dan Bodart
  • “Feature Branching hinders integration of features.”
    “Feature Branching hides work for the rest of the team. Frequently merging back to mainline = communicating with your team”
  • “Feature Branching works against refactoring.”
  • “Feature Branching creates inventory.”
  • “Feature Branching increases risk.”
  • “Feature Branching creates cognitive overload.”
  • “Continuous Integration Your application is always in a releasable state on main line – with Trunk Based Development”
  • “Continuous Integration Your application is always in a releasable state on main line.”
  • “Break large changes into a set of small incremental changes”
  • “Use Branch by Abstraction when performing large refactoring.”
    “Feature Toggles to decouple feature release from code deployment.”
  • “Trunk-based development requires a big mindset shift. Engineers thought trunk-based development would never work, but once they started, they could not imagine ever going back.” – Gary Gruver

Additional Learning Assets: