August 20, 2019 // By John Doucette
What did I learn taking the Implementing SAFe® course and receiving my SAFe® 4 Program Consultant certification as an executive in a Consulting Company? I received an awakening.
After being in the software development business for more than three decades, I was both validated in my understanding of the Agile processes and amazed at the impact of the convergence of Lean and DevOps in Agile.
When I advise clients about their methodologies, I draw upon my experiences from the SDLC/Waterfall days, to the Agile working models of today. I use terms such as “scrum,” “XP,” “Kanban,” and sometimes the little “a” agile as I seek to understand a company’s culture supporting Agile.
When talking about frameworks like SAFe®, LeSS®, or the Spotify model, we brush them broadly and do not venture into those “more complicated approaches.” In many cases, clients are still struggling getting the business to align and collaborate on a common process and collaborate to “build working software.” Sending a product owner as a business analyst to join the team is about as far as many companies go to fully adopt Agile.
After four days of very intense curriculum and team interaction with scrum masters, and real product owners, from companies like Boeing, GE, USAA, and HP, I learned SAFe is a culmination of proven practices from all the great Agile techniques and Lean thinking already in place today.
Scaled Agile is a “framework” of existing ideas. It includes proven methodologies wrapped in a package in which teams of thousands can operate and build great software to impact positive business outcomes.
Dean Leffingwell (creator of SAFe®) has a saying; “Every business is a software business now. Agility isn’t an option, or a thing just for teams, it is a business imperative. But we struggle building big systems.”
I was fortunate to be in his course in Boulder as Leffingwell and Inbar Oren led a group of 40 students through the “Implementing SAFe®” training. It was there I realized the barrier laid at the foot of any of these frameworks was simply a cognitive bias of the unknown.
For years, Agile coaches have tried to make an impact on the industry of building software. As one client recently told me (after I took the SAFe® course), “We have tried to implement change with coaches and vendors. What makes you any different?”
As I sat there and thought about the question, I realized the essence of the problem he was having. He and his leadership team were not embracing the fundamental problem of change: that they own the change, not some proxy.
There are two compelling reasons why my client needed to change, and it was obvious which one they were tracking towards. As the “tipping point” discussion in the SAFe® framework defines, the following questions needed to be asked:
Do you have a burning platform, failing to compete and your existing way of working is inadequate to achieve a new solution in time?
Are you missing a proactive leadership team creating a sense of urgency to proactively drive change by taking a stand for a better, future state?
As our company began understanding the benefits supporting our clients using the principals of SAFe®, we began internally adopting the training program, certifications, and eventual coaching with our clients to enable them to be change agents.
We do not profess to be the vendor who will change their organization to adopt a better way of implementing Agile, but merely a catalyst for their leadership and teams to explore the benefits of the SAFe® program.
SAFe would not exist if not for the building blocks of embracing the Lean Mindset, taken from the Toyota Production Systems in Lean manufacturing. The five principals of Lean, Value, The Value Stream, Flow, Pull and Perfection, are all found in the SAFe® House of Lean in one way or the other.
SAFe® is built on the Agile Manifesto and its 12 guiding principles, such as:
- Individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
After hours of details in the course describing the foundational underpinnings of how SAFe® was conceived and enriched by the principals laid before it, a final compilation of their own principals was defined. It is in this list we find common logic and tenants anyone can follow. It follows these rules;
- Take an economic view
- Apply systems thinking
- Assume variability; preserve options
- Build incrementally with fast, integrated learning cycles
- Base milestones on objective evaluation of working systems
- Visualize and limit WIP, reduce batch sizes, and manage queue lengths
- Apply cadence, synchronize with cross-domain planning
- Unlock the intrinsic motivation of knowledge workers
- Decentralize decision-making
My awakening has been coming for a while, as we have consciously invested in SAFe® to enhance our proven practices of delivering software solutions for our clients. It was the push to get the training as a company leader, where I found you can “teach an old dog, a new trick.” We build some of the most complex and important software for clients who are trying to win in business. They cannot afford for us to “figure it out” when it comes to Agile. We help them build their solutions faster using SAFe®, which is why Magenic has embraced the framework as the foundation of our Fast Forward Process.