Lean and Agile Principles for Transformation at Scale

Agile – Roots and Current State

When the concept of Agile delivery was originally designed, it primarily focused on improving software development for small teams where nimbleness and efficiency were more easily attainable. However, with the spread of Agile in the software development community, more large enterprises desired to gain the efficiency and speed associated with Agile teams. Unfortunately for large enterprises, staying nimble and flexible while delivering code is difficult with all the established bureaucracy. However, as Agile has matured it has provided a method for large enterprises to maintain nimbleness and speed for delivering code.

To understand how Agile can improve software delivery for large enterprises, it’s important to understand traditional project management and how it differs from Agile. Most large enterprises use traditional project management guidelines due to strict constraints associated with their projects, which usually impact the entire enterprise. They use these constraints in an attempt to maintain quality in the product they are delivering. These three constraints are the following:

• Scope
• Time
• Cost

In traditional project management, the project team members understand that not all constraints can be met. It’s not possible to have a project fully in scope, within a schedule and within a set budget. Ultimately, the organization must choose between two of the three constraints to maintain success. However, Agile delivery deems the three constraints as enablers rather than constraints.

Jim Highsmith explains these three constraints as enablers in his book, Agile Project Management. In this book, he focuses on enterprise software project work and how it integrates within project management. He presented a new way of thinking about the triangle constraints. He took the traditional constraints and collapsed them into one vertex of a new triangle, the triangle of Agile software delivery. The concept of changing the traditional constraints into enablers lies in the underlying truth that scope and cost are flexible. Ultimately, someone decides what is in scope and what is included for cost. Those two enablers can change within the life of the project. The only enabler that cannot change is time, since it is a constant environmental factor.

In addition, quality, which was originally the goal of maintaining two of the three traditional constraints, is now a vertex of the new triangle.  Quality is no longer the central goal of delivering functionality. Instead quality and value are vertices of the new triangle, with value being the primary vertex/goal of the new triangle. By changing the goal of development to value, it allows for creativity and flexibility in delivering functionality. Essentially, the purpose of the new triangle is to allow an organization with the flexibility to change scope and cost within a certain timeline while delivering quality and value.

The Agile Manifesto’s Principles

In accordance with the new triangle where value, versus quality, is the central goal of delivery, the Agile Manifesto declares that Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This manifesto primarily pertains to software development, since delivering infrastructure relies on the traditional project management principles due to external dependencies and constraints that prevent flexibility with scope and cost. Although, in some instances, it’s possible to adopt Agile principles for building infrastructure/hardware, if the infrastructure/hardware is cross-functional with software and physical components. Adopting Agile methodologies is possible if the initial project is implemented using traditional project management guidelines but software enhancements are developed using Agile principles. This model allows the enterprise to introduce software enhancements to customers early and continuously.

A simplified look at the enterprise

With this overview on the origination of Agile principles in software development, there are practical steps to scale those principles for large enterprises.

To understand how to implement Agile, it’s equally important to understand the three primary components of an enterprise:

• Business Customer. Build requirements, analysis, and design
• Application Development Team. Develop software based on the requirements established by the Business Customer.
• IT Operations, Production Environments, Support. Deliver software to production after the Application Development Team develops the software.

In the traditional model of project management, developers don’t see the requirements until it’s ready for development. Likewise, once the solution is finally developed, the IT Ops teams don’t traditionally see code until it’s ready for test and production delivery. In this model the IT Ops teams are completely disconnected from the business analysis and requirements gathering, which creates dysfunction across the teams involved in the design, build, and delivery phases. 

The underlying issue in this model is that there’s not much alignment between the teams on what is being delivered to customers. As a result, the IT Ops teams become very rigid on allowing change to production. The fear grows over time with IT Ops teams as they encounter production/infrastructure issues that could break current business value. This rigidity to change leads to extensive change management inhibits continuous delivery.

