How to Scale the Agile with Scaled Agile Framework(SAFe) and Large Scale Scrum(LeSS)?

 SAFe Introduction: The Scaled Agile Framework(SAFe) built upon Agile, Lean Systems Thinking and Product Development Flow. It allows agile to be scalable for enterprise systems and software. Similar to Scrum, it offers the flexible and evolving framework in which milestones are met to complete a larger project. It provides practices, roles, artifacts and activities for agile development at the enterprise scale. It is a loved resource for large enterprise companies that driven by its structural and methodical approach to project alignment and completion.
     The Scaled Agile Framework can be implemented in the enterprise-class product or service initiative. It allows the user to see the SAFe Big picture to understand the roles, teams, activities necessary in enterprises. SAFe adoption delivers the best business benefits concerning faster time to market, higher quality of the product, improves the productivity and employee engagement.

    Delivering the Software with SAFe: One of the activities of SAFe is the alignment of multiple agile teams around the value streams. It is the lean construct that provides the organisational pattern for delivering the continuous flow of value. Value Streams are realised through the Agile Release Trains(ARTs). It serves as the delivery mechanism for value streams. The key concepts of ARTs are,
    * ARTs work on a fixed and reliable schedule provides the regular development and predictable planning. They also provide an architectural and UX guidance and release governance.
     * The people needed to the ART are dedicated to the train regardless of the reporting structure. It makes easier to apply SAFe without reorganising the enterprise.

  Program Level work of Scaled Agile Framework: Program-level work accelerate the Agile Release Train(ART) that delivers the solution incrementally to the stakeholders. It consists of planning, program kanban, and adapt activities which inspect the optimum quality of the solution.
      The Agile Release Train consists of multiple agile teams, and the individuals are responsible for leading the Train and providing the maximum output in their roles as,
     * Release Train Engineer: Guides the flow of value in the Agile Release Train
     * System Architect and Product Manager: Constructs the architecture of the System. The System Architect has design authority at the program level.
     * Product Manager: Product Manager has the complete authority over the content and understands the Customer Needs
     * Business Owner: Stakeholders or Customers can provide the feedback of the product
Artifacts are the result at the program level that is,
    * Features: items that are become part of the final solutions
    * Product/Program Backlog: It is the list of features that have to be implemented for an Agile Release Train.
    * Program Epics: It originates from Portfolio Epics and become part of the Agile Release Train.
    * PI Objectives: The Program Increment Objective which has to be achieved
    * Architectural Runway: It is the technical vision consisting of code and the features that become the part of the solution that enhances the value of the business.
Portfolio Level Requirements: The collection of multiple value streams is called as a portfolio. It connects the enterprise software via themes like investment funding, program management, strategy. Each theme assists with overall budget planning in large development initiatives called epics. Business epics are the customer-facing solution while the architectural epics are technology facing solutions that are managed in the kanban system.


Configurations of SAFe: Businesses can choose the configuration of SAFe to complete the enterprise software. It can be defined as,
  * Essential SAFe: It is the basic configuration and businesses choose this configuration because it focuses on the critical elements needed to be successful. It includes a foundation with team and program levels.
  * Large Solution SAFe: This is same as essential SAFe with a large solution level added in place of Program Level. This Solution train ensures value delivery of the most complicated large-scale systems.
   * Portfolio SAFe: It contains 3 levels such as Team, Program, and Portfolio level requirements. In Portfolio level, the budgets are defined with the help of epics and themes.
   * Value Stream - There is a 4th level SAFe framework used to scale the enterprise solutions. It is an additional layer between the  Program level and Portfolio level. A value stream can be defined as the series of steps it takes to deliver value from the beginning of development to customer interaction. It flows from customer request to delivery.
  * Full SAFe: It is the configuration that has all the configurations of SAFe in one package. It is a very large systems contain thousands of people to develop. It comprises Team, Project, Portfolio and Large Solutions.

