Auditing Agile Scrum Project

Why Audit Agile Scrum Projects?

  • Effective Audit helps uncover problems and ensure efficiency.
  • Ensuring effective quality delivery of the project.
  • Ensure best practices adherence.
  • To perform a “due diligence” review for all impacted Stakeholders.
  • Unearth Problem areas proactively and work on solution/improvement
  • Provides objective insights and Evaluates Risks
  • Allows to Get Rid of Inefficient Processes
  • Assessment of gaps that lead to corrective and preventive measures
  • Continuous improvement across all teams in the enterprise
  • Process consistency across all teams in the organisation

We are Agile !!! This is something every organisation / team these days claims to be. But the question is how effectively Agile processes are inherited by the organisation. Are they truly working in the spirit of Agile? 

To measure the effectiveness of an Agile Scrum Project, Agile Scrum Audit Process comes in handy. We follow 3 phase approach.

  • Phase 1:  Planning the Agile Project Audit Plan
  • Phase 2:  Agile Project Analysis (Interviews, Artefact Reviews, Fieldwork)
  • Phase 3:  Report and Recommendations

Phase 1:  Planning the Agile Project Audit

In this phase Auditor spends time to understand the current processes in place and plan for the analysis phase. Key elements include:

  • Interview the Product Owner and Scrum Master to determine what is their “success criteria” for this agile project. 
  • Identify the competencies of the Scrum Master and Sprint Team members.
  • Identify if Agile project management tools and templates exist to ensure a consistent application of agile quality processes.
  • Validate if the project is strategically aligned with business goals. That is backlog is mapped to the Vision
  • Schedule interviews with Scrum Master, Product Owner and other Scrum team members.
  • Have a discussion with any key stakeholders who will be impacted by the project.
  • Schedule to attend some of the Sprints, Demos and Retrospective meetings.

In the planning phase we came up with a set of questions that would be asked to the different stakeholders of the Project on the following 14 parameters. Intent is to see how team is performing in these different parameters of Agile Scrum process

  1. Sprint Backlog
  2. DOR
  3. DOD
  4. Sprint Grooming
  5. Daily Scrum
  6. Sprint Planning
  7. Retrospective
  8. Sprint Demo
  9. Time boxed iterations
  10. Velocity
  11. Burn down Chart
  12. Jira (Other Tools) Updates
  13. Impediments
  14. Scrum Master

Each of the parameter is then scored on the scale of 0 to 5 considering how closely parameter is met as follows:

  • Never – 0
  • Rarely – 1
  • Occasionally – 2
  • Often – 3
  • Very Often – 4
  • Always – 5

Phase 2:  Agile Project Analysis

During this phase the project auditor dives deep into the Agile project.  Key elements include:

  • Interview the Product Owner and Scrum Master.
  • Review the competencies of the Scrum Master and Scrum Team members.
  • Assess the issues, challenges and concerns in more depth to get to the root causes of any possible problems.
  • Be a silent observer of the Sprint.
  • Attend and Observe the daily Scrum stand-up meetings.
  • Participate in the Sprint Demos.
  • Attend and Observe the Sprint Review and Sprint Retrospective Meeting.
  • Review the backlog and how stories were broken down into these backlogs.
  • Determine how change and risk have been managed.
  • Review the Sprint Burn down chart and other artefacts.

Phase 3:  Reports and Recommendations

In this phase the project auditor reviews all of the data they’ve collected and creates the final report and recommendations.  Key elements include:

  • Compile the information collected from the interviews.
  • Consolidate the findings from the review of project artefacts.
  • Review the observations from the meetings.
  • Validate that the customer requirements are understood and being met.
  • Validate that the Sprint team members are being effectively and efficiently utilised.
  • Review the observed issues, concerns and challenges.
  • Identify the Short term and Long term recommendations. Short term recommendation will help immediate improvement of the project.
  • Finalise the the report with recommendations based on the findings and present this detailed Agile Project Audit Report with recommendations including the steps required to keep this project on-track.

Basis inputs Effectiveness Score is calculated for all the parameters as:


