Making “agiLE” Work

AgiLE: Summary of Approaches to Scaling Agile in the Large Enterprise

Over 80% of organizations are implementing agile approaches now and that number is increasing every year ^[6]. Many of those organizations have hundreds or even thousands of members on their IT teams. The challenge these enterprises are facing is that many agile approaches aren’t designed to scale, or at the very least don’t give many guidelines for scaling. Even the agile manifesto principles that work well at the team and delivery levels do not really address what to do on a large scale.

The trend of moving to agile approaches in large organizations has created a demand for approaches that scale. There are numerous approaches available, leaving many agile transition teams confused as to which approach is best for their organization. This summary of frameworks focuses on the most commonly encountered approaches, according to a Gartner study on scaled agile approaches ^[3] and our own experiences working with F1000 organizations trying to scale agile.

What Is AgiLE?

AgiLE is not a typo! It’s our shorthand name for agile in the Large Enterprise. We are working with customers who are scaling agile approaches from the team level to the enterprise level. Some common issues that we see when teams try to scale are related to dependencies across teams, finding common ways to share information and collaborate across teams, dealing with distributed teams, ensuring user stories are written and prioritized to provide business value, business stakeholders that are not aligned to or are untrained in agile practices, formalized or regulated processes, and non-iterative funding models.

Summary Comparison of Scaled Approaches

There are many ways to scale “base agile”, all of which claim to cover the typical pitfalls associated with scaling agile like distributed teams and just in time requirements gathering. While that is true, there are still strengths and limitations for each approach. Scaled Agile Framework (SAFe) is by far the most commonly deployed approach in industry. However, SAFe is also the most rigorous approach and may not be a good fit for many organizations. Disciplined Agile Delivery (DaD) is another large player in the scaled agile stage; however, our evaluation didn’t find a consistent answer as to which industries commonly use DaD. Large-Scale Scrum (LeSS) seems to have higher adoption in the financial industries. And Nexus is still too new to determine which industries will adopt it.

Exhibit 1 describes each of these scaled agile approaches using a common set of “levers” or determining factors for when to use each methodology. This table is not meant to be a thorough decision table; rather, it helps narrow the choices for a final assessment of the scaled approaches specific to your organization.

Approach	Total IT Teams	Agile Type	Maturity Required	Overhead	RE Suitability
SAFe¹	15+	Any	Advanced	High	High
LeSS⁵	2–8	Scrum	Beginner	Low	Medium
DaD²	15+	Any	Advanced	Medium	Medium
Nexus⁴	3-9	Scrum	Medium	Low	Medium

In the exhibit above, total IT teams represents the ideal number of teams for each approach. The number of teams is something to take into consideration if the IT organization has hundreds of agile teams. LeSS or Nexus may not be sufficient approaches on their own if there are many agile teams, though each has its own way of adding a higher level to allow for additional scaling. Some scaling approaches only work well with Scrum and others can be adapted for Kanban, Scrumban or any other combination. The maturity required column in Exhibit 1 focuses on how good the teams should be at base agile before they try to scale it. Some approaches, like SAFe and DaD, assume some level of engineering expertise in agile with automated builds and deployments that not all new agile teams have. The overhead column refers to the number of people it takes to coordinate the teams on a relative scale. And finally, the Requirements Engineering Suitability is a relative measure of how much of a focus each approach has on the backlog, product ownership, product management, business analysis or user stories aspects of agile.

SAFe – Scaled Agile Framework

SAFe is by far the most adopted or considered of the scaled agile frameworks today. According to a Gartner study, 45% of respondents had either considered or implemented SAFe ^[3]. It has the most layers of working teams so, in theory, SAFe can scale to any size. However, these layers, along with new terminology, make it complex to adopt quickly.

SAFe works in four layers, from the top down: portfolio, value stream, program, and team. Each layer has its own group of stakeholders working in that layer and a backlog from which they are working ^[1].

Portfolio Layer

The portfolio layer is the highest enterprise level of SAFe. At this level, all the strategic themes for the company are assessed, ranked, and given a budget. From there, business-level epics and enablers are identified for the highest-level backlog. At this level, enterprise architects and portfolio managers guide the entire enterprise.

Value Stream Layer

