Contact Us
en
scaled agile framework core values
Article

Successfully Adopting the Scaled Agile Framework Core Values: Enterprise Leader’s Roadmap

Adoption of the Scaled Agile Framework (SAFe) is a hot topic among large enterprises. So much so that 70% of Fortune 100 companies and an ever-increasing number of Global 2000 firms now have their own accredited SAFe specialists. Here, we analyse the Scaled Agile Framework core values and offer a rundown of the four levels of the SAFe, and how you can implement them within your organisation with little to no risks.

Agility was a business necessity long before the COVID-19 outbreak. In today’s rapidly evolving market, the ability to adapt is crucial, and SAFe methodology enables new levels of corporate flexibility and scalability. According to a survey by Organize Agile, 78% of businesses have spent at least the last year focusing their efforts on implementing Agile methodologies and adopting Scaled Agile Framework core values.

Managing business processes, establishing communication between teams or onboarding stakeholders can present an obstacle for a large and cumbersome company. Simple waterfall processes no longer meet the expectations of a large enterprise and its teams. So, SAFe was developed to seamlessly integrate Agile practices within large organisations — as well as small ones.

Scaled Agile, Inc., reports that financial, logistics and insurance companies, among others, have incorporated SAFe more and more in recent years. But adopting the Scaled Agile Framework core values isn’t without its challenges.

 

What are the Scaled Agile Framework core values?

The “core values” are the foundational principles on which the Scaled Agile Framework is built. These values enhance SAFe’s effectiveness and guide enterprises through the development of complex solutions — ensuring effective teamwork and swift product delivery. SAFe leverages following five core values:

1. Alignment

Alignment helps each team member understand workflow status, business strategy, business goals, and the steps needed to achieve them. Aligning employees through top-down and bottom-up information flows helps develop team autonomy and makes it easier for a company to quickly respond to changes.

2. Built-in quality

This principle guarantees a certain quality standard throughout the development process. Hence, the quality benchmark doesn't solely rely on testing — it’s enhanced in an Agile company’s products and services from the very beginning.

Five fundamental indicators of built-in quality
scaled agile framework core values: Five fundamental indicators of built-in quality

3. Transparency

SAFe’s transparency value provides visibility of workflows, enhances trust relationships within a team and helps identify bottlenecks. It also provides real-time information on the development process across all levels within a backlog, thus making progress transparent to all stakeholders and team members.

4. Program execution

SAFe’s program execution principle ensures that teams continuously deliver high-quality software and added business value. Successful program execution relies on the previous alignment, built-in quality and transparency values and is broken up into manageable roles and sprints.

5. Leadership

SAFe leaders are responsible for creating the ideal environment for the successful implementation of the core values. By reinforcing these principles, leaders deliver unique value for customers and create a meaningful culture for their team members.

 

What are the four levels of the Scaled Agile Framework?

There are two paths that organisations can take when implementing a Scaled Agile Framework: three-level and four-level. Smaller teams tend to implement SAFe at three levels — portfolio, team, and program. For a company with many specialists, a four-level SAFe approach is applied.

1. Team level

Self-managing and self-organising teams within SAFe deliver a software demo every few weeks — known as “sprints”. At the end of each fortnight, the team presents a working element of the software to the product owner. Using common iteration, teams can remain synchronised and work simultaneously.

2. Program level

At program level, multiple autonomous teams — forming an Agile Release Train (ART) — work together to provide verified and working software or systems. ART provides a cohesive goal and tangible evidence of progress for the teams. Members of the ART team define the objectives to be reached by the end of each product increment — lasting from 8 to 12 weeks — with bi-weekly meetings offering a sufficient architectural runway.

3. Value stream level

This is considered optional and designated for the multiple ART teams. At the value stream level, SAFe helps coordinate large product groups and supports the production of comprehensive solutions.

4. Portfolio level

