Here are some of the key points made in the presentation:
- In 2006, there was a decision made to stop using the concept of a ‘project’, as this fake and artificially fabricated term implied start and end of something that was meant to be continuous: product development.
- In 2007, there was a decision made to stop using Component-centric work and Release Trains – something that was mistakenly introduced by SAFe implementation
- During 2006-2008 – the number of ‘feature points’ (equivalent to deployed features) delivered each sprint was pretty low. Introduction of SAFe did not improve the situation: too much ‘undone’ component-work remained at the end of each sprint
- Between 2008 and 2009, Large Scale Scrum (LeSS) was introduced, and it led to a number of ‘feature points’ increasing steeply, every sprint
- Closer to 2009, when 150+ development teams introduced SBE (specification by example), ATTD (acceptance test-driven development) and feature toggling (engineering practices that are strongly advocated by LeSS), a number of ‘feature points’ delivered each sprint grew even higher, with many teams becoming capable of releasing to production multiple times each sprint
- Forming properly structured feature teams in NY, London, Kiev, Hyderabad and Hong Kong brought about the following benefits:
- Reduced hand-offs: “concurrent engineering”
- Clear accountability for feature delivery (by each team)
- Code base sharing, across all teams that resulted in greater quality, evidenced by very minor issues, following latest release
- Each team, focusing on one feature at a time – something that led to shared purpose and reduced task switching (ultimately leading to greater efficiency)
- Teams, having greater appreciation for customer needs
Why did everything work? Because there was an environment of Autonomy, Fearlessness and good practices of software Engineering created.
Many companies start agile adoptions by introducing a long array of “agile processes” and “best practices”, falsely assuming that they are all universal or absolute. But they are not. Every company, every department, every situation has its own context. Also, starting with “best practices” concept is wrong because hardly any of them are always “best”; rather “great” and only contextually. Instead companies should start with introducing good principles that can be over time developed into good processes and practices that will always remain contextual.
The magic formula then becomes: Process + Practices = Principles + Context
Download Gordon Weir’s Presentation
Awesome presentation. Thanks for sharing your experience and unique wisdom.
Great presentation!
Great presentation yesterday! Really enjoyed hearing about the journey and experiences in regards to what worked, what did not, and especially the commitment to building feature teams.
Thank you Gordon for sharing your insights from his experiences. They are very useful and the way you presented and communicated was very interesting.
The LeSS War Stories Meet-up with Gordon Weir checked all the boxes for a productive, engaging and well-planned session. Gordon is an amazing and inspiring story-teller skilled at articulating the journey to and with LeSS. He seamlessly connects thought frameworks, approaches and technical requirements with in-real-life challenges and solutions in a relatable, smart, energetic and humorous narrative. Another key element of this session was the in-person attendance of the hosting firm’s recruiting team and their approachability. Speaking with the recruiters provided insights to practitioners and aspiring coaches on mind-sets that are valuable to organizations looking at LeSS and Agile. The final aspect of the productive session was a well-attended and engaged audience that extended the learnings with questions for Gordon, recruiters and peers. Looking forward to the next talk with Gordon and other War Stories sessions!