Scaled Agile Frameworks offer your teams the advantages of Agile along with the freedom to follow other methodologies where it makes sense. Let's explore why enterprise architecture could be the key to implementing Scaled Agile.
Scaled Agile Frameworks (SAFe) are becoming a popular alternative to a full Agile transformation. Yet, this modular implementation of the traditional Agile methodology can be even more complex to adopt.
While a SAFe methodology maximizes your organization's flexibility and empowers your employees to self-organize, it needs careful monitoring and in-depth understanding of the needs of your teams and your business strategy.
Our LeanIX EAM can offer clarity on your enterprise architecture to illuminate where you should implement what aspects of Agile methodology. To find out more, download our free whitepaper:
DOWNLOAD: How Enterprise Architecture Can Contribute to Delivering Agile Transformation
In the meantime, let's explore the history of Agile, why Scaled is the best way to implement it, and how enterprise architects can help.
The Origins Of Agile
The concept of Agile Scrum was first developed by Hirotaka Takeuchi and Ikujiro Nonaka in a 1986 Harvard Business Review paper. The pair would then expand upon the concept in a subsequent book, The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation.
The term 'scrum' in rugby refers to part of the game where the teams link arms to form a pushing competition to try to clear space to allow the players behind them access to the ball. Takeuchi and Nonaka, however, thought it referred to the subsequent passing of the ball from player to player along a line as they ran towards their goal.
The pair saw this as the optimum way for product development to work, as the software product being produced passed from developer to developer on its path to completion and release. While the product is in the hands of a developer, just like a ball in a game of rugby, that player is able to choose a path and make decisions regarding what to do with it.
The difference between this misnomered "Scrum" methodology and traditional development was that the developer who is 'hands-on' with the product is in charge of its development at that moment, and can react and change course as is needed, instead of waiting for authorization. It's a way of putting the decision-making power on the ground, where it needs to be to make the optimum choice in context.
The Pace Of Change
Since the 1980s, technology has been developing increasingly quickly - often faster than technology companies are capable of keeping up with. Where a company could once take a decade to develop and perfect software, in the modern age, the hardware an application is being developed for would be long obsolete before the product was released.
Development needed to accelerate. Achieving that meant cutting out bureaucracy and hierarchy by putting the responsibility for development decisions in the hands of the people who both understood the product and were able to enact the new strategy.
The need for this 'agility' became so desperate that a group of developers published a "Manifesto For Agile Development" in 2001, calling for 'Agile Scrum' methodologies to be adopted across the industry before the speed of technological change outpaced the software development industry.
As time went on, however, it became clear that Agile Scrum wasn't always the answer. Numerous other Agile methodologies were created, but Agile practitioners also petitioned for using the right tool - or methodology - for the right job.
Being Agile About Agile
Agile doesn't always make sense in every context. For example:
- highly regulated industries like healthcare and finance require comprehensive approval processes that don't always allow for developer autonomy
- regular daily Scrum meetings to synchronize teams can sometimes become more of a drain on time than the approvals process Agile removes
- open-source software risk needs to be managed, so security decisions sometimes need to be made for the project overall
- when different teams are building separate parts of a larger application, each team working independently can cause issues with assembling the final product
- for Agile to work, your customers must be as on board as your team and this isn't always the case
Thankfully, Agile takes this into account. A major principle of Agile is that you must be as flexible in your approach to Agile as the Agile approach is to software development.
Indeed, the last of the twelve principles of agile development contained within the manifesto is:
"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
To stress this, Agile is now often rebranded to make clear that it is a flexible methodology to be applied only where it makes sense. This is where Scaled Agile Frameworks (SAFe) come in.
What Is A Scaled Agile Framework?
Scaled Agile Frameworks (SAFe) offer the support of Agile methodologies and training to teams, while still empowering them to self-organize according to Agile principles. This means that you create a range of functional methodologies under which teams in your business can operate and then work with them to determine which is best for their team and function.
Each of your teams can then determine whether it makes sense for them to stick to their existing structure, switch to Agile, or to take elements from each methodology to find the best way of working for their situation. For example:
- finance teams are strictly regulated and must follow a repeatable process to ensure consistency, so Agile may not be the best option for them
- an independent project team looking to develop and launch a new product could benefit from adopting the Agile Scrum framework
- a quality assurance team needs to ensure quality and compliance on all software, so should stick to a strict workflow, but splitting this into Agile Sprints may help manage stakeholder expectations
Making Scaled Agile Work
Yet, no team in your business is an island. For a SAFe structure to work, you need to ensure that your teams can collaborate despite their different methodologies.
Your sales team may make a promise to a partner, guaranteeing a particular feature would be live before implementation. Yet, your development team might decide to prioritize bug fixing over the new feature and push it back to a future two-week "Sprint" of work.
For your business to function, your value stream needs to flow correctly through your business architecture. While this can be done efficiently with each team working under their own Scaled Agile Framework, someone must curate the workflow to ensure the different frameworks function together.
This means that someone with an understanding of your entire business strategy must have oversight of how your individual teams function and how they fit together. There's no better person for that task than an enterprise architect.
Supporting Scaled Agile With Enterprise Architecture
Scaled Agile Frameworks (SAFe) are best implemented by an enterprise architect with knowledge of how all the moving parts of your business support each other, as well as your overarching business strategy. This ensures an unbiased opinion on team methodology and also ensures collaboration is optimized.
Your enterprise architecture team should be tasked with developing the templates for frameworks under which your teams can build their structure. Enterprise architects can then approve their choices, ensuring they aren't at odds with other teams in the business, and still allow reporting and alignment.
To do this, however, enterprise architects must have a clear overview of their organization's business capabilities, teams, and software infrastructure. They need a modern enterprise architecture management system.
The LeanIX EAM
Implementing Scaled Agile Frameworks (SAFe) requires enterprise architects to have a clear overview of their business infrastructure. The LeanIX EAM combines all the information you need into scalable dashboards to empower SAFe with comprehensive clarity.
To lean more, download our whitepaper on leveraging enterprise architecture for Agile transformation:
/EN/Reports/Thumbnail-Obsolescence-Gartner.png?width=140&height=100&name=Thumbnail-Obsolescence-Gartner.png)
/EN/White-Paper/EN-IDC-Inforbrief-Application-Rationalization-Portfolio-Management-Thumbnail_v2.png?width=140&height=99&name=EN-IDC-Inforbrief-Application-Rationalization-Portfolio-Management-Thumbnail_v2.png)