Our 3-phase Agile Project Audit will uncover the root causes of problems, issues and challenges that may be preventing an Agile project from succeeding.  Report will also provide “Lessons Learned” that can help improve the performance of current and future Agile projects. Agile Project Audits are always highly beneficial to an organisation and pay back the investment many times over.

Program Increment – Day 2

In my previous blog we saw how RTE sets the agenda for Program Increment session. It was more focused on setting up of business context by Leadership team. Sharing the Architecture vision by the System Architect, and Team getting into breakouts and preparing the Draft Plan followed by Management Review. Let us see how Day 2 looks like in the Program Increment Planning.

At the start of Day 2, RTE reviews the agenda and objectives and share the same with the participants as shown below:

This is the time when the program commits an action plan that fits the capacity of the team where they can deliver maximum business value. 

Planning Adjustments

After the previous day review with management and problem-solving meeting, adjustments are done with respective ARTs. It is the responsibility of the management review group to describe the issues and do planning adjustments that were concluded in the problem-solving meeting at the end of day 1.

Team Breakouts Continue

Basis feedback and inputs received from Management review team gets back to the breakout sessions to work on the following:

  • Adjust their draft plan and work on the final plan. 
  • Teams are expected to finalise their Sprint Plans and PI Objective during these sessions.
  • Teams as well try to establish stretch objectives
  • Business Owners help assign business value to PI objectives in the scale of 1 to 10 (1 being the lowest and 10 the highest)

The team has to ensure that their boards are updated with all the features, risks and cross-team dependencies so that all the stakeholders and participants are aware and accordingly prioritise their set of stories and dependencies.

Concluding Team PI Objectives

Team works towards Final PI objectives by the end of the session.  PI objectives are expressed in business terms. It is a brief summary indicating what teams committing for the upcoming PI. 

Use of Stretch Objectives

Stretch objective is the work that is planned but is not included as a commitment from the team. It is kept to identify work that can be variable within the scope of a PI. 

Reasons for categorising Objectives as Stretch Objectives?

  • It helps to have a stretch objective when the team has low confidence in its ability to meet a PI objective. As this is something not committed and takes away the burden from the team. That said, teams are always encouraged to achieve the same.
  • If the objective has many unknowns, the team should plan spikes early in the PI to reduce uncertainty. Such cases can be categorised as Stretch objective.

Team tries its best to achieve Stretch Objectives and as well are included in the capacity, but since they are not the committed ones, business stakeholders can plan accordingly and keep their side of stakeholders updated accordingly.

Establishing Business Value

Why there is a need to estimate Business Value? This is required to evaluate the progress of an ART. How do we evaluate if ART is a success or not? It is basis Business Value delivered by an ART. To measure each ART, all the PI Objectives need to be mapped to numeric value on a scale of 1 to 10 known as Business Value. To execute this, the Business Owners set the business value of each objective toward the end of the PI planning session as given below:

Note that not all PI objectives will deliver equal value. Business Owners will accordingly assign value to objectives. The one with externally visible will be assigned with a higher value as compared to infrastructure or architecture objectives that are not going to be visible outside.  

Team also uses these Business Values for making trade-off or scope adjustment to ensure they deliver the maximum value to the business.

Program Board

It is the responsibility of the RTE  to create a program board in advance of planning. The team then updates it during planning. This board gives visibility on the feature delivery dates, milestones, and dependencies among teams and with other ARTs as shown below:

Final Plan Review

Once the teams are done with their side of planning and discussions with other teams on dependencies and are ready with their PI Objectives, it is time for Final Review.

This is basically a repeat of the draft plan review session from the day before, but by now the teams will have completed their plans.

Each team is given 5-10 minutes to present their plan indicating the BV (business value) planned, risks and dependencies. After publishing its Objectives, each team states its remaining program risks and impediments. Risks and any impediments are addressed later. 

This is followed by a Q&A between ART and Business owners. The facilitator confirms with the Business Owners if the plan is acceptable to them. If the plan is acceptable, then there is a discussion on identified risks and impediments in front of everyone. This helps everyone to understand each other Objectives in real-time. This is done for each team.

