In the Town Hall, the CEO of XYZ company announced that they were going to focus on accelerating their journey towards digital transformation, and everybody in the organization should buckle up for a speedy ride. The message was loud and clear, heard by thousands of employees. The executives had shown their intent, and it was for the various other layers of the pyramid to align and deliver. The legacy applications with bespoke customizations were to be replaced with the next-generation COTS applications, the data centers and servers were to be moved to the cloud, end-to-end automation of processes was to be implemented, DevOps was to be adopted, and AI and analytics were to be applied for real-time data-driven decision-making. Fast forward to one year, XYZ company had tens of incomplete projects delayed by months. Does this story from a large transformation program seem familiar? Well, if not entirely, then the only variation might be the amount of uncertainty and incompleteness. What goes wrong with the XYZs of the world?
When any company begins its journey, the entrepreneurial mindset prevails, and the organization is centered around the value to the customer. However, with the growth of the organization as the workforce swells, the functional segregation of responsibilities takes place, and delivering value while maintaining stability in the organization becomes the key factor, which makes customer centricity take a hit. The organization becomes fragmented, with experts running the functions like HR, Procurement, Finance, Infra, Data, IT, Operations, Innovation etc. The silos get created. The best case in these traditional organizations like XYZ turns out to be that each function can deliver the expected value while only struggling to collaborate with the rest of the functions, and the worst case, well, there are silos within the functions themselves. Thus, when somebody like the CEO of XYZ tries to pursue a large transformation program in the organization, which largely means adopting digital solutions cutting across the functions to drive quality value to the customer faster, it’s heard by the organization as function-wise goals that many a times lead to competition rather collaboration among functions. However, the value to the customer traverses through various processes cutting across functions, and unless the organization focuses on the end-to-end transformation of the entire value chain i.e. from trigger to delivery of the value to the customer, the end goal would be far from achieved. The usual modus operandi in most of the organizations for such transformation is to create large projects and pull people from the different functions to form temporary project teams. These projects follow slow budgetary processes where each project needs multiple budgets which is essentially the addition of budgets from different cost centers, and if the budget runs out, which usually does happen because of the limited understanding at the beginning, then the project must again go through the grilling process of more budget allocations. The project teams even if try their best, can’t have the best motivations either, as a project is driven by utilization-based planning and execution where people are more worried about their billing for their agreed responsibility rather than the value created for the end customer. The overall accountability in a project is also diluted by the temporary nature of these projects as the loyalty of the team members lie with their respective functions where they are bound to return after delivering the solution and handing over the further responsibilities to the operational support which is another function. Moreover, the upfront budgeting and the freezing of requirements and the architecture at the beginning leave little room for the project teams to change course in the event of refinement in the understanding of requirements or even change in the requirements itself. Even if the changes happen, they must go through a lot of monetary and technical hassles which are always time taking. In that scenario, sticking to the timelines and the plan looks more important rather than improvising based on new learnings about customer and market, which is like anti-agile.
Now imagine that the CEO of XYZ has a way to get his intent of transformation translated into actionable tasks cascaded from the top to the bottom of the pyramid, and he has absolute transparency into the progress of the whole transformation through measurable and relevant metrics. The organization is focused on transforming each step of the value chain in a customer-centric way such that the high-quality value is delivered in the shortest sustainable lead time. Rather than big projects, there are minimum viable products planned to validate the solutions, and then based on the results, teams decide to persevere or pivot from the selected solutions thus being agile and minimizing risks. The budgets are allocated for these minimum viable products and then further allotted incrementally based on the success of these products and their subsequent progress. There is a framework to enable the entire organization to plan and deliver in a synchronized manner aligned with the concepts of Lean, Agile, and DevOps.
But is it possible? Well, this and even more is what the Scaled Agile Framework is doing for thousands of enterprises across the world. With the sole intent to help organizations perfect the adoption of business agility, SAFe provides an elaborative framework based on Lean, Agile, and DevOps to create value in a customer-centric way. Business agility is the ability to respond to the market changes and emerging opportunities with innovative, digitally enabled business solutions. In order to survive and thrive in today’s world, enterprises proactively need to align with customers’ needs and expectations as well as always strive to stay ahead of the competition. With the lives of digital solutions getting shorter and with so many choices at the discretion of customers, it becomes imperative that enterprises are positioned to explore new ideas, quickly try those ideas as minimum viable products or POCs, and then either discard them or further build upon them.
A large digital transformation project in SAFe can be managed at a ‘portfolio level,’ ‘large solution level,’ or even at an ‘essential SAFe level,’ depending on the number of value streams involved. The key to the success of SAFe is the alignment of the delivery of value with the value streams rather than functions, thus essentially bringing customer centricity to the driver’s seat again. It gives a structured approach to an organization like XYZ to translate its vision and strategy into well-defined deliverables (Epics, features, stories), augmenting the minimum viable product incrementally to develop the final solution spread across various functions leveraging a cadence-based, timeboxed event called Planning Interval (PI).
PI planning, which is the soul of SAFe, brings together every single stakeholder concerned with the program in a single room for usually a two-day-long workshop to plan together the deliverables, strategize for risk mitigation and agree on the dependencies. PI planning has done wonders for organizations across the world. Another reason for SAFe being the most popular framework is that it empowers the people who are responsible for creating value on the ground by enabling decentralization of decisions. These people are no longer just taking instructions from their managers and working to finish their tasks; rather, SAFe enables them to contribute to the bigger scheme of things by planning for themselves. This is the best kind of motivation any employee can find in a workplace.
Thus, an organization striving to achieve a big transformation through SAFe turns into a big team planning, executing, reviewing, and doing course corrections in the most synchronized fashion possible. However, even after proving its worth through thousands of real success stories globally, SAFe still finds itself at the wrong end with so many organizations. One of the big reasons for that is that many organizations get scared by its comprehensive detailing and the scale of implementation it may need. Many such organizations attempt half-heartedly to implement their own customized versions of SAFe and then either struggle to leverage the full benefits or sometimes even fail altogether, blaming SAFe for their ill fortunes. The important thing to understand here is that only due to this comprehensive nature of SAFe, different organizations in the world with so many complex and different operating models now have a standard roadmap for the implementation of SAFe and how it can be perfected over time. No doubt that organizational-level customizations are a must while adopting SAFe to make it fit for purpose, but precursor to such alterations is that the underlying principles of SAFe should never be tempered with.
SAFe also recommends avoiding getting stuck in over-preparation for implementation and instead following the prescribed fundamental steps without overthinking about perfection. Relentless improvement is, after all, one of its core values, and the adoption of SAFe continues to improve with every PI. Implementing SAFe and excelling at it is a journey that requires time and commitment.
However, the question to ask here is, which path poses a bigger risk to XYZ’s journey — sticking to it’s current way of working or trying to adopt the Scaled Agile Framework?