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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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:
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.