- AI-Native Training
- SAFe Training
- Choose a Course
- Public Training Schedule
- AI-Native SAFe
- SAFe Certifications
- Leading SAFe
- Implementing SAFe
- SAFe Scrum Master
- SAFe Product Owner/Product Manager
- SAFe Lean Portfolio Management
- SAFe Release Train Engineer
- SAFe for Architects
- Advanced SAFe Practice Consultant
- SAFe Advanced Scrum Master
- SAFe for Teams
- SAFe DevOps
- SAFe Agile Software Engineering
- Agile Product Management
- SAFe for Hardware
- SAFe for Hardware Teams
- Leading SAFe for Government
- SAFe Micro-credentials
- Agile HR Training
A Perspective on the Scaled Agile Framework
I have watched with interest and disappointment over the past month or so as Agile thought leaders have taken to publicly passing judgment on the new kid on the block, the Scaled Agile Framework, aka SAFe. In the interests of full disclosure, I am a certified SAFe Practice Consultant. I use SAFe with my team, and our approach to implementing SAFe is featured in the case study section of the Scaled Agile website.
Over two and a half years ago, I went on two days of Agile Fundamentals training. The intent of the class was to introduce Agile and to provide us with a toolkit we could use to apply Agile in our workplace. I remember talking about aspects of Scrum, XP, Kanban and other methodologies. We discussed various agile values, principles, and practises, and participated in several learning activities. After the two days in the classroom and a heap of new ideas to think about, the message I walked away with was - "Agile is a term for a range of methodologies that have in common the principles embodied in the Agile Manifesto. We should embrace the full range of tools available to us and choose which to apply in any given context."
Following the training, we commenced our first agile "pilot" project. The transparency introduced by agile quickly led to all new projects using agile. It was only a matter of months before we had 6 agile teams across 4 projects, working in parallel with a large outsourced offshore team on a single codebase. As if this were not already a recipe for disaster, we also had no clues as to how to effectively coordinate the teams and the work. Agile Fundamentals had not prepared us for this at all!
Following a recommendation from some agile coaches, I spent my Christmas break reading Scaling Software Agility. I was intrigued by the Agile Release Train concept, and it was not long before I was plotting with my team how we might implement one.
While we did leverage many of the ideas from Dean's book, Agile Software Requirements, we did not, by any stretch of the imagination, implement SAFe "by the book". The message I gave my team was "Dean's book contains a lot of great ideas, but Dean does not work in Data Warehousing, and he does not work in this organisation. We need to look at the concepts and principles and work out which of these are applicable to our situation". And that is exactly what we did. Among other concepts, SAFe gave us cadence, a single program backlog, a system team, and a way to be agile within a largely waterfall organisation.
Today we still leverage SAFe; it is a significant component of our Agile toolkit, but it is by no means our only source of inspiration. When I reflect on our world, Dean's words come to mind, "we stand on the shoulders of giants". We use Scrum, XP, Kanban and Lean (in the ways recommended by SAFe); however, we have also been heavily influenced by others, including: Jean Tabaka's Collaboration Explained, Henrik Kniberg's Lean from the Trenches, Scaling Agile at Spotify, Toyota Kata and Ken Collier's Agile Analytics.
My philosophy, when it comes to the various schools of thought, methodologies and frameworks in the Agile domain, is possibly best articulated by Bruce Lee: "Adapt what is useful, reject what is useless, and add what is specifically your own."
For a more extensive list of books that have inspired me and my team, check out our bookshelf.
For a more extensive list of books that have inspired me and my team, check out our bookshelf.
