Face any Scaled Agile job interview like a pro with the best Scaled Agile Framework interview questions and answers for experienced and freshers. If interviews are getting harder, it’s time to ramp up with the expert-designed top interview questions and answers on Scaled Agile Framework and proven interview tips. Be well-prepared with Scaled Agile Framework interview questions to impress your employers!
Delivery early and often is one of the two crucial pieces’ needed to achieve optimum economic outcomes through Lean-Agile approach. It is an integral part of SAFe Principle #1 – Take an economic view. “If the solution doesn’t meet the Customer’s or solution provider’s economic goals, then its sustainability is suspect” – As per scaledagileframework.com
The concept emphasizes the importance of early and frequent releases to the customer by delivering business value at every delivery. Earlier the process model allowed the product being accessible to the customers at the end hence impacting the customers to reap early benefits from the markets, services delivered to market early are typically more valuable. Early delivery often benefits with the fact that the customer is continually being part of the process and contributes through significant feedbacks.
Moving towards Agile development is big step that organizations choose to take as it requires a lot of effort from all the directions but they resort to this stage once they realize that their existing processes aren’t generating the results they need. Through the concept of deliver early and often, the organizations can go for incremental development and early and continuous value delivery and in turn benefiting the customers and at the same time satiating the economic view as a whole.
Features and capabilities are essential to the SAFe Requirements Model. They are absolutely necessary in the defining, planning, and implementing Solution value.
A Feature is an ability that fulfills a stakeholder requirement. Every feature has two core concept - a benefit hypothesis and acceptance criteria, and is sized or split as necessary and made ready to be delivered by a single Agile Release Train (ART) in a Program Increment (PI). Acceptance criteria in features are used to determine whether the implementation is correct and delivers the business benefits. Features can include additions or changes to existing functionality. A feature spans over a single ART (Agile Release Train) and broken down into stories targeting the completion in a PI. Product Managers, in collaboration with Product Owners, and other key stakeholders, define features in the local context of an ART. Some arise as a result of splitting epics.
A Capability is a higher-level solution behavior that typically extents multiple ARTs (Agile Release Train). Capabilities are sized and broken down into multiple features to aid their implementation in a single PI. They exhibit the same characteristics and practices as features e.g. they are described using a phrase and benefit hypothesis and are sized to fit within a PI, however, they often take multiple ARTs to implement.
A Value Stream is a long-lived series of steps that provide a continuous flow of value to the customer whereas an Agile Release Train (ART) is a long-lived team of teams that is organized around a Value Stream. A Value Stream can have many ARTs within it. SAFe value streams are used to define and gather Portfolio-level business goals and establish Agile Release Trains (ARTs) to deliver value more quickly. Forming around value offers significant benefits to the organization, including faster learning, shorter time-to-market, higher quality and higher productivity.
For example, if there is a feature request from the customer which triggers the flow of value. It finishes when some value has been delivered—a shipment, customer purchase, or solution deployment. The phases during the execution are the activities the enterprise uses to accomplish it. A value stream contains the people who actually work, the systems they develop or operate, and the flow of information and materials. The time from the trigger to the value delivery is the lead time. Minimizing the lead time reduces the time-to-market.
Shared Services comprises of the specialty roles, people, and services that are compulsory for the accomplishment of an Agile Release Train (ART) or Solution Train but these shared services cannot be dedicated full-time. The need of Shared Services arise when there may be a lack of a specific expertise available. Also, the requirements of the ART may change, making full-time availability unrealistic. To cater this scenario, Shared Services supports development by quickly focusing specialty expertise on the areas of the system or Solution that require unique knowledge and skills. They participate in Program Increment (PI) planning along with Pre- and Post-PI Planning.
The benefits of utilizing the Shared Services in Scaled Agile framework is immense, to mention a few, it can save time improves productivity by eliminating the need for individual development team, drives efficiency throughout the organization, accelerates speed to market of quality software products. One of the biggest benefits include, working together with agile teams to fulfill the dependencies that happen/are encountered during PI execution.
While not dedicated to the train, Shared Services must travel with it, as the train has to carry some of their cargo, too.
People who can participate as a likely Shared services normally have the following specialized skill - Agile and Software/Systems Engineering Coaches, Information architecture, IT Service Management and deployment operations, Internationalization and localization support, etc.(to mention a few)
Scaled Agile Framework is completely based on Lean-Agile Mindset which is combination of beliefs, assumptions, and actions of SAFe leaders and practitioners who hold the concepts of the Agile Manifesto and Lean thinking. Lean Thinking which is chiefly defined through SAFe’s ‘House of Lean’ and was derived from Lean manufacturing inspired by Toyota’s ‘Houses of Lean’. It was then applied to software products and solutions development.
Implementation of any model targets to deliver value to its stakeholders/customers, hence, in the SAFe’s ‘House of Lean’, the top most thing is the GOAL: Value, then we have pillars on which this Goal stands. Optimize the Whole is a part of fourth pillar in the house of lean – Relentless Improvement. It talks about optimizing the organization and the development process as whole and not in parts. It encourages learning and growth through continuous retrospection and process improvements.
Decentralized decision-making is a method where the decision-making ability is distributed throughout a larger group. It tends to create less stringency and flatter hierarchies in organizations.
In the Scaled Agile Framework, Decentralize Decision is part of the SAFe principles at the foundation. It is the ninth principle, which talks about decentralization for optimal value delivery. With the dependency on the decision making by the higher level authority, the lead time increases, which in turn impacts the quality due to lack of context along with the changes that happened during the waiting time.
Hence, the ninth principle focuses on decentralizing decision making so as to reduce the waiting time, improving the flow of development along with faster feedback cycles. This decentralization also gives space for innovative solutions. Though, SAFe talks about decentralization but it also mentions that there are few areas which should be kept out of the scope of decentralization, decisions with the characteristics – Infrequent, Long-Lasting and provide significant economies of scale – are centralized. Though the higher level authority can make decision on these but the decisions will be supported by the input of those affected the outcomes. Apart from the above mentioned all other decisions will be decentralized such as - Team and Program Backlog prioritization, point releases, customer emergencies, dependencies with other teams or response to defects and emerging issues.
In SAFe, the System Team is one of the agile teams responsible for providing support in constructing and employing the development environment infrastructure and evaluating the system increments. This can include development and maintenance of continuous integration, build environments, Create products, utilities and scripts to automate deployment testing platforms and testing automation frameworks, and integrating code from Agile Teams. The System Team also has the skills and tools needed to perform end- to-end system testing, demonstrate solutions to stakeholders and assist with Nonfunctional Requirements system testing. One of the responsibility also revolve around Facilitate the technical aspects of collaboration with third parties, such as data or service providers and hosting facilities.
The System Team often takes part in the System Demo at the end of each iteration and the Solution Demo at the end of each Program Increment. Once the infrastructure is stable and settled, the decision can be taken to remove the system teams from the ART and the development teams pull up the maintenance and usage work.
System team testers' responsibilities include:
Scrum is being widely used at the Team Level, even in the last year’s report from the Standish Group, more than 68% of organization in Agile use Scrum at the core level. But, it is not the only practice that is being followed in SAFe, the teams in SAFe can use the practice which works best for their team and the delivery. There is no prescription written in stone for the teams, they can opt for Kanban, Extreme Programming (XP), Scrum or even Scrum with XP. The SAFe teams usually work on agile practices, owing to the fact that it is lightweight that ensures quick value delivery to the stakeholders.
But the teams can use Kanban or XP and they don’t have to limit themselves to Scrum.
Kanban is based on 3 basic principles:
One of the important moves while implementing SAFe is identifying Value Streams and the Agile Release Trains (ART), both of them carry a critical role and can be termed as the backbone of the scaled agile model. A value stream is a sequence of activities that an organization undertakes to deliver on a customer request, and being more specific - A value stream incorporates all activities undertaken from start to end for a definite product or service in order to provide business value. Value streams are typically cross-functional, cross-organizational, and cross-geographical. When we develop systems to support value streams or deliver value directly, we do that with an Agile Release Train (ART). The ART contains all the right people, and all the skills needed, to deliver some or all of a value stream.
“ARTs are cross-functional and have all the capabilities—software, hardware, firmware, and other—needed to define, implement, test, and deploy new system functionality. An ART operates with a goal of achieving a continuous flow of value” – ScaledAgileFramework.com
An ART is a virtual organization that includes all of the people, with all of the requisite skills, to deliver value. After all, people do all the work, and we realize value with people in ARTs.
There are also ARTs that are physical organizations. ARTs are designed in such a way that each ART can deliver a set of capabilities, and in some cases, release independently of other ARTs.
A Value Stream can have many ARTs within it.
SAFe actually is a Scrumban arrangement kind of. In the earlier version of SAFe, Scrum teams worked at the Team level, within the larger iterative Program
SAFe actually is a Scrumban arrangement kind of. In the earlier version of SAFe, Scrum teams worked at the Team level, within the larger iterative Program Increment (PI) cadence. Now, both Scrum and Kanban teams have been “legitimized” at the Team level, and can coexist within the same program. And while there is still a PI cadence, there are Kanbans now at the Portfolio, Value Stream, and Program levels. The teams mostly use Scrum at the Team level and work in scrum fashion with all the ceremonies and following the cadence as set by the organization. SAFe does not have hardcore prescription for any particular agile process, at the team level, the teams have the liberty to use either Scrum, Kanban or Scrumban.
Yes. The Customer is a part of the Value Stream. Talking about Lean-Agile framework, customer is an important entity. There are two types of customers – Internal and External. Internal Customer can be the IT department or the HR systems, requesting to build solutions around their requirements. External customers are the ones who are the direct buyer of the solution.
Below are the few responsibilities which the Customer has to fulfill (as per ScaledAgileFramework.com)
Lean-Agile development depends on a high grade of customer engagement. There can be different ways to engage a customer which is dependent on the solution which either can be General or Custom-Built.
A General solution is designed to be used by a large group of people whereas Custom built focuses on individual customers. General solutions developed must address the needs of a larger audience. No single customer is an adequate proxy for the whole market. (as per ScaledAgileFramework.com)
For custom-built solutions, the external customer is typically defining the solution with the support of Product and Solution Management. However, even though the customer is leading the effort, it is critical to establish a collaborative approach to scope and prioritization. This fosters incremental learning and exhibits a willingness to adjust the course of action as needed. Active participation in PI planning, the solution demo, and selected specification workshops is required. This will often reveal inconsistencies in requirements and design assumptions, with potential contractual problems. This process should drive the customer and ARTs toward a more collaborative and incremental approach. (as per ScaledAgileFramework.com)
The success of Agile is mainly driven by Customer Engagement. Every communication with a customer give companies an opportunity to not only provide a great experience, but to collect visions that can be used to mend processes and provide an even better customer experience.
A continuous delivery pipeline is an implementation of the continuous pattern, where automated builds, tests and deployments are arranged as one release workflow. The pipeline consists of four elements: Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand. Each Agile Release Train (ART) constructs and sustains a pipeline with the resources and technologies desired to deliver solution value as self-sufficiently as possible. The first three elements of the pipeline work together to support delivery of small batches of new functionality, which are then released in accordance with market demand. An ART operates with a goal of achieving a continuous flow of value, aligning teams to a shared mission and helps manage the inherent risk and variability of solution development. ARTs are typically virtual organizations that have all the people needed to define and deliver value.
Solution train constructs complex solution with a Lean-Agile approach. It organizes and coordinates multiple Agile Release Trains into one. It guides the attention of hundreds or even thousands of entities towards attaining a common goal. This is planned for creating solutions on a large scale. A solution train starts like a conventional SAFe Program Increment Planning session. But instead of having Agile Teams that become a part of the Agile Release Train, there are Agile Release Trains that participate. The vision and the backlog are aligned. The dates are decided for the cadence and the schedule to follow. The planning of the budget is done according to an Economic Framework. This framework consists of lean budgets, epic funding, decentralized planning and job sequencing. The Economic Framework effectively arranges the team to complete its business objectives by considering the business constraints and staying within the set budget.
At the end of every iteration, there is a solution demo. It is a demonstration of what has been done to get feedback from the stakeholders or product owners. It is used to evaluate the integrated solution that has been created by the Agile Release Trains in the Solution Train. After every solution demo, there is an Inspect and Adapt session. Problems are identified and are used to improve in the next iteration.
There are roles in the Solution Train and additional help that supports the delivery.
A System Team is often responsible for providing assistance in building and utilizing the development environment infrastructure and evaluating the system increments. This can include development and maintenance of continuous integration, build environments, testing platforms and testing automation frameworks, and integrating code from Agile Teams.
The primary responsibilities of the System team include:
System Integration: The System teams participate in PI Planning and the Pre- and Post-PI Planning gatherings at the Large Solution Level, and in backlog refinement to define integration and test backlog items, run solution-level integration scripts or manually integrate where automation is not yet possible.
End-to-End and Solution Performance Testing: The System Team may also perform some automated testing duties which include creating newly automated test scenarios, extending test scenarios to data sets that more closely match production, organizing test cases designed by individual teams into ordered suites, perform manual testing and run automated tests for new features and Stories
System and Solution Demos At the appropriate time during every iteration, the ART demonstrates the current, whole system to stakeholders in the system demos. Likewise, the Solution Train must integrate and show progress at the solution demo. The System Team typically helps prepare the technical environments, so they adequately and reliably demo the new solution functionality.
With SAFe 4.5, we have a new redefined role structure as stated below:
System Team - A System Team is often responsible for providing assistance in building and utilizing the development environment infrastructure and evaluating the system increments. This can include development and maintenance of continuous integration, build environments, testing platforms and testing automation frameworks, and integrating code from Agile Teams.
Product Manager - Product Management has content authority for the Program Backlog. They are responsible for identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban and developing the program Vision and Roadmap.
System Architect - is an individual or small cross-discipline who define the overall architecture of the system, help define nonfunctional requirements, determine the major elements and subsystems, and help define the interfaces and collaborations among them.
Release Train Engineer (RTE) - The Release Train Engineer is the _Chief Scrum Master_ who facilitates program-level processes and program execution, escalates impediments, manages risk, and helps drive program-level continuous improvement.
Release Management Team – They look after the process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases.
The basic responsibility of a Lean – Agile leader is to ensure successful embracement of SAFe and for the results the Lean enterprise can provide. These people support individuals and teams. They are life-long learners, managers, teachers, and coaches who help teams build better software systems through understanding and exhibiting the values, principles and practices of Lean, systems thinking and Agile software development. Lean-Agile Leaders adhere to Four Principles of Lean-Agile Leadership. On each occasion, a leader’s behavior plays a critical role in communicating, exhibiting, and emphasizing them. Thus, reinforcement of core values is an important aspect in the overall responsibilities that Lean Agile leaders hold. Another critical role play is around Supporting SAFe Lean-Agile Principles and Adopting and Exhibiting a Lean-Agile Mindset.
“The SAFe Lean-Agile Mindset is the combination of beliefs, assumptions, and actions of leaders and practitioners who embrace the concepts in the Agile Manifesto and the SAFe House of Lean. This way of thinking is leadership’s intellectual foundation for adopting and applying SAFe principles and practices.”- ScaledAgileFramework.com
Alignment is one of the core values in SAFe.
As per ScaledAgileFramework.com - “Like cars out of alignment, misaligned companies can develop serious problems. They are hard to steer, and they don’t respond well to changes in direction. Even if it’s clear where everyone thinks they’re headed, the vehicle is unlikely to get them there. While empowered Agile Teams are good, the responsibility for strategy and alignment cannot rest with the combined opinions of the teams, no matter how good they are. Instead, alignment must rely on the Enterprise business objectives. Here are some of the ways how SAFe supports alignment:
Changing our ways of working is difficult. Scaled Agile Framework likely represents a significant transformation in your organization. Beginnings are very important. Tipping point in SAFe refers to the point at which the dominant organizational authoritative is to achieve the change, rather than resist it.
“It’s easy for people to keep their old behavior—unless there is an exceptionally good reason to make such a change. A reason so compelling that the status quo becomes simply unacceptable. A reason so strong that change becomes the only reasonable way forward to success.” - ScaledAgileFramework.com
Sometimes, the situation can be, the company is not able to compete, and the current way of doing things is clearly insufficient to achieve a resolution within a survivable time. This can be a case for change. While there will always be those who are resistant, they probably will be overcome by the upsurge of dynamism that pushes the required modification through the organization. If this is not the case, the leadership can proactively create a case for better delivery prospects.
Nevertheless, there should be a convincing reason for the change and a vision to complement with it.
The primary goal of decentralized decision–making is to enable faster flow of value. Decentralized decision-making, Malone says, tends to create less rigidity and flatter hierarchies in organizations. When upper management delegates decision-making responsibilities, there also exist wider spans of control creating a more lateral flow of information. Thus there will be more bottom up directional information flow, allowing for more innovation and efficiency closer to the means of production. This increased flow of information thereby allows for innovation. Decentralization helps in breaking the chain of escalations and time lag that impacts the value delivery. But one must always understand that everything cannot be decentralized, there are few decisions which are still handled by the management. Decentralizing decision-making reduces delays, improves product development flow and throughput, and facilitates faster feedback and more innovative solutions.
The SAFe 4.5 Large Solution SAFe defines the following item types:
Solution Epic: Solution Epics are initiatives that are large enough to deserve analysis and a Lean Business Case but are reserved to a single Solution (Value Stream).
Capability: Capabilities are similar to features, but account for higher-level behaviors of the solution. They often span multiple Agile Release Trains (ARTs). They are maintained in the value stream backlog and are sized to fit in a Program Increment (PI), so that each PI delivers solution value.
Learning Milestone: Learning milestones mark specific progress points on the timeline and can be invaluable in measuring and monitoring the progress and risk of a program.
PI Objective: Describes a specific goal with planned and assessed business value for Capabilities, Features or Stories delivered in a specified Program Increment or Iteration. The PI Objective can be at the program, team, or value stream level.
Task: Defines a unit of work planned for a program increment and is estimated in hours.
Defect: Defines a bug, error, or flaw in the solution.
Risk: A risk is a potential event or future situation that could affect, prevent, or limit a project's success. Project risks might be seen as threats or opportunities.
Retrospective: A Retrospective is an event to discuss what went well and what did not go well, and to define improvement for the upcoming period. Use a Retrospective work item type to ensure that this event occurs and to track the team's comments and plans.
The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources. A lean organization understands customer value and focuses its key processes to continuously increase it. The ultimate goal is to provide perfect value to the customer through a perfect value creation process that has zero waste.
To accomplish this, lean thinking changes the focus of management from optimizing separate technologies, assets, and vertical departments to optimizing the flow of products and services through entire value streams that flow horizontally across technologies, assets, and departments to customers.
Eliminating waste along entire value streams, instead of at isolated points, creates processes that need less human effort, less space, less capital, and less time to make products and services at far less costs and with much fewer defects, compared with traditional business systems. Companies are able to respond to changing customer desires with high variety, high quality, low cost, and with very fast throughput times. Also, information management becomes much simpler and more accurate.
Devops in a scaling environment is defined as automation driven environment for the establishment of Devops culture and choosing of appropriate tools. Significant features to Devops in a scaling environment:
Culture - Devops culture is all about shared responsibilities which means a shift toward communication and collaboration across development, IT/ops and the business. It does not majorly focus intently on the tools but also how the team can work together for a great result.
Tools - Devops tools plays an important role to achieve great result and good use of Devops tools bring efficiency and productivity. The DevOps model relies on effective tooling to help teams rapidly and reliably deploy. These tools automate manual tasks, help teams manage complex environments at scale, and keep engineers in control of the high velocity that is enabled by DevOps.
Automation - Automation is the backbone of Devops strategy. It helps to reduce the manual effort and speed up the processes to release the software continuously. It is the process of scripting environments — from installing an operating system, to installing and configuring servers on instances, to configuring how the instances and software communicate with one another, and much more.
Communication and Collaboration - The success of DevOps automation hinges on effective communication and collaboration. Strong communication between team members is vital if those common goals are going to stay relevant for all parties going forward and embracing true collaboration in the workplace can drive positive change in how people work together.
Release on Demand is the final element of the Continuous Delivery Pipeline. It is the method through which features deployed into production are released incrementally or immediately to Customers as per market demand. It is the last element in the four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD) and Release on Demand, as can be seen in Figure.
Continuous delivery is deploying software product incrementally with new features as continuously and frequently as needed. It consists of processes and workflows that reduce cost and improve speed, quality and reliability of the software product.
The course of Continuous Delivery is started by the consent of an Epic. The stakeholders track the progress by using the Program Kanban Board where progress of features can be tracked from team level to business level.
Once the consent is made, the Epic goes through four stages of Continuous Delivery.
Continuous Exploration – The Product Management does the exploration on the epic to get its maximum benefits. This exploration is done amongst customers, key stakeholders, agile teams, business owners. Once the value is obtained, it is broken down into its artifacts. The Program Backlog is made.
Continuous Integration – The features from the backlog are taken and then executed. They are developed, tested, integrated, and validated.
Continuous Deployment – Once the features are made, they are deployed. Automated Testing of features and non-functional requirements is done.
Release on Demand – The software is ready to be deployed on demand. They are released as soon as they become available and whenever it is needed.
In Scaled agile framework, the teams are focused on delivery, and to do that job they are endowed in many ways, They can take their own decisions on what is to be committed, how it is to be developed, the testing pattern and scope but there still remains a need for management outside of the ARTs to provide for aspects such as pastoral care, risks and issues management, and for building capacity and capability in the teams. The development manager can look into the areas which can enhance the competence of the team, making them much stronger and focused on delivery. Great development managers are team builders, and that starts with hiring, they drive the hiring process and are well positioned to do so. Searching for candidates takes focus away from building great products hence the development manager can be of much help in removing such distractions.
Development managers also serve as accomplice and advisor because they are skilled at the essentials of management: one-on-one meetings, giving feedback, and coaching. Successful development managers mentor engineers to bring greatness to the table: ideas, code, tests, and culture. Even when an organization is using SCRUM as its development process, there are still supervisory and departmental tasks that need to be performed outside that process such as HR issues, performance reviews, upward reporting, etc. SCRUM doesn't touch on any of these day-to-day tasks that development managers still need to be in place to take care of.
Scaled Agile Framework is based on Agile Architecture which applies to all the levels in SAFe. It has few set of principles which helps to maintain the overall strength of the process/model:
Agile architecture allows incremental value delivery by harmonizing emergent design and intended architecture:
“By balancing emergent design and intentionality, Agile architecture is a Lean-Agile approach to addressing the complexity of building enterprise Solutions. In turn, this approach supports the needs of current users while simultaneously evolving the system to meet near-term future needs. Used together, emergent design and intentionality continuously build and extend the Architectural Runway that provides the technical foundation for future development of business value.” – scaledagileframework.com
While we talk about the scaled agile framework and its implementation, metrics can give you the required evidence to track your way and approach to the necessary destination. They are the tools to track the progress of how well your teams are doing and what all measures can be taken to improve it further on the scale. With the help of metrics, the organizations can review how the different levels in scaling are performing. As the enterprise grows from projects to portfolios, it is vital to not be limited to team agility but to strive for business agility. A program's business metrics should be rooted in its roadmap.
Specifically, talking about Scaled agile, metrics are used to measure the progress of an organization in terms of different aspects, such as – Portfolio, Large Solution, Program and Team. Metrics at each level in SAFe helps the enterprise to maintain the progress at the each level e.g. The Epic Burn-Up Chart at the Portfolio level tracks the progress towards completion of the epic. Each level has their own set of metrics, which helps around predictability, accessing the progress report, self-assessment at individual levels etc. But we have to make sure that the metrics are not implemented just for the purpose of doing it but it is necessary to adopt some metrics for your agile teams that suit your needs.
The Essential SAFe configuration is the most elementary configuration of Scaled Agile Framework. It is the initial level for organizations opting to implement SAFe, at this level of SAFe, it consists of the most critical elements needed to recognize the majority of the framework’s benefits. At Essential SAFe level, it mainly comprises of the Team and Program levels, and Foundation. Essential SAFe is a great first step to improving scaled delivery if your organization has not tried it at all. It keeps in the framework of Lean-Agile Principles, Lean Agile Leaders and the basic components on building and releasing Agile Release Trains (ART) as the chief method of delivery for organizations at the program level. Talking about the Portfolio Level, this is where strategic themes are planned. In any Lean Agile Enterprise, these strategic themes set the tone for developing and achieving the objectives in fulfilling all the requirements necessary for a Value Stream. Thereby creating a solution. It contains the people and processes necessary to build systems and solutions that the Enterprise needs to meet its strategic objectives. Once, the organization has successfully implemented the Essential SAFe, it can opt for Portfolio level and thus scaling it further.
“A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems.” – ScaledAgileFramework.com
At the PI planning event, each day there is a set agenda which spans across 2.5 or 3 days, which is divided into Business Context, Product/Solution Vision, Architecture vision and development practices, Planning context and lunch and Team Breakouts. During this process, teams identify risks and dependencies and draft their initial team PI objectives.
There is a Draft plan review session which is the tightly timeboxed draft plan review, teams present main planning yields, including draft objectives, potential risks, and dependencies. Business Owners, Product Management, and other teams and stakeholders review and provide input.
At the Final plan review and lunch session, all teams display their plans to the group. At the end of each team’s time slot, the team states their risks and impediments, but there is no attempt to resolve them in this short timebox.
And lastly, Confidence vote is taken, once program risks have been addressed, teams vote on their confidence in meeting their program PI objectives.
Teams leave the PI planning event with a prefilled iteration backlog. They take their team’s PI objectives, iteration plans, and risks back to their regular work area. Program risks remain with the RTE, who ensures that the people responsible for owning or mitigating a risk have captured the information and are actively managing the risk.
(As per ScaledAgileFramework.com)
The scaled agile framework has been evolving since the time it has been introduced, with the launch of the new version SAFe 4.5, lets dive into the framework and see what all new changes have been introduced.
SAFe 4.5 can be shaped to match your organization’s necessities. This new version allows enterprises to:
The key areas of improvements in SAFe 4.5 are as follows:
They’ve renamed the old SAFe 4.0 Value Stream Level to ‘Large Solution Level’. In doing so there are name changes, so Value Stream Epics becomes Solution Epics and a Value Steam Engineer now becomes Solution Train Engineer!
They’ve dressed up their piece a little bit. Now you get four essence depending on how determined your organization is in scaling:
Agile practices are a group of behaviors and techniques that use an empirical approach to deliver as much business value as possible in a given amount of time. They use iterations followed by inspect-and-adapt points to accommodate emerging requirements. It is a broad term that covers a number of different methods. It was created by a group of people who represented the methods that existed at the time (Scrum, Extreme Programming, Feature Driven Development, Crystal, etc.) Prior to the creation of the manifesto they were referred to as “Lightweight Methods.” Agile, in fact, is a way of thinking.
On the contrary, SAFe is an acronym for the Scaled Agile Framework, which is a branded version of a scaling model. Other scaling models include Large Scale Scrum (LeSS) and Scrum@Scale. Scaling models add extra layers of communication and controls to allow people to use agile methods (like Scrum) with very large groups. It is an attempt to take Scrum/ Kanban/ ScrumXp and make it work in large organizations with lots of teams working on the same product. SAFe defines an approach for scaling lightweight methods to an enterprise level and dealing with some of the challenges at that level that a team-level process based on Scrum does not address.
Among the other roles in scaled agile framework, there is a role called Release Train Engineer (RTE), this role revolves around servant leadership and coaching for the Agile Release Train (ART). The RTE facilitates value stream processes and execution, escalates impediments, manages risk, and helps ensure value delivery and continuous improvement. The key responsibilities include – People, Program Increment, ART Success Indicators, Improvement Roadmap and Coaching & Education.
The Release Train Engineer is the Chief Scrum Master who facilitates program-level processes and program execution, escalates impediments, manages risk, and helps drive program-level continuous improvement. RTEs are responsible for facilitating program events such as Release Planning, the Inspect & Adapt Workshops, and the Scrum of Scrums. During retrospective sessions, the Release Train Engineer reports to the Product Owner. Usually, the RTE reports to the Agile Program Management office which in SAFe, is considered a part of the Lean Portfolio Management (LPM). Many also participate in the Lean-Agile transformation, coaching leaders, teams, and Scrum Masters in the new processes and mindsets. They help configure SAFe to the organization’s needs, standardizing and documenting practices. The RTE performs a lot of activities but there are few which actually helps the teams at all levels such as - assisting with economic decision-making by facilitating feature and capability estimation by teams and the roll-up to Epics, wherever necessary, Improve the flow of value through value streams using the Continuous Delivery Pipeline and DevOps, etc.
The term “Portfolio Kanban” is often used to describe the process of managing portfolios of projects and business services using a hierarchy of Kanban boards, to track services at different levels with ease. The hierarchical Kanban boards, each with their appropriate stakeholders, help to visually track status, with easy cues and early signals, providing the relevant level of detail in near real time. It provides an at-a-glance grid view of the portfolio items in a project. Epic Owners are accountable for managing portfolio Epics through the Portfolio Kanban system. They define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved, facilitate implementation. If an epic is recognized as the potential delivery item, the Epic Owner works directly with the Agile Release Train (ART) and Solution Train stakeholders to outline the Features and Capabilities that recognize the value. They may also have some responsibility for supporting the initiative as it moves downstream through the Continuous Delivery Pipeline to Release on Demand. Typically, an Epic Owner works with the one or two epics at a time that falls within their area of expertise and current business mission. The only way an Epic Owner is effective is through close collaboration with other entities in the organization.
Customers are the end user or eventual consumer of every Solution. Being an important part of Lean-Agile development, they contribute through few specific responsibilities in SAFe. It’s a worldwide known fact that the customers are difficult. They anticipate solutions to work well and to resolve their present requirements. They also expect their solution providers to continuously improve the quality of their products and services.
The Customer is a part of the Value Stream and can be external or internal. Internal customers are within the organizations requesting to create internal apps such as Intranet, HR services or admin portal.
Where as a Business Owner is a role defined to represent management outside the Team. In practice the Business Owner is either the ‘lead’ Stakeholder, the Team’s Sponsor, or the Product Owner’s Product Owner. “Business Owners are a small set of stakeholders who have the principal business and technical accountability for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART). They are key stakeholders on the ART who must evaluate fitness for use and actively participate in certain ART events.” – ScaledAgileframework.com
The SAFe house of Lean has been derived from Lean Manufacturing originally, it has four pillars, a foundation and the Goal. The goal of Lean is to deliver the maximum customer value in the shortest sustainable lead time while providing the highest possible quality to Customers and society as a whole.
Below figure explains the Goal, Pillars, and Foundation of "SAFe House of Lean."
Pillar 1 – Respect for People and Culture – There are approaches which cannot be implemented without human intervention and same applies to Lean-Agile. Hence, Respect for people and culture becomes the basic necessity. The driving force behind this behavior is the culture and it requires the enterprise and its leaders to change first.
Pillar 2 – Flow – Success of the SAFe implementation lies on establishing a continuous flow of work that backs incremental value delivery, based on continuous feedback and fine-tuning.
Pillar 3 – Innovation - Flow creates a concrete groundwork for value delivery. But without innovation, both product and process will gradually deteriorate. For this reason Innovation has been given a lot importance.
Pillar 4 – Relentless Improvement – As with the other three pillars, this one too holds a great value, it inspires new learning and evolution through constant reflection and process improvements.
First, it is important to understand about what exactly is a core value, it is a principle that guides an organization's internal behavior as well as its association with the outer world. Core values are usually summarized in the mission statement or in a statement of core values. Scaled Agile Framework is based on both Lean and Agile principles. SAFe supports four Core Values: alignment, built-in quality, transparency, and program execution, as illustrated in Figure below:
These core values make sure that the SAFe is implemented with the true intension and the organization abides by the values which form an encapsulation around the implementation. The values are the roots which makes sure the tree is getting the right nourishment. Alignment is required to keep pace with fast change, disorderly competitive forces, and geographically distributed teams. Built-in Quality ensures that every increment of the solution reflects quality standards. The importance of transparency in Agile cannot be overstated. Over the long-run, the lack of transparency can upset the team, the project, and the organization. Without transparency, nothing is going to good. SAFe provides a strong attention on working systems and business outcomes, hence, program execution is the fourth value that SAFe holds.
The Iteration Review is a cadence-based event, where each team inspects the increment at the end of every Iteration to assess progress, and then adjusts its backlog for the next iteration – ScaledAgileFramework.com
Iteration Review has the potential to be a great source of learning and feedback for all involved. Agile teams embrace the notion of inspect-and-adapt as a means to continually build learning and improvement in how they work. The goal of the meeting is to create visibility around what occurred in the course of the iteration and to amplify learning about what could then be planned for the next iteration. The delivery team presents the done items in a demonstration. Done items are all items that have been accepted by the product owner. The demonstration invites clarification, reflection, and celebration with regard to the team's commitment. At the end of a good meeting, all attendees have a clear understanding of the completed iteration as well as a good sense of the value that was delivered. The iteration review starts by going over the Iteration Goals and talking over their status. It then continues with a walk-through of all the committed stories. Each accomplished story is demoed. The Iteration review is followed by the Iteration Retrospective.
Value stream mapping is a technique used to document, analyze and improve the flow of information or materials required to produce a product or service for a customer. A value stream map is usually formed as a one-page flow chart portraying the current production track or design path of a product from the customer's request to delivery. An important objective of value stream mapping is to identify processes that do not provide value so they can be improved. In lean production, value can be believed of as something the customer is prepared to pay for. Processes that do not deliver value are called waste. Value stream maps document the current state of the value stream as well as the future state of the value stream and define any gaps between the two.
Value stream mapping is often used to ascertain processes that could be streamlined and areas of waste that could be eradicated in keeping with Toyota's kaizen philosophy. The philosophy, which highlights continuous improvement, has been adopted by many other industries outside manufacturing including healthcare and software development.
An important aspect of Agile is continuous improvement. For ones on the Agile scrum teams this improvement can only be attained in an environment that allows for and endorses continuous learning. The Innovation and Planning sprint offers just this occasion for scrum team members as it gives a structured break in the development cycle to re-evaluate the team’s current skills with those needed in the sprints ahead.
SAFe provides for periodic Innovation and Planning sprints, which serve a variety of purposes, including: providing an estimating buffer for meeting objectives; a dedicated time for Inspect and Adapt and Release Planning activities; a cadence-based opportunity for innovation; time for continuing education; time for working on the technical infrastructure, tooling, and any other impediments; and time for backlog refinement.
As per ScaledAgiledFramework.com:
“Innovation and planning iterations provide a regular, cadence-based opportunity, every PI, for teams to work on activities that are difficult to fit into a continuous, incremental value delivery pattern. These may include:
Final user acceptance testing and documentation, and any other readiness activities that are not feasible or economical to perform at every iteration”