This value stream layer is new to SAFe 4.0. Because it is new, it is less well understood to many practitioners. A value steam is a collection of release trains, or programs that all work together toward a single vision or roadmap for a set of products. The value stream team gets a budget based on the portfolio-level planning and the assigning of the epics from the portfolio layer, plans architecture in advance, and coordinates across multiple release trains.

Program Layer

The next level is the program layer, where many individual teams are grouped into a program. The program layer contains the agile release trains that roll up to the value streams that roll up to portfolios.

Typically, programs are a single, large project being worked on by eight to 15 teams (or around 50–125 people), but they could also be multiple projects that need coordinated releases. The teams in one program create a release train that coordinates sprints/release dates to release a program increment together. At the beginning of each program increment, the release train gets together for program planning to come up with the program increment objectives, decide what will be built and assign epics and feature that support the program increment objectives. Usually, this meeting is two days long. At the program level, there is a steering committee that guides the overall release train and ensures that all teams in the program are working toward the same goals and release dates.

Team Layer

The team layer of SAFe works just like any one team of any agile approach. This is usually a team of six to 10 people to produce a usable product.

LeSS – Large-Scale Scrum

LeSS was one of the first scaled agile frameworks. It scales from one Scrum team by adding an additional layer (like Scrum of Scrums). It works best in a context of two to eight Scrum teams working in concert to create a single product. In LeSS, there are individual Scrum teams with developers, ScrumMasters, and product owners or proxies for the product owner. Over the collection of teams, there is a single product owner for the overarching product who will create and maintain the product backlog with help from the teams. All teams, also called feature teams, within the product will work on the same sprint schedule and pull from the same product backlog to deliver concurrently ^[5].

There are two parts to sprint planning. Part 1 is where all teams meet together with the head product owner to determine what will be built by each team in that sprint. Part 2 is where the teams meet individually to determine how to build the chosen user stories for that sprint. Similarly, there is one sprint review where the head product owner and customers can approve or accept the work as “done” from the common definition of done.

DaD – Disciplined Agile Delivery

DaD is tailored specifically to help enterprises scale their current agile processes. DaD focuses on the delivery of a product across the entire product life cycle, from inception to end of life. It works across any of the agile team-level approaches, including Scrum, lean, Kanban, or lean startup ^[2].

DaD places great emphasis on the people working on the product and adds a few roles to the mix from traditional Scrum or generic agile. In addition to the standard ScrumMaster, product owner, and team member roles, DaD adds an architecture owner (who makes the architectural decisions), specialists (who can be brought into teams for short periods of time for specific needs), subject matter experts (for other parts of the organization that the product owner brings in for specific questions to help with user story creation), technical experts (for specific pieces of projects), and independent testers and integrators (who typically work with large teams to enhance and supplement the team testing and integration). These additional roles are mainly for scaling the agile practices across many teams as these roles take a broader view of the organization and the architecture involved to ensure that all teams are delivering the same goals.

Additionally, DaD starts off with a goal-centric approach. This goal-centric approach provides the framework for making the decisions about the agile process. For example, responding rapidly to stakeholder changes could be a goal (a goal that all agile approaches try to solve) and continually maintaining Scrum backlogs are one way to satisfy the goal. There are other ways that an agile team could satisfy this goal, but by putting the goal at the center of the decision-making process, DaD aligns all work to the goals or objectives of the organization.

In terms of scaling to the entire enterprise, DaD contains three levels of operation and emphasizes technical excellence at every level by building DevOps into delivery. At the lowest level is IT delivery, which consists of individual teams creating shippable products. The next level is disciplined DevOps, which coordinates releases across the various teams and ensures technical excellence in each team (similar to the program level in SAFe). Finally, DaD has the organization level, which includes everything else that impacts development, including product and portfolio management.

DaD is more adaptable than most other frameworks for fitting an already established agile ecosystem. However, that adaptability can be a double-edged sword for enterprises that are not well versed in agile prior to scaling, as it is not always clear which elements of the approach should be adapted.

Nexus

Nexus is similar to LeSS in that is it most suitable for three to nine Scrum teams and is effectively a scaled Scrum approach. In addition to the Scrum teams, Nexus introduces an integration team, which focuses on ensuring that all the teams’ work can be integrated into a single integrated increment. The integration team coordinates, coaches, and supervises the application of Nexus across the various Scrum teams and is a full team itself, with a dedicated product owner, ScrumMaster, and team members ^[4].

