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