CI/CD Pipeline with Scaled Agile Framework (SAFe)

/0 Comments/in , /by

Continuous Exploration, Continuous Integration, Continuous Deployment, & Release on Demand are the Four Major Aspects of SAFe.

The Continuous Integration / Continuous Delivery (CI/CD) Pipeline includes the phases, activities, and automation needed to develop and deploy a new software feature or improvement from analysis to an on-demand release to a production environment for use by a system user. The pipeline is a significant element of the Scaled Agile Framework (SAFe) method for organization-level software development. Moreover, SAFe utilizes a concept known either as agile release train (ART) or solution train (ST). This concept encompasses a team of agile teams collectively responsible for the regular release of features, functionality and improvements. Further, each agile release train independently builds and deploys their own software applications using their own CI/CD pipeline.

The use of a comprehensive CI/CD pipeline provides each agile release train within SAFe with the ability to implement and deploy new or enhanced functionality to users in a more rapid fashion than more conventional software development processes. Conventional practices typically have long implementation cycles, and they tend to deploy large software releases with a great deal of features included. In contrast, the SAFe CI/CD pipeline utilizes short implementation cycles and it enables the deployment of much smaller software releases. Additionally with the SAFe CI/CD pipeline, software modules are developed and deployment of software releases occur as needed. This could be several times a day, several times a week, weekly, or monthly depending on the when the functionality is required to be deployed.

In the previous diagram, the SAFe CI/CD pipeline is shown to be sequential in which the process follows in order of phases (analyze, design, code, build, test, release, deploy). However in reality, the agile release train conducts many of the tasks in parallel. Additionally, analysts, developers, quality assurance personnel, subject matter experts, and operations staff of the agile release train typically all work on tasks at the same time but not necessarily on the same feature. With a shared vision and with team members working concurrently, every agile release train increment and iteration includes: Analysis of requirements, development of functionality, quality assurance, feature demonstrations, deployments to production, and the realization of value.

The SAFe CI/CD Pipeline Includes Four Distinct Aspects:

Continuous Exploration is the process in which user and business needs are identified and features that address those needs are defined. The focus of continuous exploration is to create alignment between what is needed to built and what can be built. During continuous exploration, ideas and concepts are continuously converted into features and specifications of the features are continuously provided. Continuous exploration replaces the conventional waterfall approach of defining all systems requirements at the beginning of the implementation with a more rapid process that generates a consistent flow of features that are ready for the agile release train to implement. Features are defined as small units of work that can travel easily and quickly flow through the remaining aspects of the pipeline. Additionally, within in the continuous exploration process, features are prioritized within the release train backlog.

Continuous Integration is the process of taking features from the release train backlog and building the features into working software modules. Within continuous integration software modules are developed, tested, integrated, and validated in either a pre-production or staging environment where the working software modules are ready for deployment and release. Additionally continuous integration includes a practice in which the merging and testing code of code is automated and code is constantly being integrated into a shared code repository. While automated testing is not required as part of continuous integration, it is typically implied. Continuous integration enables agile release trains to effectively collaborate in the development of different components of a complete software application.

Continuous Deployment is the process of taking completed and validated software modules located in either a pre-production or staging environment and migrating them into a production environment. Once migrated to a production environment, the software modules are verified and monitored to ensure that they are working properly. At this point in the process, software modules become part of the deployed solution and are able to be fully-utilized. This aspect of continuous deployment allows the organization to release, respond, rollback, or fix deployed software modules.

Release on Demand is the ability to make competed software modules and functionality available to system users either all at once or in a incremental/staggered fashion. Subsequently, the business determines the appropriate time to release the completed software modules to groups of system users. New functionality can be released to all system users as soon as it is developed. But more often aspects of each release are provided to groups of system users, timed for when the groups need the new functionality or for when it makes business sense to release new functionality.

Share

SAFe’s Agile Release Train (ART) and Release Train Engineer (RTE)

/0 Comments/in , /by

SAFe’s Agile Release Train is Comprised Multiple Agile Teams Working Together

Agile Release Train (ART)

The SAFEe Agile Release Train (ART) is the primary value delivery construct in Scaled Agile Framework (SAFe). ART is a long-lived team of Agile teams that are cross-functional across an organization and include all the capabilities needed to define, implement, test, deploy, release, and operate solutions. In a nutshell, ARTs include the teams that define, build, and test features and components, as well as those that deploy, release, and operate the solution. ARTs are organized around the enterprise’s significant value streams and they live solely to realize the promise of that value. Hence, an ART is basically a team of teams responsible for the regular release of features and business benefits. And all the teams within an ART are bound by a common vision, strategy, and program backlog. The ART provides alignment and helps manage risk by providing program level cadence and synchronization. It is based on agreement and adoption of a set of common operating principles and rules which are followed by all teams included within the train.


Release Train Engineer (RTE)