Addressing Program Risks and Impediments

All the risks, dependencies, and impediments identified by the teams are discussed in an open forum in front of everyone one by one by each team. These are resolved in a broader management context in front of the whole train. One by one, the risks are addressed with honesty and transparency, and then categorised into one of the following categories:

  • Resolved – The teams agree that the issue is no longer a concern. 
  • Owned – Someone on the train takes ownership of the item since it cannot be resolved at the meeting. 
  • Accepted – Some risks are just facts or potential problems that must be understood and accepted. 
  • Mitigated – Teams can identify a plan to reduce the impact of an item. 

Confidence vote

Once the risks of all the teams have been addressed, teams vote on their confidence in meeting their program PI objectives. The teams vote using a ‘fist of five’. 1 being a low confidence and 5 fingers indicating very high confidence, as given below:

If the average of the vote is three or more fingers, management accepts the commitment. However, if the average is less than three, then it indicates the low confidence and indicate a problem with the plan finalised so far.  This indicates that some adjustments are needed in either Scope or Resourcing. In such a scenario, teams need to revisit the plan, make adjustments and it continues till the time confidence is achieved and the average confidence vote is between 3 to 5.

Planning retrospective and moving forward

Finally, the RTE leads a brief retrospective for the PI planning event to capture what went well, what didn’t, and what can be done better next time. This specific session gives further insights to RTE to make adjustments for the next PI session so as to be more effective. 

As seen in 2 days Agenda for the PI session, it is advent that no other even is as powerful in SAFe as PI Planning. This 2 days session holds the key to the success of any given ART. It brings everyone together to plan toward a common mission, vision, and shared purpose. 

The primary output of PI planning is a committed set of PI objectives that the teams will deliver over the course of the PI. This is supported by a program board, which maps the feature delivery dates, milestones, and dependencies that must be successfully navigated to develop and release value.

References: SAFe Distilled 4.5 and Scaled Agile Framework

Program Increment – Day 1

Effective execution of Program Increment is very essential to reap true benefits. In my previous blog, we have seen what Program Increment is all about and what are the main factors to be considered while planning a Program Increment. Let us see how effectively we can use 2 days.  In this blog we will see how do we execute Program Increment Day 1 in detail i.e. Agenda for Day 1. Over the years, SAFe have evolved standard agenda that is useful in most of the cases as depicted in the image below:

Day 1: Create and Review Draft Plans

Day 1 event begins with RTE or the facilitator reviewing the Objectives, agenda, planning rules and logistics. The facilitator makes sure expectations are set for all the participants and stakeholders attending the session. It is also essential for the facilitator to publish the upcoming calendar of events, future PI planning dates, and other milestones that may impact team capacity.

Setting up the Business Context 

Officially Day 1 starts with Senior executive providing the business context of the planning session. This discussion sets the tone for the PI planning session and also contributes to driving the motivation for the PI. Leadership representative get a chance to share success story (On how well existing solutions are helping meet the customers needs), current market risks and also through some light on SWOT analysis. This is the time when presenters provide an overview of the strategic themes and business objectives. 

Sharing Product/Solution Vision

After the address from the leadership team, Product management team present the current vision and objectives of the upcoming PI. It details out the feature priorities. Each Product Manager (if multiple) will get a chance to showcase features for their area of solution.

Sharing Architecture Vision and Development Practices

Product Vision is followed by Architecture vision where System Architect presents the vision for the architecture. This is a platform for Technical Leader to provide guidance about changes to standard development practices which may include new tools and techniques for DevOps and the CI/CD pipeline and Quality practices

Team Planning Breakouts

Once the business and technical agenda is set, Team Planning session takes place. This is the heart of the PI planning session and is the longest and most critical part of the 2 days session. Here, teams get into separate meetings and chalk out their initial plan and achievable objectives of the PI (based on the business and the technical vision). Teams during this time will as well consult with Product Managers, System Architect, UX Teams or any other team to get clarification and understand dependencies on each other.

