According to the RightScale 2017 State of the Cloud Report1, 78% of enterprises will be implementing DevOps in 2017. Deployment frequencies will be increasing from months to minutes. As Agile development becomes more predominant, the speed to production is quickening.
On the surface, that seems like good news. But there’s a problem.
In the modern-day fast-paced development cycles, documentation and system requirements development is often neglected. As a result, many of those fast-moving Agile development teams have no clear picture or roadmap of where their project is going, and what it’s expected to accomplish.
Or to put it a bit differently, these fast-moving development teams are quick to production and quick to failure.
Agile Speedbumps
How did Agile come into existence? Agile was born when we began to realize that the monolithic programs of the past with their hundreds of pages of detailed requirements, requiring years for huge teams to create, were often obsolete before they were even finished.
Businesses needed a faster pathway to software implementation. Agile provided that faster pathway.
Instead of looking years down the path, the Agile approach looks only one sprint down the path addressing a few of the most important requirements. Development teams work only on what’s needed for successfully accomplishing that single sprint goal. Continually repeating this process allows the team to frequently and repeatedly adjust to changing markets and business needs — with the project sometimes ending up on a completely different road than originally envisioned.
But the Agile process has been taken to the extreme by many organizations. Some even consider it taboo to look any further down the road than the current sprint. These teams have not defined a roadmap and a solid foundation for the project to be built on.
This short-term view leads to un-necessary rework, more complicated sprints, and an overall slowing of the Agile process. Indications of these problems can manifest in sprints requiring lots of re-writes, or sprint changes that become progressively more difficult and require increasing amounts of time to completion.
Whereas a proper roadmap defines the user functionality that is sought, the system requirements define the foundation for the roadmap. When these requirements are tailored for Agile but based on the old Waterfall methodology, they can finetune your Agile process into the speedster you originally envisioned.
Is Water Falling All Over Your “Agile” Project?
In terms of popularity, it’s safe to say that Agile has supplanted the Waterfall software development methodology. In my experience, though, many so-called Agile projects are Agile in name only. In fact, it’s not uncommon to find projects that look and act like Waterfall but are called Agile.
Why?
It’s partly because Agile is the ‘in’ thing right now. But labeling a de facto Waterfall project as Agile is also often used as an excuse for skimping on requirements development.
No Sense in Driving Blind
Yes, Agile is about speed. It’s about trimming weeks, months, even years off the development lifecycle. But no matter how fast you’re moving, if you don’t know where you’re going, you’ll get nowhere in a hurry.
A fitting analogy for an agile project is the construction of a building.
Before the first shovel of dirt is turned and the first drop of concrete poured, the builders know whether they are building a family home or a skyscraper. They don’t start out just frantically building a foundation as fast as possible, without knowing the type of building the foundation will support.
Will it be a single-story house? Will it be a ten-story office building? The builders know what they are building before they start; they don’t figure it out on the fly. Any other approach would result in a disastrous failure.
A software development project is the same. There must be a blueprint in place, a roadmap (system requirements) to tell the development team what they are building, at least in general terms. To do otherwise — and many development teams have experienced this firsthand — risks ending up with a finished product that doesn’t meet users’ needs.
An Add-On or a Whole New Building?
It makes a difference, of course, whether you’re adding new development sprints to an existing project or starting a project from scratch.
An existing project already has a foundation in place. The development team (hopefully!) has an understanding of the ultimate goal of the project. So as new development sprints are initiated for the project, the requirements can more fully address the specifics of each individual sprint, with less focus on the project as a whole.
But a new project MUST address long-term requirements. And those requirements MUST convey the ultimate goal of the project. Following a planned strategy and vision of where you want to go is key. This stage of the project, after all, is where you’re developing the foundation for the entire project. Just like constructing a building: If you get the foundation wrong, the finished project will not fulfill objectives and expectations — no matter how fast you get to the finish line.
Plan Ahead to Get Ahead
Achieving success with an Agile development project requires the following three keys:
- A vision of where the project is going
- A foundation upon which the project will be built
- Ongoing guidance for current and future sprints
The first of these keys, vision, should provide a view of the ultimate goals of the project. This original vision will be updated and modified as needed throughout the project lifespan. The vision will be conceptual and should be highly specific for the near-term stages, but less specific for later-term stages. Ultimately, this vision should be used to assure that each individual sprint supports the ‘big picture’ overview of the project.
The foundation serves as the base of the project, both initial and ongoing. Early on, it’s important that the foundation defines a system that maintains flexibility, and that doesn’t limit possibilities. And specialized functionality should always be pushed as far down the implementation path as possible. Building specialized functionality support into the foundation may cause catastrophic, unforeseen ripple effects.
Ongoing guidance for the project should support sprint planning for two to four sprints ahead. To accomplish this goal, requirements must be developed at least a step or two ahead of development. Requirements availability should enable development to make wise decisions that will support the building of current backlog items that will, in turn, support future backlog items.
It’s also important to ensure that the backlog contains a list of must-do items — not just a duplication of the requirements list. The requirements should provide an overview that helps to pull things together, takes into account interdependencies, and supports building a complete system that works together. A backlog, conversely, contains standalone items which do not account for how each item impacts and meshes with the rest of the system.
Just Looking for An Excuse…
As someone who has been involved with software development for decades, I get it: Documentation and requirements development can be a tedious process. And as with any chore that’s less than exciting, people often look for a way to get out of doing that chore.
That’s happening more and more frequently with requirements development. People are often looking for an excuse for skipping (or skimping on) that task.
Ask why the requirements are being dumped, and — to borrow a famous line from the movies — the response might be something like this: “Requirements? We ain’t got no requirements. We don’t need no requirements. I don’t have to show you any stinkin’ requirements! After all, we’re doing AGILE development!”
But the truth is that we really do need those stinkin’ requirements — and that will never change.
Works Cited
1. Flexera https://info.flexera.com/CM-REPORT-State-of-the-Cloud
