Scaled Agile

It's no surprise that this one pops up often in interview questions on Scaled Agile framework.

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 a few areas that 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 responses 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:

• Developing testing platforms and frameworks that serve the teams that make up the agile release train, not just individual features or components
• Creating and running automated tests to enable continuous integration and continuous deployment
• Designing and performing end-to-end tests, exploratory testing, performance testing, and so on—this might be the only team with visibility across the whole product
• Maintaining service and network virtualization systems that let teams test and develop independently of one another
• Reviewing and testing cross-system concerns such as single sign-on, open source usage, common security requirements, and regulatory standards

One of the most frequently posed interview questions on Scaled Agile framework, be ready for it.

Scrum is being widely used at the Team Level, even in the last year’s report from the Standish Group, more than 68% of organizations 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:

• Visualize what you do today (workflow): seeing all the items in the context of each other can be very informative
• Limit the amount of work in progress (WIP): this helps balance the flow-based approach so teams don’t start and commit to too much work at once
• Enhance flow: when something is finished, the next highest thing from the backlog is pulled into play
• Kanban promotes continuous collaboration and encourages active, ongoing learning and improvement by defining the best possible team workflow.

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.

 Are there any reasons that Scrumban would not work with SAFe? 

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

A staple in Scaled Agile interview questions, be prepared to answer this one.  

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.

This question is a regular feature in SAFe Agile interview questions and answers, be ready to tackle it.  

Yes. The Customer is a part of the Value Stream. Talking about Lean-Agile framework, the customer is an important entity.  There are two types of customers – Internal and External. Internal customers 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 that the Customer has to fulfill (as per ScaledAgileFramework.com):

• Participate as a Business Owner in PI Planning.
• Attend the Solution Demo and possibly System Demos; help evaluate the solution increment. 
• Participate in Inspect and Adapt workshops; assist in removing some systemic impediments.
• Interact with analysts and subject matter experts during specification workshops.
• Collaboratively manage scope, time, and other constraints with Product and Solution Management. 
• Help define the Roadmap, Milestones, and Releases.
• Communicate the economic logic behind the solution and help validate assumptions in the Economic Framework.
• Review the technical and financial status of the solution.
• Participate in beta testing, User Acceptance Testing (UAT), and other forms of solution validation.

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.

This is a frequently asked question in Scaled Agile interview questions.  

Solution train constructs complex solutions 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 toward 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.

• Solution Train Engineer supervises the solution Kanban. They make sure the smooth running of the train and manage the delivery of the solution with the Release Train Engineers.
• Solution Management expresses the customer’s needs to the Agile Release Trains. With the help of the product management, the Strategic themes are used to define capabilities and split into features.
• Solution Architect defines the technological design that links the solution across all the Agile Release Trains.
• Release Management governs the Solution Train. They have the power to approve releases. They regularly assess content, advancement and the scope of the solution. It is a set up of representatives from the solution train, agile release trains, marketing team, quality assurance team, Lean Project Management, operations, deployment and distribution.
• System team addresses the regular integration of the system across the Agile Release Trains.
• A supplier is an external or internal organization that helps the solution train in the delivery of the solution. They help in providing subsystems or components. Assurance to be delivered in the shortest amount of time to the customer is of dire importance. A supplier works in the same cadence as the Agile Release Train and participates in the PI Planning.
• The customer is the owner of the final solution. They are part of the value stream and work with the solution and product management.
• Shared Services are required whenever their help is needed. They are not full time members of the Agile Release Train. Shared services include data security, information architects and database administrators.

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

A must-know for anyone heading into a Scaled Agile interview, this question is frequently asked in interview questions on SAFe Agile.

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:

• It starts with strategy and investment decisions at the Portfolio, is reflected in Strategic Themes and the Portfolio Backlog. In turn, this informs the Vision, Roadmap, and backlogs at all levels of SAFe. Continuous Exploration gathers the inputs and perspectives from a diverse group of stakeholders and information sources to ensure that the items in the backlogs contain economically prioritized and refined work ready for teams to implement. All work is visible, debated, resolved, and transparent.
• It is supported by clear lines of content authority, starting with the portfolio and then resting primarily with the Product and Solution Management roles and extending to the Product Owner role.
• PI Objectives and Iteration Goals are used to communicate expectations and commitments.
• Cadence and synchronization are applied to ensure that things stay in alignment, or that they drift only within reasonable economic and time boundaries.”

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.

A common question in Scaled Agile framework interview questions, don't miss this one.  

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 on increasing it continuously. 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 lower costs and with much fewer defects compared with traditional business systems. Companies are able to respond to changing customer desires with wide variety, high quality, low cost, and with speedy throughput times. Also, information management has become 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.