The goal for the team is to understand the scope and also prioritise the features and understand any dependencies.  They as well need to understand the reuse of common code. Teams during this exercise use flipchart paper and stickies. Flipchart is used per iteration (Sprint) and also identify the dependencies, enables, and risks associated for all to see (see below)

During the process, team identify risks and dependencies and as an output outline the PI objective for the team (Objective also include stretch Objective).

Draft plan review

Once the teams are done with their respective planning, the entire ART gets back in the main session to review each others draft plan. Some of the team may not be done entirely with their plan, still review should be done so that everyone else can see the planning process and get insight to each others deliverable and understand cross dependencies. Each team is given 5-10 minutes depending upon the size of the ART

It is very essential for business owners to be present throughout the review sessions so that they can give live feedback. High level team talks about following:

  • Velocity (Capacity) and load
  • Draft PI Objectives
  • Program risks and impediments
  • Q&A

Capacity-Based Planning – If it’s the first PI planning session for any team, they may not have visibility of their team’s velocity. How should the plan their Velocity? In such a case, it is recommended to use eight pointers per iteration (sprint) for one FTE. The best way is to identify one story that will take one day of effort and estimate the same as 1 story point. Other stories are then estimated relative to that one story point.

If team is aware of their past velocity, it can be figured out it the planned velocity is achievable.

Hourly Planning Checkpoints During PI Session

At the time of team breakout, RTE conducts Scrums of Scrums to ensure planning is on track. In the short  stand up meeting, RTE and Scrum Masters from each team meet to review the planning status using a checklist as given below:

Management Review and Problem-Solving Meeting

It is expected that the draft plans represent certain challenges in scope, dependencies and resource constraints. During the problem-solving meeting, management may negotiate scope changes and resolve other problems by agreeing to various planning adjustments. The RTE facilitates and keeps the primary stakeholders together for as long as necessary to make the decisions needed to reach achievable objectives. 

Next we will see Day 2 Agenda and how to conclude effective PI Planning

References: SAFe Distilled 4.5 and Scaled Agile Framework

Program Increment and It’s Planning

SAFe is no Magic except for Program Increment Planning. No event is as powerful in SAFe as Program Increment Planning. PI planning sets the platform for cadence for ART. In this blog we will see how to prepare for an effective Program Increment Planning session. Next Blog we will cover Day wise activities during the PI session.

With large audience of 100 + people working together at the same time to achieve a common vision and mission, it is truly incredible how much energy this session creates. These two days sessions with synchronised efforts saves months of delays

What is PI – Program Increment

A Program Increment (PI) is a time-box during which ART delivers incremental business value in the form of the working, tested system. PI is followed by Innovation and Planning Iteration and is typically 8 to 12 weeks long. The way iteration is to the Agile team, PI is to an ART. 

What is PI Planning?

PI planning is an important milestone for each ART implementation. Teams come together during this session to define and design the system that best fulfils the ART’s vision. Teams commit to the objectives for upcoming quarter with all the stakeholders part of this cadence. This helps in a sense of cooperation and collaboration within cross-functional teams and sets the base for the entire ART. 

PI planning is recommended face-to-face at a single location, or in some cases, multiple face-to-face locations simultaneously. For example, teams in the United States get into planning at the same time as remote teams in India using video conferencing. Seating arrangements shall be considered taking into account the visibility of key stakeholders like business owners to everyone. Product owners shall be closely seated with their respective teams. As a best practice, all the ART members should attend the PI Planning session so that they have the visibility of end to end goals to be achieved.

During the PI planning team estimates what will be delivered and also highlight what are their dependencies with other Agile Teams and Trains. 

How to prepare for PI Planning:

Conducting PI Planning requires effective preparation, coordination, and communication. For making this cadence effective, all the stakeholders must be well prepared. We can distribute the readiness in 3 major areas:

  • Organisational readiness
  • Facility readiness
  • Content readiness

Let us review each one of them one by one

Organizational readiness

