It’s been nearly two decades since the agile manifesto was published, and it seems “agile” is on everyone’s mind. Marketing teams are experimenting with sprints, operations teams are adopting scrum, and HR teams are looking to bring more flexibility into their strategy.
But what about IT? There’s been much debate about which frameworks are best for “agile” to work, but at its core, agile is really just a set of principles to help solve large, complex projects.
To agile or not to agile?
Often, complex IT projects, like say replacing a billing system, require cross-functional alignment. IT teams want to move fast and iterate, but sometimes it feels impossible when you think about all the intake required to pull off a project that affects almost every facet of the business. And, IT teams don’t always have the ability to use an iterative approach when updating the company’s infrastructure or performing “keeping the lights on” activities.
Agile is not about clearly defined requirements and knowing the full scope of work before getting started. But for a large cross-company initiative, the end-to-end requirements and final outcome need to be understood, or else everyone’s systems may go down. So is it possible to apply the agile methodology to such a behemoth?
We think so, but maybe not the agile you’re thinking about.
Remember, agile is not a prescriptive set of rules that everyone has to follow. It’s a methodology, a set of principles and values that teams strive to follow every day. In software, teams often use a framework like Scrum or kanban to guide their work. But for a scenario where those frameworks don’t fit, it doesn’t necessarily mean agile is out, particularly for the build phase of an IT project. It can be as simple as looking at the goal of the project, breaking it down into a small achievable pieces of work, and then iterating and building from there.
Tip
Ready to get started? Check out our top eight collaboration techniques for IT teams going agile.
When waterfall works
So let’s take a look at a real-world scenario that many IT teams have faced: replacing a billing system.
One approach that the team could take, would be to look at one product at a time, building out the systems and features needed for the requirements of that specific product. They’d learn as they went, bringing those lessons to the next round of builds for each new product.
The problem is that the global, system-wide requirements are interdependent, and sometimes contradict each other. Consider situations like purchasing a product bundle and receiving a discount on the licensing fee for a SaaS solution. Or purchasing bulk quantities of multiple products from a manufacturer.
When are these requirements addressed? When you start the scope and build process for the first product? Do you bring in members of the second product team while building the system to address the needs of the first product? What if there are multiple bundling or bulk quantity options, available in different configurations and automatic refill triggers, across five products?
The product-by-product approach according to agile principles starts to break.
The business requirements are the what, and the solution requirements are the how. You don’t necessarily need to use the full waterfall approach and wait to write the first lines of code until ALL of the business requirements and ALL the solution requirements are 100% signed off, but you need to be able to stitch everything together for an end-to-end solution that addresses the business and technical requirements. And you need to confirm buy-in from all stakeholders, which means that your solution needs to be thoroughly vetted and stress-tested for edge cases that might be mission-critical.
This is even more important if you’re in a regulated industry, like healthcare, energy, or manufacturing. Beginning the build phase without checking off the compliance requirements and regulatory boxes is a recipe for disaster, not to mention delays and budget overages.
Inevitably, things will come up once you start building. New systems come online, requirements might shift, and new laws might impact compliance requirements. Thus, the build phase of the project can successfully utilize agile principles to pivot when necessary, while adding incremental value to the business as new systems and features come online.
Slow is smooth and smooth is fast
People are starting to realize that sometimes, you have to slow down to go faster. As IT moves from the old mentality of keeping the lights on to helping the business grow and thrive, they need to think more about building the right things. After all, no matter which approach you take, it’s ultimately about delivering value to your customers.
Like pondering the future of IT? So do we. Discover what Atlassian is doing to unlock the potential of IT teams everywhere.