Here is the nutshell of SAFe,

                                   Image Credit: Henrik Kniberg

Adoption of SAFe: The Value Stream that produces the consistent result is essential to the adoption of SAFe to the Organization. So, consider these question to identify the value stream,
       * Is the Executive Supports this idea?
       * Where are the team members are located and distributed?
       * What are the programs that provide the biggest opportunity?
       * What program to adopt SAFe the fastest?
   If you are looking for a solution to scale your development platform for large-scale enterprise solutions, SAFe could be the right iteration of Agile for your business. The benefits of using SAFe in your enterprise solution includes the organised structure, clear definitions and boundaries with the flexibility and overall ability to scale with program needs. SAFe based on the principles of Agile for developers who are used in scrum and sprints to provide consistent results with the same level of reliability. It makes an excellent choice for developers in any organisation that needs to restructure their development framework and processes.

 Large Scale Scrum(LeSS) Introduction:  Is it possible the small-scale development can apply the large-scale development? This question has driven Craig Larman and BassVodde to hundreds of experiments and formulate the LeSS. LeSS scales up the activities in the scrum, applying at the team-of-teams level, while the scrum is single team oriented. Large Scale planning is done by delegating one or two members from each team to the higher level team.  Retrospective and scrum of scrum problem solving are done in the same way. LeSS is defined by minimalism and minimal process, i.e. use as little process as possible to get multiple teams to work well.  LeSS is a solution of how Scrum is intended to work.

Overview: LeSS has a set of principles and experiments. It is based on some of the proven principles of Queueing Theory, System Thinking, Empirical Process Control. It is a product development framework for building the products with at least 2 teams. It is based on the scrum rules, and it can extend multiple team scrum. LeSS tries to stay true to the Agile Manifesto and scrum while figuring out how to work with more teams on the same product.
      Also, LeSS manage the products as products and not as projects. It leads to permanent long lived team owning their work and continuously improving forever. The effect of having the lot of roles, artifacts, process, and layers causes the team does not own the process, the process own the team. With LeSS, you have less roles, less artifacts, and less process but more ownership, creativity, improvement and purpose. It is called More with LeSS.


LeSS Framework: It is a Scrum with Scrum master, development team and product owner. This stable team grows into Feature team. LeSS is based on lean thinking and systems thinking. LeSS organisations follow a simple structure. Work is organised around the teams, and mismatch of skills triggers the learning and coordination within existing teams. Feature teams scales the team that goes above 8 members, and then the additional structure is needed. The requirement area provides this structure with concepts behind the feature teams. Requirement area is the categorisation of the requirement, leading to different views of the Product Backlog managed by a Product Owner. LeSS has an architecture and design, technical excellence, and continuous integration to add value to scrum. It looks like the below picture,

Organizational Descaling & Adoption: When adopting to LeSS, it will reflect the structure of your organisation. The organisational problems that are traditionally solving in a complex way can be solved more easily in LeSS. The small batches of working software Sprint by Sprint enables the removal of complexity in traditional development.
    Traditionally, Organizations manage the work using the projects. A project from Agile is managing the large batch of requirements towards the release. The project way of managing the work is obsolete when focusing on the product and delivering value to the customer. It is much easier to manage small batches of work via product backlog for the life of product. This allows investing within budget in the product, based on the predicted and realised customer value. Thus LeSS organisation descaled the organisation by removing projects and project management and solve the organisational problem of managing the work.

Business Analysis Are the Focal Point For Scaling Agile: Most of the organisations are delighted with the results produced on the agile projects, but they are struggling in the application on large and complex projects and adaptation in enterprise-wide frameworks like Scrum of Scrums, Scaled Agile Framework(SAFe), Large Scale Scrum(LeSS) and Nexus. There is a great deal about which framework is best that there is a need for coordination, integration, and communication among agile teams related to the solution being developed. It is a Business Analysis work that has always been needed on large, integrated projects - the coordination of dependencies, security, business and technical impacts, and version control etc.,