Before the planning session, it is critical to have a strategic alignment between the participants and Business owners. Each one of them should understand what they are going to build and should be aware of:

  • Planning scope and context – Does the teams understand the scope of the product, system, and technology?
  • Business alignment – Are all the stakeholders aligned? Is there reasonable agreement on priorities among the Business Owners?
  • Agile Teams – Does each team has dedicated developer and test resources and an identified Scrum Master and Product Owner?

Facility Readiness

The availability of the physical space, the technical infrastructure is equally important. 

  • The planning venue should be large enough to accommodate all attendees. 
  • It is like organising the big event so support teams should as well be identified and be available at all times during setup and session.
  • Since the room is going to be large, adequate audio, video conference for remote users and presentation channels must be available.

Content Readiness

All participants need to be aware of the goals to be achieved. For this, the leadership team should provide a clear vision and context. Following factors shall be considered in the presentation:

  • Executive briefing – A senior executive or line-of-business owner to presents the current business context.
  • Product/solution vision briefing – Product Management to presents the vision, highlighting the ‘top 10 features’ in the program backlog.
  • The architecture vision briefing – This is prepared by the CTO, Enterprise Architect, and/or System Architect/Engineer, this briefing communicates architectural strategy

Role of the Facilitator

PI planning sets the platform for ART. It’s where all teams are expected to come to a consensus of what they will be achieving in the upcoming quarter. With all the stakeholders involved, a highly charged session is on the cards. Stakeholders can very well see what they are asking and what teams can achieve.

Expectations are going to be on the higher side with expectations of achieving maximum business value. This sometimes can lead to overloading the ARTs. It becomes very critical to ensure excess work is moved out of the system. Getting expectations aligned with reality can be a daunting task, therefore it is very essential that someone takes the responsibility of keeping everyone aligned and ensure that the group meets its planning objectives and at the same time have buy-in from everyone. RTE – Release Train Engineer can own this responsibility or delegate so that he can get time to focus on the teams. 

Inputs and Outputs of PI Planning

Inputs to PI Planning:

  • Business context
  • Road map and Vision
  • Top 10 features of Program backlog

Outputs of PI planning:

  • Committed PI Objectives
  • Program Board

In next blog we will see best practices followed during the PI planning session to effectively achieve the desired output

References: SAFe Distilled 4.5 and Scaled Agile Framework

Agile Release Trains – ART – Organisation and Roles

Agile Release Trains are the heart of Essential SAFe in the similar way Essential SAFe configuration is the heart of the Framework. It is the simplest starting point for implementation. In this blog, we are going to talk about Agile Release Trains (ART). We will see how Agile Release Trains in itself is an organisation and also see important roles within ART. It describes the most critical elements needed to accomplish the majority of the Framework’s benefits.

We discussed about roles and critical elements of Essential SAFe configuration in my previous blogs SAFe Birds Eye View and Essential SAFe – “Implementation Starting Point”

What is ART – Agile Release Train:

The Agile Release Train (ART) is a combination of multiple Agile Teams which in conjunction with other stakeholders work on developing solutions incrementally by working on fixed-length iterations (sprints) within a Program Increment i.e PI.  It is a virtual organization that consists of all the cross-functional roles and skills required for product development. The one goal each ART works towards is to achieve and maximise the value defined. This cross-functional ART have all the capabilities of developers, testers, UI, UX, architects, and DevOps. 


Principles in ART –

The end goal for each ART is achieving the value from a common Program Backlog. Each ART has a set of common principles such as:

  • Fixed Schedule – Typically 12 weeks i.e three months or 6 Sprints of 2 weeks each. It follows the same PI length of three months. Demo within ART happens on the same day. Start dates and End Dates of sprints are same within ART.
  • Major advantage of ART concept is that one can predict and estimate the features an ART team can deliver in a particular PI.
  • Members of ART are dedicated full time on the train
  • Work in ART is planned through face to face event called PI Planning
  • Each ART has dedicated time for Innovation and Planning. It keeps specific time buffer for Training, continuous learning, and Innovation. 
  • Inspect and Adapt sessions – Like retrospective in Scrum,  I&A sessions are conducted within ART at the end of every PI sessions. The current state is demonstrated to Stakeholders and feedback is taken to keep the train on track.
  • ART leverages DevOps to deliver value with automated continuous delivery pipeline. ART uses Lean UX to get timely feedback
  • Develop on Cadence and Release on Demand – ART works on scheduled cadence which helps different ART teams in synchronisation. The release is separated from Development cadence. We can release a solution anytime based on demand and release criteria.

