“Agile at Scale” Doesn’t Mean What You Think It Does
“Agile at Scale” Doesn’t Mean What You Think It Does
In this post, we discuss a few ways that Agile teams working on large projects can properly scale so they can meet their Sprint goals.
Join the DZone community and get the full member experience.Join For Free
Enterprises have many IT projects that are moving concurrently and interdependently. Some of these projects are huge in size and scale. While Agile may be in place for a company in typical small team situations, the need exists for it to also be used on a much larger scale, encompassing many teams. So, the question arises: How do you use Agile so that the small teams are not working in isolation but, rather, in coordination with each other in a large enterprise? The answer to this question requires Agile to scale up and work in a way that all small teams on a large project are coordinated and integrated.
Though the title of our webinar “'Agile at Scale' Doesn’t Mean What You Think It Does” may be a bit presumptuous (since we don’t really know what you think “Agile at scale” is), we think the topic is important and one that is relevant to what is working in corporations today. Agile, as it was original created, doesn’t address this need to scale up for larger projects and organizations, but there are many frameworks that do.
One of the most widely used frameworks to achieve this scale is SAFe. Our webinar gives you an introduction to SAFe and how it can be used in a large environment to coordinate smaller Agile teams. The webinar is packed full of information you can use, but in this article, we wanted to give you some of the highlights in the form of these 5 key takeaways:
- SAFe is a framework for scaling Agile in a large organization.
- SAFe allows the enterprise level to work in an Agile way.
- Only implement the pieces of SAFe that you need.
- You must invest in overhead in order to coordinate teams.
- Restructure systems into a service-oriented architecture.
SAFe Is a Framework for Scaling Agile in a Large Organization
SAFe is one of the most widely used frameworks for scaling Agile in a large organization with situations that are larger than having a few smaller, Agile teams. A typical Agile team is usually 6-12 people. Scaled teams can be dozens, or even hundreds, of workers. When a small team isn’t sufficient for a project, you need to scale Agile.
SAFe Allows the Enterprise Level to Work in an Agile Way
SAFe uses layers in its framework that build from the team level up to the portfolio level. The layers are (from bottom up):
- Value Stream
The team layer is at the bottom of the SAFe framework because it is the basic core where the actual IT work is done. These are normal Agile teams structured with up to 12 workers, a product owner, a Scrum Master, a backlog, and so forth. These teams are not working in isolation in the SAFe framework; the other layers enable the teams to coordinate and work in parallel with each other.
The Program layer adds the structure that is necessary to coordinate teams for the large project. This is the layer where the project work of the individual teams comes together. This layer sets up the integration of the work by pulling the pieces together, guiding, and coordinating all the teams.
The key players in this layer are the RTE (Release Train Engineer), the System Architect/Engineer, and Product Management. The RTE coordinates the logistics of the overall project. The role of the System Architect/Engineer is to design the system and put the pieces together, addressing whatever technical issues are appropriate given the technologies being used and the type of product that is being built. Many times, this role also addresses the integration testing at the program level as the pieces of the teams are put together.
Product Management is made up of the product owners of the small teams. The product owners work in concert with each other and should be in sync from a logical product perspective.
Value Stream Layer
The Value Stream layer is a higher level that meets the enterprise needs for very large projects. This layer is coordinating multiple release trains. Questions that are answered on this level are:
- What do we need?
- When do we need it?
- How do we deliver value?
- How do all of the programs work together?
The Value Stream Engineer “conducts” and coordinates the work. The Solution Architect/Engineer and the Solution Managers provide the context for the roles being performed in the Program layer.
The Portfolio layer is designed for true Agile enterprise management. Many organizations are stuck in traditional approaches, which can be a common challenge for teams that are working in an Agile way. Historically, organizations have worked in a waterfall, and it is very difficult to break this habit. The Portfolio layer addresses this challenge by allowing the Portfolio Management, at the enterprise level, to be done in an Agile way. SAFe provides a set of guidelines for looking at the entire portfolio of the work being done, thereby enabling Agile from the value stream engineering down to the Agile team development processes.
Only Implement the Pieces of SAFe That You Need
The SAFe framework is designed so that you only use the pieces that are appropriate for your particular situation. SAFe is flexible in allowing you to use as much or as little as your business needs. For example, a small organization may only need to use the Team and Program layers. Maybe your business only needs the Portfolio and Program levels. Maybe you don’t need the Value Stream level if you don’t have very many programs. Use critical thinking in implementing the roles and layers that will be helpful as you coordinate the product teams in your organization.
You Must Invest in Overhead in Order to Coordinate Teams
In scaling Agile for an enterprise you need additional roles, and this means an investment must be made for the additional overhead and time that is required. Essentially, the top 3 layers of the SAFe framework diagram are overhead. But, in order to move forward and scale Agile, an organization must make an investment, keeping the long-term goal in mind. This is especially true for organizations with old monolithic systems that have many structural issues. An investment in money and time is necessary in the short-term so that the business can become competitive and succeed in the long-term.
Restructure Systems Into Service-Oriented Architecture
A lot of organizations have difficulty staying out of the waterfall and, therefore, are not able to sync their projects. A solution is to deconstruct large projects into smaller pieces of work that are service-oriented. By restructuring large systems into more service-, object-oriented architecture, you can decrease interdependencies. DevOps is a helpful approach in providing techniques you can use to decrease interdependencies and allowing the development of a modular architecture.
Published at DZone with permission of Catherine Perry , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.