Subsequently, extensive change management slows down the process of providing value to customers, which is the central concept of the Agile delivery triangle. While functionality and development may seem valuable, they have no value until IT Ops delivers the code to customers. Which means that the longer an enterprise takes to establish requirements and develop prior to the delivery phase, the more a business idea can become irrelevant to the market by the time it’s delivered to production.

To prevent this loss in value, it’s important to establish cross-functional teams that have business partners and IT Ops teams part of the development team to ensure we add value in a timely manner. This allows for each team to not only continuously deliver value but to also continuously discover the business needs in frequent delivery iterations. It also reduces the IT Ops fear in delivery, since they are actively engaged with teams during the development process.

Jez Humble’s “Water-scrum-fall”

While the concept of a cross-functional team originated with Agile and is beneficial to quickly deliver functionality to customers, Agile was originally designed to work with small teams of about 8-10 people. In an enterprise where the development teams are Agile, the small team is comparatively small to the rest of the company. Change is welcome at the team level; however, getting to true enterprise agility for the whole delivery process is much more difficult. The issue occurs because the development team is Agile, but the business partners and IT Ops teams are not Agile. Jez Humble coined this phenomenon as water-scrum-fall, because it is an attempt of an enterprise to adopt Agile while still maintaining traditional waterfall practices for delivering code.

In most enterprises, governance enforced by the PMO, Project Team, and IT Ops teams are established to help them manage multiple Agile teams’ deliveries. They enforce tollgates to ensure only value is added and to reduce risk/instability deployed to production. For the Agile team of 8-10 people, they lose some of their ability to execute on Agile principles. The enterprise has deemed those principles less relevant compared to exercising every caution in protecting the enterprise production stability.

If an enterprise establishes cross-functional teams, many of the development activities can gain efficiency with continuous feedback from the Agile development team. The types of beneficial feedback would contain insight into potential functionality constraints, risks, issues, and even benefits. By identifying potential roadblocks and/or value prior to starting development, the development and IT Ops teams could reduce development setbacks that are traditionally discovered due to lack of alignment with upstream teams (e.g., PMO, business partners).

From waterfall, to agile, to continuous flow

By finding areas to limit wasted time and energy, teams can find more opportunities to align on what to deliver to the customer. Instead of business teams using months to prepare business requirements, they should build those requirements with limited documentation (and with the development teams) and the assumption that some requirements are still unknown. When development progresses, the business requirements evolve which is yet another benefit to cross-functional teams at an enterprise level.

Unfortunately for large, complex, and enterprise-wide projects, many enterprise teams have to spend time discovering cross functionalities against the various applications to ensure they integrate correctly with each other. Ensuring integration across applications is one of the greatest challenges to scaling Agile at an enterprise level, but there are practices to address this concern of integration.

Ensuring integration across applications is one of the greatest challenges to scaling Agile at an enterprise level.

Exploration (fast testing) versus Exploitation (Scalability) in the Lean Enterprise

The first type of delivery practice in Lean/Agile enterprise is Exploration. Exploration relies on teams developing quickly, inexpensively, and with disciplined efficiency with the primary objective of providing a minimum viable product (MVP) to customers as soon as possible. The primary benefit is that the enterprise learns more about business needs and explores knew competitive markets since teams are encouraged to explore new functionality.

The second type of delivery practice in Lean/Agile enterprise is Exploitation. Exploitation relies on teams constantly analyzing current functionality and development processes with the primary objective to gain efficiency, competitive advantage, functional stability, and more steady-state methods of successful delivery processes. Teams are more focused on stability and enhancements of current functionalities versus exploring new functionalities and markets. The primary benefit is that the enterprise improves current delivery processes to gain competitive advantage in their current markets.

Whether an enterprise decides to adopt the Exploration and Exploitation delivery practices, the ultimate goal is to just get started using Agile methodologies. Just how Agile teams deliver software in many iterations, enterprises have the flexibility to adopt Agile in iterations. Agile doesn’t require perfection, but it does require continuous improvement.

Phoebe Giglotti