Traditionally, organisation used to work in silos. There were major challenges in the flow of value and handoffs. This resulted in delay, communication gaps and late feedback which lead to dissatisfied customers and often missing the deadlines. 



ART as a virtual organisation consists of all the people with the required skill sets to deliver the value. It breaks down the functional silos and each member from the different functions are part of the ART team.

Agile teams within each ART are in themselves cross functional teams:

Each Agile team is equipped with the skills and people required in different domains such as UX, Developers, Testers, etc. so that it can effectively deliver the value and have minimum dependencies. It has everything it requires to deliver the value.

Roles in ART:

Three important key players in ART are:

  • Release Train Engineer (RTE) – The RTE is a servant leader and the chief Scrum Master for the ART. The person filling this role helps improve the flow of value in the program.
  • Product Management –  Product Management bridges the gap between customers  and internal stakeholders. They work with Product Owners and Customers to define features. They are the ones responsible for Program level backlog and prioritisation of the same. 
  • System Architect/Engineer – This is the one role that applies systems thinking and therefore, system architects are the members who define the overall architecture of the system. They help identify new nonfunctional requirements (NFRs) and help determine the critical components and subsystems.

Apart from the above three, following roles also play an integral part of ART:

Additional Roles that support ART

  • Business Owners –  Business Owners are a group of stakeholders who have the responsibility of ROI. They are key stakeholders who must actively participate in certain ART events.
  • Customer – Customers are the ultimate deciders of value and are an integral part of the Lean-Agile development process and value stream. They have specific responsibilities in SAFe.
  • A System Team i.e DevOps assists in creating and stabilizing the development environment. It extends support in continuous integration, test automation, and continuous deployment. They help integrate deliverables from Agile teams, often perform end-to-end solution testing, and assist with deployment and release.
  • Shared Services are the SME’s or specialists who cannot devote themselves full-time to a single train. Few of the examples of the shared services are data security professionals, information architects, database administrators, and technical writers.

As stated above, ART is a combination of Agile Teams. Thereby meaning it consists of multiple Agile Teams which have dedicated individuals with the required skill sets who works towards achieving the goal or value in iterations known as Sprints. Each Agile team estimate their own work, determine the technical design, Implement, test and deploy.

Each Agile team within ART have three critical Roles of Scrum. Those are Scrum Master, Product Owner and the Dev Team.

References: SAFe Distilled 4.5 and Scaled Agile Framework

Essential SAFe – “Implementation Starting Point”

In one of my initial blogs, we touch based on the 4 configuration that SAFe provides. These configurations can fit from small organisations to large enterprises. It is flexible enough for organisations to leverage to their specific needs. In this specific blog and the following blogs, we would deep dive into Essential SAFe. It is the starting point for SAFe implementation in the organisation. 

Essential SAFe is the root of the SAFe framework and serves as the foundation for other configurations. My earlier blog SAFe Birds Eye View talks about Roles associated in this configuration.

Essential SAFe configuration covers the most fundamental elements of the framework.

10 Fundamental Elements:

The following 10 important elements of Essential SAFe are applied to all SAFe configurations.  These elements are critical for successful Agile development. If an organisation effectively leverage these 10 critical elements, they can unearth the full potential of SAFe.

