What is Scaled Agile?
What is Scaled Agile?
SAFe is a framework developed by Scaled Agile, Inc. to scale up classic Agile methodology from the team or small group level to the enterprise level.
If you’re not familiar with it, Agile is a project management style focused an iterative approach and frequent communication between the team and the customer versus extensive upfront planning and requirements gathering to ensure success.
Basically, instead of sitting down and trying to think about every single requirement for a project along with a detailed timeline as with traditional project management (often referred to as Waterfall), teams practicing Agile focuses on getting a rough idea of what the product should be. Then they do or build something and show it to the customer, get feedback, make changes to accommodate the feedback, rinse and repeat.
Benefits of Scaled Agile
Benefit 1 - Fast Results: A huge benefit to an Agile approach (scaled or not) is that you see results very quickly in comparison to Waterfall. Gone are the days of enduring (and paying for) a 9-month long project before seeing anything tangible from the project team.
With Agile, you can see tangible results within weeks. Obviously, it probably won’t be a completed product, but it will let you know if the team is on the right track and that progress is being made.
Benefit 2 - Less Rework: Since you’re frequently seeing the current state of development, you can make changes to it to accommodate current needs. This avoids the, unfortunately frequent, problem with Waterfall management of having a teamwork for 3-months only to have them produce something that meets all the stated requirements but is no longer useful because the organization’s needs have changed. Of course, for perpetually budget-starved departments this also reduces the cost of projects which is a nice plus.
"Agile is a project management style focused an iterative approach and frequent communication between the team and the customer versus extensive upfront planning and requirements gathering to ensure success"
Benefit 3 – Happier Customers: Since your teams are frequently communicating with their customers, they feel more involved in the development process. This tends to make them much happier with what they get from the teams. It also helps ensure that the product will do exactly what the customer needs since they’ve been involved all along.
Challenges We Encountered Adopting SAFe
Sound’s great, right? I mean what kind of leader wouldn’t want to realize those benefits? Well, as with most things in life, there’s always a catch. Or, in this case, at least three that we encountered when trying to adopt SAFe in Pima County.
Along with describing the top three challenges we encountered, I’ll also give you some advice, based on hard-earned experience, to overcome each of the challenges.
Challenge 1 - Budgets Set Far in Advance: One of the problems we encountered with Scaled Agile is the long lead time for budget planning here at Pima County. Essentially, we must have our budgets laid out in detail more than a year in advance. Since technology changes so rapidly, we’re often guessing as to what will be available and how much it will cost when the time to start a project comes.
As you can imagine, trying to plan budget for technology projects 12 to 24 months ahead of time reduces our ability to adapt to new needs or technologies since much of our budget is “locked in” and often can’t be used for other purposes even if we have the budget to cover it.
This is because most County departments, by necessity, use a Waterfall methodology and the overall budget process is tailored to those needs. After all, you don’t want to iteratively build and rebuild a bridge, road, or sewer system until you get it right, do you?
To get around this problem, communication is key. The IT department must communicate upcoming changes to planned spending with the budget authority as soon as possible. In addition, IT should be prepared to make a logical and fact-driven case to explain why the change to planned spending is necessary.
Challenge 2 -Coordination of Projects: Another challenge is the coordination of projects between the teams. In particular, when one of the teams is performing operations-type work such as upgrading Active Directory or vSphere which, in turn, affects all of the teams. While SAFe builds the framework to have multiple Agile teams, it makes a couple of assumptions that can be problematic:
• SAFe assumes all the teams need the same thing at the same time. In SAFe the underlying technical infrastructure is referred to as the “Architectural Runway” and it’s assumed that the teams will plan in time to build out the runway as they need between other, usually customer-driven, projects.
• SAFe also assumes that the teams will have the access required to make those changes because what CIO/COO/ CISO doesn’t want multiple teams to have full rights to every Enterprise IT system in order to make changes as they see fit?
At Pima County, we decided that the best way to address these shortcomings was to have a dedicated Operations team along with our customer-facing teams. The Operations team doesn’t directly work on projects for customers. Instead, they support the teams supporting the customers. In addition, they oversee the technology infrastructure and set standards for things like server hardware, Windows server versions, security, networking, database standards, etc.
This team then “publishes” a quarterly schedule of projects and associated versioning to the other teams so that they can plan accordingly. In turn, the other Agile teams give feedback as to what versions/capabilities they will need for the upcoming quarter so that the Operations team can accommodate them.
While this prevents the other teams from getting exactly what they want, it gives them what they need in a timely manner.
More importantly, it prevents the infrastructure from falling into a chaos of different standards and versions of products or the development of independent (and very expensive) infrastructure for each agile team’s use.
While this approach isn’t perfect, it does avoid several problems that could arise with the adoption of SAFe.
Challenge 3 - Agile is Geared for Coding Projects: This one sounds silly but it’s a real problem for some people and can cut down on morale and confidence in the whole process.
Since the use of Agile is most prominent in software development circles, many Agile development tools use terminology centered around software development such as “features” and “user stories”. Turns out, that this can lead to them feeling like the process isn’t really for them since it’s not describing the work that they are doing (unless it just happens to be software development).
In turn, the team members feel like a square peg in a round hole when they’re being forced to adapt their terminology to fit the software development paradigm.We saw this most frequently with members of the Operations team.
While SAFe isn’t perfect, it can provide a lot of value. Just be willing to adopt and adapt the process to best fit your organization. Hopefully, our experiences can help you avoid, at least a few, pitfalls if you so choose to go down this path.
We began our journey in August of 2018, and in just 7 short months we’ve seen our productivity increase by leaps and bounds, better relations with our customers, and improved morale. Despite some hiccups along the way, it’s been well worth the effort.