Is SAFe actually Agile?

There are a lot of strong believers that Scaled Agile Framework (SAFe) is not. That it is a nicely packaged Waterfall approach that kills agility in its midst. We are not going to argue that it is not the case. Every Agile project that uses Scrum or Kanban, as every scaled project that uses Nexus or SAFe, or any other framework, is different. Every project and every organisation have their own nuances and it’s not their fault. It’s how people are working within those projects and organisations, implement and use different frameworks determine, if those are truly Agile or not.

---

Based on our experience, we would like to give a few examples what to watch out for, while using SAFe, and how not to fall into a Waterfall trap.

The balance between plan and changing requirements

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage” says Agile Manifesto. We can tell you now – you will hate changing requirements in SAFe. However there’s always the need to ask yourself “why”. Maybe because you have committed for a very long horizon already and you are pressured to deliver that? Maybe because you cannot release on demand and your processes allow you to release only once every 3 months, so everybody awaits that event with held breath? Maybe because you haven’t invested enough in CI/CD or stability of environments or automation tests? Any and all of those reasons, will be extremely painful if someone comes in with new requirements, especially late in development.

On the other hand you need to deliver, and you need to do it fast in order to get feedback, to become better, sometimes in order to keep your budgets. If you accept every new requirement into a release it might come that your release is a never ending story of new requirements and without the proper processes and infrastructure you cannot close that loop.

Hence the balance and the processes in SAFe, that, on one hand will help evaluate and prioritise new requirements, on the other, will enable you to deliver on cadence, but release on demand.

Launch with Waterfall approach

SAFe implementation can be done in few, quick steps. We shouldn’t spend on it months. First Agile Relaese Train (ART) can be launched within 2 weeks time. You start with short preparations and start without having everything in place. Assess what is crucial and without what you can’t actually start your SAFe journey with first ART. After this is done you continue scaling this up.
Don’t try to rebuild and implement scaling framework in whole company at once. Do it Agile. Pick up product with which you want to start and start building first teams around it. Train key people, through value stream mapping workshops asses how you will be organized. Do not spend months on preparations, don’t build big plans and roadmaps for transformation. SAFe offers you Implementation Roadmap (scaledagileframework.com/implementation-roadmap), do it step by step. Act quickly, fail fast and continuously improve.

SAFe approach is supposed to be Agile and same concerns its implementation. You do not have to have everything in place, you do not have to spend long months on discussions, meetings and workshops to start. Don’t start a Waterfall project where the goal is to launch SAFe, because this is a first step to spectacularly fail. Good enough, and at the same time short, preparations will help you to transform your organization step by step. Remember that transformation is a journey, that will actually never end. Bear that in mind and don’t be afraid to start it.

Committed roadmap

SAFe tells you that you will look into the future with roadmap and epics – long term cusinitiatives that will span across multiple Program Increments (PI) and will give you direction in your development. Continuous Exploration will help you figure out the MPVs that will move you towards that future.

“But what will I get of a product in 3 years?” asks a very important manager that can cut your funding in a heartbeat. And the answer should be – you don’t know – but you are afraid to admit that truth. If done properly, it will definitely be something that your customers want, as you will explore their needs and responses to your product and shape the product accordingly. However, now, you don’t know what your customer will want or need in 3 years so how can you tell what you will deliver? That’s impossible, but not knowing the answer is extremely uncomfortable for your organisation, and hence you oblige and create a roadmap of what you think you will deliver. Then, because of the pressure, you make the worst mistake of them all and commit to that roadmap. Now you are no longer Agile, that’s Waterfall – known requirements and designs upfront that have been committed within the time and budget.

SAFe suggests to create and maintain roadmap for a 3 PI time horizon. It should be elaborated within the Agile Release Train (ART) processes and should evolve with the product itself. You will find new features that your customers would like to have and you have to have space for that. How are you supposed to deliver those if you have committed already something different?

Dev-Ops is even harder in scale

Dev-Ops is a state of mind. It’s how you, and everyone else on the project and in your organisation, think about the product – end to end. It’s not about taking responsibility for someone else’s piece of work, but thinking ahead how they are working and how can you help. When you, as a leader, have to inspire culture of shared responsibility in a Scrum Team, it’s not easy. If you have to do the same with 50, 100, 700 people it’s going to be that much harder.

Establishing a Continuous Delivery Pipeline will help you overcome some of the problems, but you have to do it right. Continuous Exploration cannot be a phase in the PI with deadlines and milestones of when the requirements and backlog should be ready. There cannot be handovers between Business, Architecture, ART as there has to be close collaboration. Continuous Integration has to have a purpose and that means we have to invest in infrastructure and automation of the processes and tests. Continuous Deployment has to go as close to production as possible. Release on Demand cannot mean we have a number of set dates for releasing.

Every loop inside the Continuous Delivery Pipeline is a feedback loop. You want to learn if you go in the right direction of what the customer needs, if your code won’t stop everyone else from working, if your code works, if it’s good quality, if it brings value, and you want to learn it fast, to adjust, to be better than everyone else, so you have to close that loop as soon as possible.

Remember to improve, continuously

One of the crucial things is also to improve when working any Agile methods. Thinking about what went good and what doesn’t work and regular discussions about it is an essence of working Agile and delivering value to customer. Each iteration on team level should end up with sprint retrospective. On program level in SAFe, among other things, you have Innovation and Planning Sprint (IP sprint).