The Ten Essential Elements in Essential SAFe:

  1. Lean-Agile Principles – In order to stay onto the correct path, organisations should ensure following the Nine essential principles that guide teams to make sure that they are heading in the right direction following the basic fundamentals 
  2. Real Agile Teams and Trains – These cross functional Agile teams and trains ensures teams have all the skill sets to develop a working, tested piece of the solution. These teams are fully cross-functional and self- organising.
  3. Cadence and Synchronisation – Cadence helps providing platform to different SAFe and Scrum ceremonies that are important for any development process. ART (Agile Release Trains) team get clarity in roles and objectives through these cadence. Cadence ensures different ceremonies at team or program levels are held at a scheduled time. It helps all stakeholders to collaborate and understand different perspectives.
  4. Program Increment (PI) Planning –  If Essential SAFe is the heartbeat of entire SAFe framework, Program Increment i.e PI Planning is the heartbeat of Essential SAFe. There is no event as powerful in SAFe as PI planning. This event serves as the heartbeat for the ART, aligning all the teams on the ART to a shared mission and vision.
  5. System Demo – How do we measure the work done during a Sprint iteration or PI iteration? The basic measurement is through working solution. Every two weeks, working solution is presented to different stakeholders in the form of Demo. This is the primary measure of the ART’s progress. Every two weeks, work of all teams on the train for that iteration is demonstrated to stakeholders. Based on Demo, stakeholders then provide the feedback so that the train is on course and can take corrective action.
  6. Inspect and Adapt (I&A) –  The way we have Retrospective sessions in Scrum, the I&A session is conducted at the end of every PI. This is a dedicated session to look through the solution and identify the things that went well, what are the improvement areas and action items to keep the train on the right track. It’s a scheduled opportunity to define the improvements needed to increase the velocity, quality, and reliability of the next PI.
  7. Innovation and Planning (IP) Iteration –  The IP iteration occurs at least once every PI and help in multiple ways. It serves as an estimating buffer for meeting PI objectives and dedicates time for innovation, continuing learning, and PI planning and I&A events. 
  8. Architectural Runway –  Architectural Runway helps in the continuous flow of value through the Continuous Delivery Pipeline. It provides the necessary technical foundation for developing new Features. The architectural runway is the primary tool used to implement the Framework’s Agile Architecture strategy. 
  9. Lean-Agile Leadership – As in the words of Deming It’s not enough that management commit themselves to quality and productivity, they must know what it is they must do. Such a responsibility cannot be delegated.” For SAFe to be effective the organisations leadership must take responsibility for Lean-Agile adoption and success. Therefore, transformation can only be done when leaders are actively participating and taking responsibility for the implementation.
  10. DevOps and Releasability – For organisations to bridge the gap between development and operations SAFe’s recommends ‘CALMeR’ approach to DevOps. It provides the culture, automation, Lean-flow, measurement, and recovery capabilities. Releasability focuses on the business’s capacity to deliver value to its customers more often and according to market demand. 

As stated earlier, Essential SAFe is the heart of the Framework and is the starting point for implementation. Let us see what is in the core of Essential SAFe i.e. Highlights of ART

ART – Core Of Essential SAFe:

  • The ART helps in alignment of all the stakeholders. It helps clarifying vision and road map to teams, management, customers. 
  • ARTs helps in delivery of the features i.e. user functionality and the enablers i.e.  technical infrastructure that are needed to deliver value.
  • All the teams follow the same iterations i.e. same start dates and end dates of the Sprints
  • Every ART delivers testable solution at the end of two weeks and is demonstrated to all the stakeholders on a common platform. 
  • Program Increments (PIs) provide longer, fixed time boxes for planning, execution, and inspecting and adapting. Normally, one PI is for 6 Sprints i.e three months with 2 week sprint cycle.
  • PI is done face to face and remote users are encouraged to join through a live video conference to ensure alignment and collaboration.
  • ARTs work on continuous delivery pipeline to regularly develop and release small increments of value. This enables teams to release solutions at any time the market demands i.e. Release On Demand
  • ARTs provide common and consistent approaches to system architecture and user experience (UX).
  • DevOps is a mindset, a culture, and a set of technical practices that provides communication, integration, automation, and close cooperation among all the people needed to plan, develop, test, deploy, release, and maintain a solution.

To conclude most of the critical aspects of SAFe framework are covered in Essential SAFe. In the blogs to follow, we will see each components of Essential SAFe in details.

References: SAFe Distilled 4.5 and Scaled Agile Framework

SAFe – Lean-Agile Mindset