SAFe’s portfolio level encapsulates strategy formulation and solution development, via a value stream or set of value streams. At the portfolio level, teams are tackling the backlog of business epics and working on the systems needed to achieve an enterprise’s goals.

 

Solving the 3 key challenges of switching to SAFe

For all its benefits, migrating to the Scaled Agile Framework isn’t straightforward. Here's our take on the three common issues a company might experience when implementing SAFe, and some of the best ways to tackle them.

1. Marking the beginning of epics

Most enterprises never determine the initial epics of a project. Defining these can disrupt the flow but it’s important. Here's how to simplify the process of outlining your first epics.

Let’s start by defining what we mean by "epic”. In SAFe, an epic is a solution development initiative which measures the potential ROI ahead of launch. Also, within SAFe, an organisation can outline its business case for each epic.

The concept is similar to a software project or program. Both require economic feasibility and evaluation of ROI before you can secure funding. The main difference, in the case of SAFe’s epics, is that the company sets up a new team for a project that’s already funded. Epics form part of ART’s capacity, with a request for a dedicated team of 50 to 125 people.

Epics fall into four categories, which sit under two “umbrella” categories:

Portfolio epics and software epics

It’s a common misconception that every software (or program) epic derives from a portfolio epic. In fact, portfolio epics cover several flexible releases (ART), while a program epic belongs to a single ART.
To add to the confusion, both software epics and portfolio epics are typically stored in a single reserve called a “portfolio”. Portfolio epics come from the portfolio management team, and software epics come from the train.

A train can either:

  • create an independent software epic
  • distinguish itself as a part of portfolio epic, then create a program epic to fulfill its part of the portfolio epic

For a transparent and flawless performance, both types of epics go through a Kanban portfolio, like the project conveyor.

In conclusion, every epic is a software epic, in terms of ART. While only a few are tracked back to portfolio epics.

Business epics and architectural epics

The difference between business and architectural epics is more obvious. Business epics improve your customers’ experience, while architectural epics accelerate your portfolio’s value delivery and add quality.

Define your initial epic

We’ve worked with several companies that had many yet-to-be-funded projects and unclear processes for progressing them. Once a proposal or initiative receives funding, it becomes a project. Converting existing proposals, initiatives, projects and programs into an epic is the fastest proven method of designing the initial set of epics.

This same initial process will also help you define possible Agile Release Trains. Think of the program’s existing teams instead of building new ones. You already have a set of specialists working on programs and projects, and they can become your dedicated resource at the outset.

2. Determining value streams and initial trains

This can seem hard — even impossible — at the start. A clear example can help get things going.

Imagine having office products with three primary income sources: productivity software, operating systems and consulting. The first thing that might cross your mind is that these profit centres could become perfect streams of value creation, since each of them is its own source of value. SAFe, however, is about size. SAFe addresses the issue of large teams — of more than 50 — and multiple teams with functional dependencies. Let’s break this down:

  • Example 1
    Where there are 20 developers across three value streams, it doesn’t make sense to have three trains. Because there are less than 50 people, SAFe implementation probably isn’t needed. If, however, those 20 developers are accustomed to SAFe, they're likely to use its best practices, despite their small team size.
  • Example 2
    Where you have 50 to 125 developers across three value streams, you can either have one value stream with three trains – productivity software, operating system, and consulting – or three separate streams of value creation each with one train. We advise that you start with one train, in this instance, and add more when you need to.
  • Example 3
    Now imagine that your value streams have an abundance of developers. Let’s say you have four key products to improve in terms of software performance: Doc, Sheet, Presenter, and ToDo, with web, mobile and desktop operating systems. Each of these product areas comprises 50 to 125 developers. In this scenario, it makes sense to create three value streams, each with several trains.

Draft value streams and trains

A train consists of a group of 50 or 125 devoted individuals, and this is a great indication of the number of trains and value streams your business might need. If you have around 125 people or less, start with one train and one value stream. If you have more, refer to your current activities for guidance. Aim to continuously develop your specialists by providing a range of training exercises and masterclasses.