The SAFe Release Train Engineer (RTE) is a servant leader within the SAFe framework that serves at the enterprise level, and operates as a full-time chief scrum master. Further, the RTE manages program level processes and execution, facilitates constant improvement, drives continuous development and continuous integration, confirms value delivery, mitigates risks, and resolves impediments at both the strategic and tactical levels. RTE’s are critical to an organization’s Agile framework because they drive ART events and ceremonies as well as help teams deliver value. RTE’s must have extensive knowledge of how to scale Agile practices as well as an understanding of both the unique opportunities and challenges involved in the facilitation and continuous alignment a multi-team development environment.

Release Train Engineers have very similar responsibilities to conventional project managers. They both are responsible for issue, risk, and dependency management, quality assurance, time, people, cost management, and team communications. But they also perform a different type of role. Project managers typically handle scheduling, scope, or change management. Contrarily, RTEs are responsible for program level ceremonies and the release train organization. While the project manager’s role is typically more focused on planning and organizing activities and teams, the RTE’s job in more concerned with mentoring, educating, and improving team member skills, enabling teams to effectively execute, and managing the entire work environment.

Share

What is Scaled Agile Framework (SAFe)?

/0 Comments/in , /by
SAFe Enables Agile Systems Development to be Conducted at the Enterprise Level.

About SAFe

Scaled Agile Framework (SAFe) extends the core concepts of Agile systems development and is designed to be used for an entire organization. While Agile is typically designed as an implementation framework for an individual team, SAFe enables Agile concepts to scale beyond a single team. SAFe is designed for implementing Agile concepts for multiple Agile teams working concurrently. SAFe encompasses concepts from three bodies of knowledge related to systems deployment: agile software development, lean product development, and devops. Moreover, SAFe is the most commonly utilized approach for scaling and common management of Agile implementation practices.

Dean Leffingwell and Drew Jemilo created and released SAFe in 2011 in order to assist organizations to more effectively develop and deploy systems and solutions to better satisfy their client’s changing requirements. Their idea of SAFe has been to enhance the effectiveness of systems development and enable systems development processes to embraced at the enterprise level. Moreover, they designed SAFe to help businesses continually and more efficiently deliver value on a regular and predictable schedule.

SAFe Four Core Values

SAFe encompasses four core values that define the essential ideals and beliefs of this enterprise framework. These core values establish an organizational culture that enables effective utilization of the framework.


Value #1: Alignment – SAFe requires that planning and reflection cadences be put in place at all levels of the organization and for all teams. Cadences are also known as sprints and are consistent two, three, or four week periods in which a set amount of work is planned, conducted, completed, and reviewed.

Value #2: Built-in Quality – SAFe requires teams at all levels to provide a definition of complete or “done” for each unit of work (i.e. task, issue, feature, story, epic, etc.) and to include quality assurance within the development process.

Value #3: Transparency –  SAFe enables visibility into all aspects of the development process for all implementation teams including proposed features, priority of features, estimates of tasks, work being performed, work completed, and reviewed features.

Value #4: Program Execution –  SAFe requires that both programs and individual teams deliver quality working solutions that have business value on a incremental and regular basis.

SAFe Ten Principles

SAFe is based upon ten fundamental principles that guide behaviors and influence how decisions are made for all implementation teams at all levels of an organization. These underlying principles are not just intended for use by leaders and managers, but for all members of the organization. Further, these principles enable a shift from a traditional waterfall approach for development to the effective use of Agile system development practices.


Principle #1: Take an Economic View –  The entire chain of leadership, management, development team members workers must understand the financial impact of the choices they make and everyone should be make decisions based upon both the benefit and cost of the decision.

Principle #2: Apply System Thinking –  Systems development must take a holistic approach that incorporates all aspects of the system and its environment into its design, development, deployment, and maintenance.

Principle #3: Assume Variability; Preserve Options –  The goal of the process is to manage unknowns and to manage options, providing both the controls and flexibility development teams require to build quality systems.

Principle #4: Build Incrementally with Fast, Integrated Learning Cycles –  Development cycles and integration points must be planned with short repeatable cycles in order to enable feedback, learning, synchronization, and coordination among teams.

Principle #5: Base Milestones on Objective Evaluation of Working Systems –  Demonstrations of working features provide a better mechanism for making decisions than a requirements document that is only documented on paper.

Principle #6: Visualize and Limit Work-in-Place (WIP), Reduce Batch Sizes, and Manage Queue Lengths –  Maintain a constant flow of tasks in the development process by controlling the amount of overlapping work, the complexity of work items, and the total amount of work in-progress at a particular time.

Principle #7: Apply Cadence, Synchronize with Cross-Domain Planning –  A regular cadence makes everything in the development process that can be routine be routine and enables team members to focus on system development. Synchronization allows multiple perspectives to be understood, integration issues to be resolved, and features to deployed at the same time.

Principle #8: Unlock the Intrinsic Motivation of Knowledge Workers –  Leaders should leverage the mindset of coaching and serving team members rather utilizing command and control techniques.

Principle #9: Decentralize Decision-Making –  Tactical decisions are delegated to the individual teams and teams are provided the autonomy they need to make informed decisions on their own.

Principle #10: Organize Around Value –  Organizations should create a structure that focuses on both the innovation and growth of new ideas as well as the operation and maintenance of existing solutions.

Share