In my previous blogs we have seen what is the need for SAFe and also had a high level view of SAFe four different configurations that organisations can leverage to fit to their needs. In this blog let us see what changes do we need in the thought process as Leaders to drive the Lean Agile mindset.

One of the biggest challenges any organisation face is change. The transformation from one mindset to another is not easy. As Gandhi ji said,You must be the change you want to see in the world”.

When we change our thinking and change ourselves, it become possible to change those around us. If you want a change in your organisation, as a Leader you should take the first step in that direction. It is not enough for Management to commit themselves to quality deliveries. They should very well know what is that they should be doing to meet the objective and this is something that cannot be delegated.

In the words of Deming – People are already doing their best. The problem is with the system. Only management can change the system.”

House of Lean:

To implement SAFe, Leaders and Management should learn and adopt a Lean-Agile Mindset. As depicted in the figure below (From SAFe Distilled 4.5):

Most crucial aspects of Lean-Agile Mindset are:

  1. Lean Thinking – This consists of six concepts as in the picture above:
    1. The Roof i.e. Value or the Goal
    2. Value delivered is supported by four pillars of Respect for people and culture, Flow, Innovation, and Improvement
    3. Foundation for pillars is Lean Leadership. This is what holds everything together.
  2. Embracing Agility – SAFe is completely dependent on the capabilities of Agile teams and leadership. The goal should be to enhance Agile methods.

Let us see each one of them in a little more detail:

  • Thinking Lean – Lean got its birth from the Manufacturing industry, but slowly got its roots in Software and system development. 
  • Roof – This represents the value to be delivered or Goal to be achieved. Focus is on achieving this Goal or maximum value in the shortest sustainable lead-time. Therefore the goal is not just to achieve the end deliverable but also focus on high morale, satisfaction and happy customers (Internal and External) But the question is HOW?

Pillar # 1 – Respect For People And Their Culture –

In an organisation it is the people who does all the work. That is why it is very critical for an organisation to understand and respect the culture. For growth it is very critical, to change its culture. Furthermore, respect should not be limited to its own employees, but should as well get extended to external stakeholders. This is where when doing PI planning, timezone, cultural differences need to be respected when working in globally distributed teams.

Pillar # 2 – Flow

As the definition states, flow is moving steadily or continuously in a current or stream. For SAFe to be successful, value or goal to be delivered should be continuous and react to fast feedback and make adjustment accordingly. Continuous flow help in early feedback and correction.

Pillar # 3 – Innovation

Flow surely helps to achieve the end goal effectively. But how do we ensure Flow is effective? This is where innovation comes into the picture. To practice innovation, Leaders must focus on:

  • Gemba – Japanese Concept – It advises management to get out of the closed-door office and be on the ground with the team at the workplace. 
  • Keep time aside for Innovation – We shall ensure to keep a focused time aside as a part of the regular development cycle. SAFe has specifically insisted on Innovation and Planning iteration within its framework.
  • Capacity should figure out accordingly – With 100% utilisation and daily firefighting innovation or value add is not possible.
  • Cross-check Innovation with customers and to deal with bad decision simply make another decision (“pivot without mercy or guilt”)

Pillar # 4 – Relentless Improvement

Organisations focus should be to continuously learn by introspection and adaptation. Leaders should look at the facts and then act. Determine the root cause of the problems faced and work on the solutions immediately. Fix it there and then. 

Pillar # 5 – Leadership – Foundation

For successful adoption of Lean Agile mindset, leaders, managers, and executives of the enterprise should be held responsible. Therefore, leaders must learn these new and innovative ways to be successful.

Embracing Agility – The right half of the Lean-Agile mindset is, of course, Agile 

In a nutshell, moving to a Lean-Agile development framework will surely be a huge change. Practices are different, but also the entire belief system including core values, culture, and leadership philosophies are different. 

To begin the Lean-Agile journey and incubate new habits into the culture, leaders, and managers should first adopt the values, mindset, and principles provided by SAFe, Lean thinking, and the Agile Manifesto. This new mindset creates the foundation needed for a successful Lean-Agile transformation.

References: SAFe Distilled 4.5 and Scaled Agile Framework