During this iteration train has two primary areas to focus on, it’s innovation – what we could improve, change, propose to our customers; and planning – prepare & plan next PI. We should also devote some time for, so called, Inspect & Adapt workshop. It consists of three parts during which we demo what ART did during past PI, reflect on the metrics, verify how predictable we are and, lastly, we perform problem solving workshop, where train identifies what is the most burning issue and we try to solve it via agreeing actions which we will perform to minimize or remove the issue.

Proper IP sprint is mandatory and should be done in order to succeed and be even better in next PIs. Unfortunately, it’s quite common that during PI we didn’t deliver everything which we committed to or there were so many changes that we start to sacrifice some of the preps and sessions to continue regular work. Doing that way is another trap for the teams. People want to feel empowered that they have some influence on how we work and IP sprint is the best occasion to enable them that. If IP sprint is just a regular continuation of previous iterations, where we agree what we are going to do, then definitely it will have an impact on those people, their performance and deliverables.

Business owners. Have anybody who can throw your prioritization upside down very close

Business Owner (BO) is a person that we started to realise is much more important than we actually put credit to in the organisation while implementing SAFe. In the setups that we have seen it might be a Product Manager (PM) that is literally “playing” the role, or the Solution Manager (SM) if it’s a Large Solution setup, or the Epic Owners if it’s the Full Safe configuration. And that’s understandable as they hold the prioritisation responsibility on the respective levels, with which the BO should be very much involved in. However, usually, that prioritisation has to be aligned and agreed within the organisation with some stakeholders and there you should start looking for your Business Owners. It might also be the situation where the PM or SM will not have enough power in the organisation to actually make a change outside the ART.

“We don’t have business owners, we don’t need them” – wrong! There are always people who will have an impact on your priorities in a large scale setup and if you don’t realise that, you will end up in a lot of trouble. And you do need them – it’s the people that will make your problems go away just by picking up the phone and solving them, then and there on the spot.

Who is your BO? First of all it does not have to be one person. SAFe clearly states Business Owners. And secondly, that’s probably everybody and anybody that can come in during your second day of PI planning, look at the priorities, which they have seen for the first time (!), and decide that your 3 top capabilities are really not that important. However your “15th”, that the teams didn’t have the capacity for, actually has to be done next PI or the organisation will suffer substantial money loses. Or maybe you are waiting for a decision about this or that technology for months now and there’s this one person that can make that decision, but they don’t – that’s your Business Owner (or whoever has power to influence that person) and you need to involve them in your ART, in your planning, so that they understand why it’s so important that they make that decision.

Train everybody and do it quickly when a new person comes, especially the managers

According to SAFE you have to “Train everyone. Launch Trains”, which is easier said than done. This requires a lot of investment upfront that not necessarily your organisation can cope with, without realising the potential of the framework. Even if you pick a small project with around 50 people in it, that’s still a substantial cost involved in putting them through the curriculum.

We are not advocating here for SAFe trainings and certification, but rather acknowledging that SAFe is not 19 pages of Scrum Guide. It is a complex framework that one has to be trained in. Everything is harder in scale. All-in-all, without the training, people will not realise the “why” of the transformation and without that you will not succeed.

People don’t buy what you do; they buy why you do it

_{Simon Sinek, Start with Why: How Great Leaders Inspire Everyone to Take Action}

So you train the people that are going to be in the ART. But we all understand that with any project there’s a lot more stakeholders involved then just the immediate surroundings. However if you’re in the beginning of your SAFe journey, did you realise that they have to be trained as well? It’s them that will support the transformation and maybe they are not the most important they are really, really, really important. Training only the teams means we are optimising locally (SAFe principle #2 – Apply system thinking) without looking at the big picture and we will have a lot more challenging job, with the transformation, than if we understand whose buy-in we have to have to succeed.

Why a new person and especially the managers, though? You might ask – “shouldn’t the teams, Agile Coaches or RTE take care of ramping up the new people”? Yes, in part that’s true, but they will introduce them to the specific ways of working of the ART only. The newcomers have to get the fundamentals right or they will start stumbling in the dark. A manager coming in from a different non-SAFe project has some very good practices of their own and they want to do their best, but that’s not necessarily how we are going to work in a SAFe project. With their position they can make a lot of mess until you realise what is happening and that’s why you want to have them on your side, the transformation side, as soon as possible.

When introducing SAFe to your organisation it is highly recommended by Scaled Agile to build strong, powerful guiding coalitions with leaders. Only by this you can achieve good results and success as you will be empowered by them. And in case of any challenges they will be available there for you to quickly overcome those, without impact on the teams deliveries.

Conclusion 

I have yet to meet a person that says that Agile transformation is easy and painless. It is so because you have to let go of you have been taught. You have to trust people not manage them, you have to empower them to do the right thing instead of keeping everything to yourself. Everyone’s mindset has to be changed. Regardless of the methodology or Agile framework, if not done right you will fall back on your known methods and the transformation will fail, hence it is not easy. However if you follow the rules, the good practices, others people experience. Avoid the known traps and help other do so. If you acknowledge that your project or organisation is not actually that different, unique, as you might think or try to explain to others. You will succeed. Be better.

Last but not least, don’t ask how long the transformation will last. It will be permanent as transformation is a journey and SAFe or any other framework is just enabler on your transformational path.

O Autorach

---