A Conversation with Ian J. Franks
Ian J. Franks shares his insights on the importance of SAFe and why SAFe skills are essential. He discusses how a SAFe transformation might fail and offers solutions, so that we can avoid similar pitfalls. Ian also shares 4 golden pearls of wisdom garnered from his experiences and 39-year career.
Thought Leadership News: What is SAFe 5.1, and why is it important?
Ian J. Franks: To quote Scaled Agile Inc., SAFe 5.1 is a knowledge base of proven, integrated practices and principles for achieving Business Agility, but what does that really mean, and why do I care?
Well, adopting the Scaled Agile Framework provides you with a basic model of roles, responsibilities, artifacts, and ceremonies that have been established to embrace Lean-Agile principles and relentlessly improve based on more than a decade’s experience of implementations and the latest research. When an organization fully embraces SAFe, they get such a jump start towards Business Agility that they can then build on and evolve based on their operating environment, market, and experience. Business Agility is the term we use to describe an organization that has adopted a mindset, behaviors, and practices that enable them to respond quickly to the changing needs of our fast-moving digital world. An organization that is moving towards increased Business Agility will not only be delivering Value in the shortest sustainable lead time but will be moving from funding projects to products and organizing around Value by adopting a dual-operating model. The organization will be frequently inspecting and adapting at all levels to improve both their solutions and their processes. This new mindset provides the ability to pivot the organization to seize new opportunities or respond to new challenges. It’s a little like Darwin’s ‘survival of the fittest’— those who can adapt fastest will not only survive but will thrive in a digital world.
Thought Leadership News: How essential are SAFe ‘skills’, and why?
Ian J. Franks: The seven core competencies of SAFe describe the behaviors and practices needed to develop an organization’s Business Agility; but developing these core competencies requires at least some key individuals in the organization to fully understand their roles and responsibilities, and preferably, everyone to already be trained in their roles and responsibilities.
For example, to move at speed whilst maintaining alignment and quality requires decentralized decision-making. This, in turn, requires that the relevant information needed to make those decisions is provided consistently across the whole Agile Release Train. This makes Product Management responsible to develop, maintain and communicate their Vision, Roadmap and Priorities; System Architecture to clearly communicate the needs and priorities of the Architectural Runway and Guardrails; and the Teams require support from their management and must feel empowered to make these decisions.
For many organizations and individuals within these organizations, Agile and Agile at Scale are new ways of thinking, and the ideas are often alien to some people who have spent much of their career in a project-based, waterfall-type environment that focuses on resource utilization rather than being more customer-centric and looking at the Value delivered by a Team. To adopt a new way of working, embrace a new mindset, and not revert to the former ways of thinking— requires clarity of roles, responsibilities, practices and processes which will develop the new skills required across the organization.
As I said before, ideally everyone should be trained, but the very minimum critical success factor in the launch of the first ART (Agile Release Train) is to have a good RTE (Release Train Engineer). At the very minimum, you need an RTE who is preferably experienced, but definitely certified in SAFe. They need to be an organized individual, who understands the Framework, pays attention to detail and can coach others in their roles and responsibilities as a thousand small course corrections will be required to help everyone develop a new mindset and set of skills.
Thought Leadership News: What is a common mistake when implementing SAFe, and how can we avoid it?
Ian J. Franks: The biggest danger and a common mistake is to think of SAFe as something you implement over a period of a few months and then you’re done!
The Scaled Agile Framework is just the start of the journey to change the way your organization thinks and operates. Adopting Agile is really a culture change that will lead to increasing Business Agility, so whilst you may begin with SAFe, once you have understood the basics and got the principles embedded in your psyche, then you really embark on your relentless improvement journey to develop your processes across the whole organization.
It is key that the Leadership and/or sponsors of a SAFe Transformation (as that is what it is) understand that whilst they may begin with the implementation of a single Agile Release Train, they can only realize the real benefits when they begin to look at the environment in which the ART operates and start to move Agile thinking beyond the realms of the traditional (software) development organization.
Leaders who understand that this is a culture change will recognize the need to hire or develop their own coaches and advocates to support and sustain the organization on its journey. Development of a Lean-Agile Centre of Excellence (LACE) or similar to support the initial ART’s journey, launch further ARTs, move in to Lean Portfolio Management and coach the wider organization— is an excellent way to avoid the trap of very frustrated personnel who are sold a dream of a new way of working, only to find it is treated more like the current pet project and no actions are taken to sustain what has been started.
My metaphor is to think of adopting an Agile way of working in your organization as like dropping a pebble in a pond. The ripples begin to spread outwards in all directions, and if they hit a rock, they bounce back causing ripples to collide. Leadership needs to recognize the Agile pebble they dropped and remove the rocks that prevent the ripples from spreading far and wide.
Thought Leadership News: What’s an example of why a SAFe transformation might fail, how can we avoid making the same mistakes, and how can we overcome challenges?
Ian J. Franks: One of SAFe’s seven core competencies is Lean Agile Leadership. This appears at the bottom of the SAFe Big Picture quite deliberately as we clearly want to convey that LAL appears in all configurations of SAFe and underpins everything we do. It is critical that Leadership both understand what it means to be Agile and lead the change.
In my experience, one of the most likely reasons a SAFe Transformation begins to falter is a lack of understanding amongst Leadership regarding what it means to become an Agile organization. An example of this is thinking that creating an Agile Team of 5 to 11 people and calling one person a Scrum Master and another a Product Owner is sufficient to deliver amazing results. Another example of a lack of understanding is thinking that adopting Agile means only the developers will work differently, rather than this being a Business Transformation that will lead to a change in culture.
Agile and Scaled Agile require frequent retrospection and action to improve not only our products and solutions, but the way we work. Leadership needs to recognize the change in their role to become true Servant-Leaders who exist to support the people and the Value Delivery Network (aka ART) to be as efficient and effective as possible. The Team of Teams will be identifying and raising issues that are often systemic in nature and will require senior people to resolve through investment or personal action. It is important that this is understood from the outset with Leadership, and the obvious way to begin this process is by going through the Leading SAFe Training before the Value Streams are identified and the first ART created. I believe it is important to engage or hire a SAFe Program Consultant who can coach the Leadership to ‘Lead the Change’.
Thought Leadership News: If you could share 3 important pieces of advice for both business students and professionals, what would they be?
Ian J. Franks: This is an interesting one for me. I think this is harder than the other questions, not because I don’t have any advice, but because it’s difficult to succinctly summarize three things from all I’ve learnt in my 39-year career so far! I think I’ll offer these.
- Understand the Principles of ‘Flow’. It is key that in a product development or manufacturing scenario, you understand some key principles that allow work to flow through your System so more Value is delivered sooner. I recommend reading, ‘The Principles of Product Development Flow’, by Donald G. Reinertsen, and you’ll see that many of these principles translate directly into SAFe Principles. I always tell Teams I work with that if they can master SAFe Principle #6 to Limit WIP, Reduce Batch Sizes and Manage Queue Lengths, they will be well on their way to increasing the Value they deliver and to develop Agility by finishing what they committed to in an Iteration.
- Be realistic in your planning! Every organization I’ve ever worked for or worked with has been capacity constrained in some way, i.e., they have more work than they have people and resources to deliver (and that’s a good thing because if you have more capacity than work, you’re in trouble!). However, what most of those organizations had in common was they simply ignored this fact or were unable to visualize the amount of capacity versus load. Find ways to visualize your workload and available capacity, make those responsible for prioritization to recognize the challenges and call out the priorities, don’t allow your organization to abdicate responsibility by leaving it to those doing the work to make priority calls. Using Agile, we bring the work to the people, we plan in small increments, and we’re able to visualize our capacity and load to make priority decisions.
- Create an environment that motivates your people. Many of the things I’ve been taught historically about how to motivate teams and individuals were predicated on an understanding or a time when labor was more manual. In our newer, more digital world where many of us are ‘Knowledge Workers’, these old lessons don’t apply. Command and Control type thinking doesn’t align with a fast-moving, decentralized, decision-making model, and treating software development like a repeatable widget production line with the same rewards (or punishments!) will not see you out-perform your opposition. I recommend you read, ‘Drive – The Surprising Truth About What Motivates Us’, by Daniel H. Pink, and I’m sure you’ll recognize the elements of Autonomy, Mastery & Purpose that were probably present in some of the best roles you’ve ever had and understand the importance of fostering the same in your Teams and organizations.
- And if I can throw in a fourth piece of advice. Keep an open mind and keep learning. Everything I’ve said in this interview and the ways I’ve solved problems and found solutions are all things I’ve learnt in the last decade. Whilst many things Agile were like a Eureka moment for me, and they were all things I wish I’d discovered sooner; I’m also open to what’s coming next as I know relentless improvement is a human trait!
Ian J. Franks
ICP-ACC, SPC, CSP-SM/PO, AHF
Consultant and Trainer, International Institute for Learning
Ian J. Franks is an experienced Scrum Master and Release Train Engineer who used his knowledge and experience to become an independent Agile Coach, Consultant and Trainer in 2019. As a SAFe Program Consultant and certified Agile Coach, Ian specialises in Scaled Agile Framework Transformations and Training, but as he’s also a LeSS Practitioner and a Certified Scrum Professional with the Scrum Alliance, holding both CSP-SM and CSP-PO designations, he has provided both Agile, Scrum & SAFe Consulting, Coaching and Training services to Automotive, Banking, Communications, Electronics, Fashion, Fintech and Pharmaceutical companies. Ian often works with us here at IIL.
Ian can be contacted via LinkedIn.com/ianjfranks or through amplifyresultsconsulting.com.
Disclaimer: The ideas, views, and opinions expressed in this interview are those of the interviewee and do not necessarily reflect the views of International Institute for Learning or any entities they represent.