Similar to LeSS, in Nexus all teams work off of a common product backlog and do sprint planning to select the work for the common sprint. However, whereas LeSS teams just pull off their stories into their respective sprint backlogs, in Nexus, there is a Nexus Sprint Backlog, which includes all user stories across teams in a sprint regardless of teams and the tasks associated to them. This is so that the teams and tasks can be coordinated into the sprint as well as their product backlog. Nexus also adds a Scrum of Scrums, called a Nexus Daily Scrum, to coordinate across the teams in a sprint. Nexus has a common sprint review across the teams, but does sprint retrospectives individually before coming together to review all the retrospective info as a nexus.

Scaling Challenges and Suggestions

Across the different scaled agiLE approaches, there are shared obstacles that large companies must overcome when transitioning, regardless of the framework selected.

One of the most common challenges for large enterprises transforming into agile is the distribution of teams. Large companies are global, and the constant communication between team members necessitated by agile is almost impossible to accommodate. Sometimes teams are spread across different languages and time zones, so communication is limited. Because all agile teams must understand what they need to build during each sprint, this communication difficulty can lead to more time spent grooming user stories and longer sprint planning sessions. Without communicating face-to-face, it becomes hard for teams to self-organize and get tasks done. Tips to ease this barrier include providing more granular user stories, especially ensuring acceptance criteria is robust, planning more time in advance for grooming and sprint planning sessions, collocating teams for short bursts of time, and finding a common time for all team members to have a daily chat. For example, with many of our customers, we have separated sprint planning and grooming, with grooming occurring each week in advance of planning to ensure that each sprint is fully groomed and sized before planning and that planning is focused on allocating stories and tasks for the sprint. Additionally, alternating when the standup is held is a good way to include all distributed members of the team. Perhaps for one sprint, it is easy for the team in the US and the next sprint it is held at a time good for an India team. Finally, if budget allows, co-locating the entire team (even for just one sprint) helps build team bonds and increases the self-directedness of the team.

Often, in the race to be agile and to develop quickly, teams skip doing the analysis to understand the business pain. This is a mistake, for while business stakeholders are more involved, the right level of analysis still needs to be done to ensure that the teams are delivering value. Experience on our projects is that there is up to a 6-week lead time for a single user story from inception to being ready for development, depending on the complexity and if there is user interface or other detailed work to be done. One idea is to implement something like a “sprint zero” or “sprint 0” before development work begins that is 2-6 weeks long, depending on the length of the program, product or project. In this sprint 0, the initial analysis happens, and the high-level epics and features are defined and prioritized. The goal of this sprint should to have enough user stories groomed to get started with the first two sprints. If 6 weeks feels like too long of a duration, teams can also initiate a sprint 0 at any time during a project to catch up on analysis. During these sprints, the dev team is not idle; they can work on technical debt items, defects, as well as providing input to the analysis process.

Another common occurrence is the disapproving business stakeholder. Disapproving business stakeholders are accustomed to traditional methodologies and are having difficulty grasping agile because there is no implicit contract of what the team will build for them. They often feel like they are losing control of the process when moving to agile because there is no Business Requirements Document (BRD) or equivalent. They are busy running their business, but want to be involved in every decision made by the team. One solution for dealing with these types of stakeholders is to educate and establish with them their agile responsibilities before a project begins, so they are prepared for the project. In addition, include them in the decision-making process about the agile approach so they have buy-in to it. It’s important that their managers and executives also buy in. With enough persistence, communication, and patience, business stakeholders will understand their role in agile, and even grow to appreciate how agile approaches can help them. As an additional interim measure, teams could create a BRD lite (we use one called an Agile Requirements Document- or ARD for short) in which the business stakeholders can express their needs in document form while also starting to break the contract mentality of the BRD by adding notes like “These stories will go into the backlog for prioritization, but not necessarily built.”

Similarly, sometimes the teams struggle when there are executive mandates to switch to agile approaches. Top-down agile directives are usually not successful without supporting the team to learn the concepts, and bottom-up directives cannot work without executive buy-in. Before instituting agile approaches, executives should begin the organizational road show of espousing agile’s benefits so that everyone affected understands their new roles. One successful method of implementing agile is to generate buy-in from the tactical teams, run pilot projects to create champions, and then expand and support the new teams with training and coaching.

