It's been more than two decades since the Agile Manifesto was signed. In that time, agile went from a philosophy of how to do software development to a globalized product. Since that signing, the need to support agile software development has expanded beyond the use of a single team of five to 10 people. We're talking about distributed agile software development—in other words, agile in an enterprise environment.
At the enterprise or corporate level, there are competing needs between agility and stability, flexibility and consistency, distribution and centralization. While developers may have used a traditional or waterfall SDLC to address the latter of these word tuples, it generally failed to address each former concern. While the need for speed, agility, and quality is evident, can agile software development work in an enterprise or corporate level environment?
In this post, we'll explore this topic further. But first, let’s take a brief look at the traditional SDLC and agile in turn.
SDLC in Broad Strokes
Generally, an SDLC (software development lifecycle) refers to the entirety of a software development project. It's usually mapped along the path of any other type of project, which goes a little like this:
Inception: identifying some opportunity using a SWOT analysis or another tool.
Analysis: assessing feasibility using a cost-benefit analysis, including cost estimates.
Funding: securing a budget and/or funding and/or resource allocation for the project based on estimates given in #2.
Planning/Design: creating the software’s specifications.
Construction: developing the software.
Testing: validating the software to ensure it meets the specs created in #4.
Security: performing a security review or passing some kind of security gate.
Documentation/Review: delivering (and likely writing/finalizing) documentation for operations.
Deployment/Delivery: passing the working software to the operations team or customers along with the documentation on how to deploy and operate the system. This may have been on physical media that the operations team used to install the software onto a mainframe, server, or workstations.
Operations and Maintenance: keeping the working software running with occasional updates.
Retirement: taking the software out of operations and archiving data as needed.
The software development process doesn’t always follow these steps in every organization, but generally, at least some kind of similar iteration is involved. You may even think of the SDLC as being synonymous with the waterfall style of applying these steps. (After all, the waterfall approach follows these steps in order.) Other methods may iterate over some steps, or in some cases, use a different order. For example, the original agile approach performed much of the design and testing during the construction stage.
Let’s take a brief look at agile.
Agile in Broad Strokes
An agile team uses the principles of agile software development to produce working software in increments. An agile team may adhere to any of a number of methodologies or processes. Two of the most notable include Extreme Programming (XP) and Scrum.
In XP, teams of software developers work in pairs at one computer. They pass the keyboard back and forth, taking turns writing unit tests, then code to make each one pass. They effectively design, test, write, and review the software in real time.
Scrum is a household name in software development. The main points of the Scrum methodology are as follows:
Use teams with three roles to deliver software incrementally. The roles are:
Scrum master—coaches and coordinates but doesn’t manage.
Product owner—represents the customer/business.
Team member—makes the software.
Work in increments called sprints (usually two weeks).
Take a day or two at the beginning of each sprint for planning.
Commit to certain work—and only that work—for each sprint.
Meet briefly each morning for a “stand-up.”
Take half a day at the end to present the final product.
Meet at the end of the sprint in a “retrospective” to discuss how to improve.
Being agile takes discipline, practice, skill, dedication, commitment, and a high degree of intrinsic motivation. After all, the team is wholly responsible for delivering working software; therefore, its members must be capable.
Agile software practices are meant to deliver working software in short increments. Its main benefit is delivering some kind of value as soon as possible. The problem is the original agile methods were meant for single teams rather than large-scale projects with multiple teams. It also doesn’t hold up to the need for consistency, integration across multiple products and teams, or functional divisions within IT departments. In short, agile couldn’t scale without a bit of help.
Agile and the SDLC in an Enterprise or Corporate Environment
Agile development is meant to deliver change quickly. This is seemingly in direct opposition to the theory that management is about stability and control. Instead, change is the domain of leadership. So you might think agile means too much change to manage effectively. However, change is a constant. Agile practitioners develop a discipline that can deliver stable change consistently. Feeding into the discipline is the mindset of continuous and gradual improvement through regular introspection.
That said, agile is great for those who are ready to embrace change and continuous improvement. Those who use its quick delivery cycle can experiment, learn, and pivot with the market. Some divisions or departments might benefit from using agile practices; however, it's also possible to have the whole organization going in the same direction at the same pace. My jaw dropped six years ago when a program manager from a large enterprise said their whole organization was working in the same sprint cycle. (Even the sprint number was the same across the whole organization.) Something like that requires top leadership support—transformational leadership preferred. So what does this have to do with agile and the SDLC?
Large Organizations and Agile Mismatch
Large organizations typically divide resources along lines of specialization. Functional departments such as database administration, integration, information security, and operations create a structure for task breakdown, specialization, and distributed workloads. They also create myriad opportunities for resource contention that can reduce agility.
In an agile environment, the team does much of the project work rather than having it distributed to specialists in separate groups. This is one major paradigm shift that will tend to prevent an organization from realizing agility through the original methods. Going agile may require changes to the structure of the organization to clear up resource bottlenecks.
Another approach could be to use technology to automate much of the delivery of working software. This line of thinking influenced the rise of DevOps.
DevOps Enables Agility
The DevOps movement arose out of the need to support agile software development. It provided the glue between large companies and agile. Even now, it’s encompassing more and more of the lifecycle of software development. Using DevOps concepts, agile enterprises can enable more stable, secure, and rapid software delivery cycles, pivoting with the markets and de-risking change.
Since DevOps enables agile to work through more of the SDLC, you might think the story ends there. Every organization is different, however, and the solutions aren’t one-size-fits-all.
Options to Fit the Context
There are many flavors of agile and lean processes, including à la carte selections, that lead to a cobbled-together process that may not work in practice. It's not always intuitive, either. Antipatterns and pitfalls exist. Thankfully, thousands of hours were put into making decisions more fluid with tools and models to help shape the enterprise agile environment.
Two notable enterprise agile models are SAFe (Scaled Agile Framework for the Enterprise) and DAD (Disciplined Agile Delivery). These are both rather complex systems that are designed with enterprise organizations in mind. Successful implementation requires nuanced coaching, training, and support. These models deserve their own dedicated articles—if you are considering going agile in your organization, you may be interested in seeking out resources about each of them.
Conclusion
The scope of agile has certainly changed over the last two decades. It grew from something for a small set of software developers working on software construction to an enterprise-sized model for dealing with constant change. There are prescriptive methods for how to be agile, and there are tool kits that help make choices about what works in your environment. Change is constant, so instead of trying to limit change, allow change to occur in a stable fashion. While agile practitioners value people and interactions over processes and tools, they still use the latter two to enable constant and stable change to occur. Agile principles can be an integral part of the entire SDLC—and more!
This post was written by Phil Vuollet. Phil leads software engineers on the path to high levels of productivity. He writes about topics relevant to technology and business, occasionally gives talks on the same topics, and is a family man who enjoys playing soccer and board games with his children.
Additional Resources
Download the whitepaper: The Definitive Guide to Modern Software Delivery