Journey to becoming SAFe.

Ghada Ashkar, Programme Manager in Washington, D.C.
14 July 2020

SAFe (Scaled Agile Framework) is what’s going to save our project, you’re telling me? “This must be another fad that everyone is trying to convince software development organizations that they need to adopt in order to deliver faster, better, shinier, more user-friendly software to users” were my initial thoughts when I was first signed up to take SAFe training. By that time, I had obtained all kinds of certifications that pertain to program, project, and agile management. You name it: Project Management Professional (PMP), PMI-Agile Certified Professional (ACP), Certified Scrum Master (CSM), DevOps Foundation Certification, Certified Agile Leadership (Cal 1), and the list goes on. And now, I get to add another certification to my collection and check the box!

While I did have my initial reservations about yet another training, I went into the course with an open mind, hoping to learn and grow, and find bits and pieces that I could take back to my team to help deliver value in a more efficient manner. The training was intense, the level of detail that the Scaled Agile Framework website provides felt overwhelming, but I was impressed by the concept and the depth of the framework. At first glance, it felt like they had taken Agile/Scrum principles and applied them at the development team level, tied them with DevOps practices to bridge the gap between delivery and operations teams to improve the collaboration and speed to market; and introduced another layer of Portfolio/Enterprise level to incorporate the business side of larger organizations.

The foundation is brilliant, but my head was hurting. How are we going to get all these people to talk to one another, when we, at the team level, can hardly agree with the Product Owner on the priority of the backlog, let alone at times, agree on who is the Product Owner? Is it the government agent, the PMO contractor, or the development contractor? We were running a Wagile (Waterfall/Agile) project at that time – one where we were honoring all the agile ceremonies and holding them religiously, but still delivering software, testing, deploying in a very waterfall-ish way. We were DOING Agile but we were not BEING Agile.

Having lived and breathed SAFe for the past several years, I have experienced the power and impact it brings to organizations when they believe in its foundation and invest the time and effort to truly embrace its adoption.

Seven Core Competencies of SAFe

Organizations in today’s world are aspiring to become a lean enterprise, one that is able to thrive on digital disruption, be responsive to change and deliver value to customers at the speed that they demand. In addition to Lean, Agile and DevOps principles and practices, SAFe provides the operating system for organizations to achieve the business agility through seven core competencies of Lean Enterprise*:

  • Lean Agile Leadership: Leading the change, empowering the team within the organization to embrace new ways of working

  • Team and Technical Agility: High-performing, cross-functional agile teams focusing on business and technical solutions that bring quality to consumers

  • Agile Product Delivery: Keeping the customer in the center of your product strategy, developing on cadence and delivering on-demand by adopting DevOps practices and continuous delivery pipelines

  • Enterprise Solution Delivery: Applying Lean system engineering to build and maintain big system across multiple disciplines

  • Lean Portfolio Management: Organizing and reorganizing around value where strategy, funding, and execution are carried out with lean governance to empower decentralized decision-making

  • Organizational Agility: Cultivating 'Lean-thinking' people and agile teams that can respond quickly to opportunities and threats

  • Continuous Learning Culture: Becoming a learning organization that grows together by continuously improving solutions, services, and processes

* If you’re interested to learn more about the core competencies, refer to SAFe for Lean Enterprises 5.0

Having covered the basics of core competencies, let me take you through some pain points that large enterprises experience and how SAFe can offer a solution.

Where does the drama lie?

Large enterprises and government agencies tend to move slower when it comes to modernizing their platforms or updating their digital footprint to meet the growing consumer adoption of technology. Factors contributing to that slower reaction might be high levels of bureaucracy, silos within the business, fear of change, and old technology stacks that are difficult and time-consuming to modernize.

Many large organizations have long recognized that waterfall development and outdated technology stacks were not getting them the quick turnaround results to deliver better software to their customers. However, even after adopting Lean, Agile and DevOps practices, they were still not able to deliver as fast as they were hoping to. The drama was no longer at the development/testing stages (Agile took care of that), nor was it at the technical stages (DevOps addressed that). It became apparent that the hierarchical structure of the large organization along with the silos among departments caused a lot of work/projects to linger in the ‘waiting mode’ until the next team/department/contractor could move it along the process.

Waiting Mode

When you have 40+ team members working on a project, a lot of time is spent waiting for the next step in the process and therefore delaying the delivery of value to clients. By waiting, one needs to look at the full picture, not just the time it took the development team to complete the work after they committed to it on their sprint board. Work in the 'waiting mode' goes back to how long the idea took from the time the marketing team presented it to leadership, the finance team to approve budgeting it, the delivery team to secure the resources to work on it, the product and design team to define it and prioritize its features in the backlog, the sprint team to build, test and deploy it, and eventually, if all goes well, the consumer can start using it.

For companies following Waterfall practices, the work could wait 80 - 90% of the time. When doing Scrum, the waiting time does improve. If you have one sprint team, the work typically waits 20-30% of the time. But when you have multiple sprint teams that might be building features with cross-team dependencies, then the waiting time goes back up to around 50-60%. With SAFe, we were able to run large projects with multiple sprint teams (40 to 100+ members) at scale and reduce the length of time when work is sitting in the 'waiting mode'.

The journey continues

Reflecting on the projects I worked on where we chose the adoption of SAFe, the teams have had a lot of highlights and bumps along the way, but the main goal for us was to continue to grow incrementally. When we started out on our first Planning Increment (PI) Session, where we planned out the objectives to be completed in the next 10 - 12 weeks, we only focused on bringing in the development teams and the product owners. But it soon became apparent that we needed input from legal, security, DevOps, and marketing teams to make our planning more efficient. So, on our second and third PI sessions, we expanded the invite to include the other departments for which our work was dependent on their progress, or initiatives.

Having been part of SAFe teams for the past three years, and helped run and manage 12+ program increments, I have seen how the communication channels across all the departments and agencies have improved, and with it – the team productivity and commitment to focus on the value-added to the consumer benefited as well. The most empowering part of it all, in my opinion, is that everyone involved in the planning is given the opportunity to raise concerns, risk, and highlight dependencies that might cause a roadmap to be delayed. The sprint teams have a great contribution to weighing in if the objectives presented by management are feasible and can vote on their confidence level of getting these objectives completed in the designated time frame. The ultimate sign-off of the plan is coming from the team through the confidence vote, and once you get a commitment from the team, chances are plans have a higher level of staying on track. Key to achieving this is to build a level of trust and safety where the team members can speak openly with management knowing that they will be heard.

When I look back at our performance since the adoption of SAFe, we started out by completing 40 - 45% of the objectives we had committed to. But as we inspect and adapt to get better with our planning across agencies and departments, backlog grooming, estimating, identifying dependencies, mitigating risks and, most of all, empowering our team members to raise concerns during the confidence vote, we are running at 60-65% completion rate of our committed scope. As we continue to guide our business owners to focus on the top objectives they are looking to achieve, and help our sprint teams get more empowered to raise their concerns when a plan is too optimistic, we look to bridge the gap between committed vs. completed scope. Our stretch objective towards the end of 2020 is to reach 75-80% execution of committed scope. This is a very realistic target since we know that business priorities do change, and it allows us to be agile enough to adapt accordingly as we continue our journey of being a lean, agile, and most of all SAFe project.