3. Code quality assurance

Ensuring code quality can be challenging for firms that use SAFe. To do this, you’ll need to make a hard distinction between story and task. Stories add some business value when tasks aren’t units of commercial value. A story must be improved (using clear requirements), designed in line with good architecture, tested and utilised in a prearranged environment. You’ll struggle if your stories are separate entities, i.e. in a scenario with four sprints, where the first one is all specifications, and the fourth one is purely about testing.

It’s also important to note that, before going Agile, your team needs to understand and implement modern and robust engineering practices.

What are modern engineering practices?

  • Requirements methods (scenarios, business rules, terms, non-functional requirements)
  • Methods architecture (intentional architecture, model-oriented development, architectural patterns)
  • Development methods (emerging design, technical debt, development through testing, continuous integration)
  • Testing methods (test virtualisation, automated test, test management, test ideas, test scripts and test scripts)
  • And remember DevOps, which runs throughout each of the above practices

Most business would find it hard to provide high-quality engineering services in two weeks. But with deeper insight into SAFe, shaping a flexible team becomes less of a burden.

Step 1: Provide robust engineering practices. Ensure that your company’s engineering and technical activities support high-quality product development. Focus on enhancing your engineering practices to achieve the best result you can.

Step 2: Get to grips with Agile. Make sure your team recognises the crucial components of agility – teamwork, trust environment and team autonomy. If you’re not working with a robust understanding of Agile methodologies, things can quickly descend into chaos.

Step 3: Innovate and listen. Think about how many times you've rejected ideas coming from your team. Say yes more often. Accepting new ideas will help you to become more flexible and, thus, more innovative – giving your teams the confidence to make better decisions.

Step 4: Analyse your teams. Conduct rigorous team analysis, identifying any weak spots and finding ways to make your team better and stronger. It’s your job as a leader to look for those weak links and provide the right tools to bolster your team.

 

Conclusion

SAFe is an incredibly useful yet confusing framework. Scaled Agile Framework core values help large extend strengthen their Agile approach and align teams to a common goal. But switching to SAFe can be tricky.

If you have the determination to get to grips with SAFe, your firm can reap the rewards of high-quality products, streamlined execution, process transparency and improved productivity. Contact us today, to see how SAFe can give you the edge over your competitors.

Delivering Six Retail Projects with Rapid Team Scaling
View Case Study
blackboard
Contact Us
  • We need your name to know how to address you
  • We need your phone number to reach you with response to your request
  • We need your country of business to know from what office to contact you
  • We need your company name to know your background and how we can use our experience to help you
  • Accepted file types: jpg, gif, png, pdf, doc, docx, xls, xlsx, ppt, pptx, png.
(jpg, gif, png, pdf, doc, docx, xls, xlsx, ppt, pptx, PNG)

We will add your info to our CRM for contacting you regarding your request. For more info please consult our privacy policy
  • This field is for validation purposes and should be left unchanged.

The breadth of knowledge and understanding that ELEKS has within its walls allows us to leverage that expertise to make superior deliverables for our customers. When you work with ELEKS, you are working with the top 1% of the aptitude and engineering excellence of the whole country.

sam fleming
Sam Fleming
President, Fleming-AOD

Right from the start, we really liked ELEKS’ commitment and engagement. They came to us with their best people to try to understand our context, our business idea, and developed the first prototype with us. They were very professional and very customer oriented. I think, without ELEKS it probably would not have been possible to have such a successful product in such a short period of time.

Caroline Aumeran
Caroline Aumeran
Head of Product Development, appygas

ELEKS has been involved in the development of a number of our consumer-facing websites and mobile applications that allow our customers to easily track their shipments, get the information they need as well as stay in touch with us. We’ve appreciated the level of ELEKS’ expertise, responsiveness and attention to details.

Samer Awajan
Samer Awajan
CTO, Aramex