Dependencies between teams can wreak havoc on organizations. One common dependency early in the transformation is between agile and waterfall teams. If a waterfall team is dependent on an agile team, they want to know up front what they are getting and when from the agile team – which is contrary to the way agile approaches deliver. Similarly, there are issues if an agile team is dependent on a waterfall team, because they will likely hit a roadblock in delivering working software that requires functionality from the waterfall team – because the waterfall team delivers all or nothing at the end. In these cases, the best tip is to identify any potential dependency situations early and find ways to work around or remove them, maybe through the BRD lite or ARD mentioned above. It is hard to do anything once teams are stuck, which is why some scaling methodologies, like Nexus, have specific teams to address integrations.

Once all or most teams are agile, there are issues with dependencies between agile teams which can be even more difficult to overcome since neither team in the dependency necessarily has the requisite line of sight to the issue in time to coordinate, get a story in the other backlog, groomed, prioritized and completed when the other team needs it done. SAFe addresses this through quarterly program layer sprint planning sessions where all teams impacted attend, map out stories for 3 months, and identify the dependent teams. Even without that, if the product owner or business analyst can get 2-3 sprints ahead in grooming, it becomes easier to see and mitigate the dependencies. That sprint 0 time becomes even more important!

Organizations with strong project management offices (PMOs) can find themselves struggling in agile transitions to understand how that level of rigor applies. In fact, agile teams can feel extreme frustration in dealing with PMOs that have not evolved for agile approaches. Some PMOs are used to having formal gate process checks to ensure that teams are far enough along before they move to another phase. This won’t work in agile approaches, though. PMOs can adapt by figuring out what level of thoroughness is appropriate, such as creating definitions of done or definitions of ready. They can help agile teams understand and follow agile processes as well. In many cases, a strict adherence to process is needed for compliance or regulatory reasons. In these situations, PMOs can help drive how to adapt those practices to agile.

A final common peril for large enterprises transforming from waterfall to agile is the continuation of waterfall funding while delivering in an agile fashion that has no guarantees. Fixed budgets can work for newer agile teams and where executives have not fully bought in. This funding model allows them to easily forecast and focus on only the critical features – but teams have to stop when funding runs out, no matter what is built. Continuous funding budgets are better for more experienced agile teams and organizations because they allow teams to work on more than just the critical features of a product as their ability to forecast becomes more evident over time. However, continuous funding models require a great deal of trust between the business, the implementation team, and the executives. SAFe has tried to address this by implementing the idea of “value streams” where a portfolio continuously funds streams that deliver common sets of value.

Final Thoughts

This sounds like a daunting task – to transition to agile approaches in a large organization. However, with solid collaboration and communication, it’s absolutely doable. Teams will constantly be collaborating through elicitation, answering questions, and testing the actual product. Business analysts have a critical role to play in keeping the collaboration running smoothly, including helping to facilitate backlog grooming and elaboration, participating in planning in sprints, working with interfacing teams to identify dependencies, and serving as a product owner proxy on any teams as needed. Likewise, project and program managers can act as advisors about appropriate levels of process, help guide projects toward common goals, and ensure a focus on prioritization based on business needs. Instead of instilling a hierarchical control between PMO and product owner, in agiLE the PMO and product owner work together to achieve the objective. The real goal for agiLE teams is self-organization and creativity, while still contributing as a part of a large organization.

References and Literature

• [1] A Scaled Agile, Inc. SAFe® 4.0 Introduction. Retrieved from http://www.scaledagileframework.com/. 2016.
• [2] Disciplined Agile Consortium. n.d. Introduction to DAD. Retrieved from http://www.disciplinedagiledelivery.com/
• [3] Holz, Bill. Gartner. Agile in the Enterprise. 2015.
• [4] Schwaber, Ken. Scrum.org. Nexus™ Guide. Retrieved from https://www.scrum.org/Portals/0/NexusGuide%20v1.1.pdf. 2015.
• [5] The LeSS Company B.V. Less Framework. Retrieved from https://less.works/. 2016.
• [6] VersionOne, Inc. The 10th Annual State of Agile Report. Retrieved from https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf. 2016.