First off, what is SAFe….
SAFe is the Scaled Agile Framework. In software development, it is a framework to apply Agile principles at a larger scale. It is a process, or template, to apply Lean, Agile, and Scrum principles across a large enterprise of teams. Offering controls to help with the size of the team within the framework. The framework breaks down concepts and ideas, to help large teams become a team of smaller teams. Then leveraging the team of teams concept, to work towards the larger enterprise goals. SAFe is one of the Agile methodologies that allow you to apply Agile on large teams or scale Agile to the enterprise.
In my mind, the whole intent of SAFe is to apply a layer of Agile project management. Adding some layers of traditional software project management and Waterfall model controls. This seems counter-intuitive. However, Scaled Agile aims to bring some project management to allow development work at scale. Which, without that management, the Agile process is very fluid and it can be tough to manage.
Without the control and oversight of teams, your software projects can seem to be out of control. However, that is an underlying value of Agile in general, to give goals to the team and get out of the way so they can deliver. Trusting they work the software development process in the best way to meet the goals.
Adopting Agile helps solve many issues in software and product development. However, working at scale in large organizations presents a whole new set of challenges in an Agile development methodology. Scaled Agile was created to help solve these challenges.
In the following, I bring up some things I really like about working in SAFe. As well as some things I don’t necessarily like about SAFe. This is an overview of my top items about SAFe. Is the Scaled Agile Framework a new fad, is it the real deal? Adopting this SAFe, as Agile frameworks over your processes, could benefit your team, but if not suffering from issues it addresses it may not be worth it.
Table of Contents
5 things I like about the Scaled Agile Framework
- Provides a framework for large scale Agile development. The Scaled Agile Framework helps team members to use Scrum and Agile fundamentals at scale. This scale being across a larger enterprise or larger team. It can help teams organize around large work efforts, breaking up work among multiple teams, to help achieve goals.
- It’s a mature framework used by a lot of organizations. The process is mature and in use by a lot of organizations. Additionally, a lot of big-name companies use Scaled Agile. Its Agile processes are already in use by many teams and companies. This reduces the need to solve all issues with a new process or set of ideas. Scaled Agile training is also available for teams that want to use it.
- Scaled Agile has built-in documentation. There is a lot of built-in information to help understand the principles of SAFe. Including how it uses principles of Lean, Scrum, and Agile. I am not saying you can get all of this info without a cost. There is likely a cost for you to use this. I just know there is good information available on principles, roles on the team, and more.
- Lots of skilled professionals out there have used this. To me, this means there are lots of sources and options to get feedback. Additionally, lots of individuals to seek advice from when needed. There are many Product Owners, Scrum Masters, Project Managers and more, that already have used this and have the expertise to help.
- Scaled Agile does offer flexibility. Just like Agile and Scrum processes, there is some ability to tweak the overall process to what works best for your organization. Within the Scaled Agile Framework, you can make changes to make it fit best for your needs. I would point out that too many changes could break the intent of the framework, that is relative to the situation. Part of this is the idea of inspect and adapt. This fits nicely within the larger Agile principles and bolsters the flexibility of Scaled Agile.
5 things I dislike about the Scaled Agile Framework
- Scaled Agile takes some control of work out of the hands of the Product Owner. As a Product Owner on the team, I do think there are some items that I lose control over. There are aspects in the management of the product backlog that shift from the Product Owner to other team members. This removes some of that ability to facilitate and make decisions, to keep work moving by the Product Owner.
- Scaled Agile formalizes processes. Formalizes some processes that I feel should be more ad hoc or on-demand. Simply stating that in Waterfall there are formal approval processes. In Agile, a lot of times there are not. Scaled Agile uses some Scrum and Agile, but also has some more formal processes. As an example, the larger team has demonstrations. These are often pre-scheduled in a set cadence, that follows the iteration schedule. Sometimes there is not the flexibility to go outside of this for demo’s and get the good user interaction and feedback needed. Formalizing too much does hurt the team’s ability for self organization.
- SAFe adds layers of controls. Following the process of Scaled Agile can add additional layers of controls, that to me feels a bit like the formalized process of Waterfall development. These controls can hinder good iterative practices. They can create red tape that makes getting to the work difficult. These controls go against the principles of the Agile manifesto. Not that it is a bad thing. There are aspects of formalized control that are useful to the Agile and Scrum team. Especially when managing and organizing the work that applies across multiple or many teams. To develop software at the enterprise level, you may need these controls to scale the Agile team.
- The scale of the Agile project information can be overwhelming. For teams trying to implement this framework, the large scale of the framework can be a lot. Especially for team members newer to the concepts in Lean, Scrum, and Agile. This can make adoption more difficult. It’s not just about a team’s user-stories or their own sprint, but all of the Agile teams. Including all the cross functional and interrelated work. The project team can have so many things they must do that are not the software and product development work.
- SAFe can create a clutter of meetings and tracking processes. The volume of ceremonies and meetings to follow the Scaled Agile Framework creates a lot of clutter. For team members, working through all of that can be a headache. Also part of this is the number of tracking processes that can be included. Tracking of stories, dates, dependencies between teams, and more. All of that can add extra overhead, that can also be problematic for the teams. This can also hinder the ability to collaborate by teams and team members.
Scaled Agile – When It’s All Said And Done
All of the things I dislike above have one main tendency. They can slow down your deliverables. This can help avoid mistakes, but not necessarily so. Mistakes can still happen, and now they just happen slowly, burning time along with the other things used up in the mistake.
With all the emphasis on planning and project management, estimation of work takes on more importance. This means the team spends more time on estimating work, than actually working work. This creates the need for the project manager role. Depending on the company, you may not have the role or may have moved it when you made the Agile transition. With SAFe, the need is back. With all the layers of control over the work, you need the project manager to run that. Unless you want to use up team members’ time on it when they should be focused on delivering the work.
There you have it. The Scaled Agile Framework for Agile software development. An Agile methodology that is all the rage right now. It may be able to help on your software project if the work is of large enough scale. It is helpful in controlling large volumes of overlapping work. But it probably won’t bolster your existing Agile practices and methodologies.
If you consider it for your organization and software project, use its best parts, and don’t forget your Agile tools along the way!
Additional reading and eBook content that helps with Scaled Agile
Agile Product Owner skills go a long way in helping the team. They are useful to roles outside of Product Owners too. Check out the top Product Owner skills for Agile.
Understanding the intent of Agile, its ideas, and its values will help to leverage it better and enable team success. Let’s start with what it is.
Feedback Loops are an essential part of learning and building the right things. More can be found in our eBook. The Feedback Loop – Get the Info You Need To Build in Quality. Available on Leanpub here.