Agile is almost synonymous with software development teams – after all, the Agile Manifesto was originally created for software developers. But that doesn’t mean your dev team should automatically adopt Agile practices.
Some types of work aren’t suited to Agile methodology. And even if your work is suited to Agile methodology, your team will likely gravitate to parts of Agile, but not others. You may find it makes sense to adopt a hybrid approach in the beginning – or indefinitely.
In fact, if you picture a spectrum from strict Waterfall to pure Agile, you’ll find that very few teams sit at either extreme.
Curious about where your team might sit on the spectrum? Let’s talk more about the kinds of development teams best suited to Agile and what your alternatives might look like.
Agile is nearly always the answer
Agile involves an incremental approach. Agile teams break up work into small chunks so they can respond quickly to feedback and deliver a valuable, functional product sooner. In 99% of software development teams, Agile works well.
Agile can help your team:
- Stay customer-focused
- Gel and collaborate more effectively
- Organize and prioritize your work
- Deliver value to the end customer faster
Despite these benefits, agile isn’t the right fit for every organization – it’s not always possible or practical. And Agile will look different for different teams, as you’ll need to choose the practices that help you achieve your goals.
When Agile doesn’t work
An alternative to Agile is Waterfall, which is a more traditional project management style. Projects are broken up into stages:
- Planning
- Designing
- Coding
- Testing
- Deployment
As a result, changes are released in a “big bang” instead of in smaller chunks, and they’re released much less frequently (sometimes taking up to 18 months).
There are a few downsides to Waterfall, but perhaps the biggest one is that you risk investing a lot of resources into building a product that’s not valuable to users. This can happen because users don’t have opportunities to provide feedback as you go along, or because the original plans are no longer relevant once it’s deployed.
That said, there is still a place for Waterfall in some software development teams. If you’re working on critical software that needs precise integrity, detailed documentation, and in-depth analysis, Waterfall could be a better approach than Agile. Some examples include software related to:
- Medical or life saving equipment
- Launching a rocket into space
- Processing financial information
In these scenarios, you need a high level of planning. You have senior people (beyond your software development team) who need to sign off on your work before it goes to the next stage. That’s because you can’t make mistakes when people’s lives and livelihoods depend on you getting the system right from the start.
Of course, if you work for a bank, an insurance company, a medical company, or even NASA, it doesn’t mean that Agile is off the cards for you. (There are plenty of banks transitioning to Agile – and not just their software development teams.)
It simply means Agile might be harder to adopt and need more adaptations than if you worked in a lower risk, less critical environment, like developing video game software or a learning management system (LMS).
What it really comes down to is your team. If you can meet your obligations to deliver a safe, working, and useful product, it doesn’t matter whether you do it Agile or Waterfall. What matters is whether your team is willing to adapt, and which style of project management helps them gel. Speaking of adaptation...
Maybe you need a hybrid
I’m seeing more teams adopt a hybrid approach. Usually this means the organization does Waterfall, but the software development team uses Agile to work on problems and features.
I’ve seen this happen in the insurance industry. For example, an insurance company might get hit with a rollout of changes, and they have a legal obligation to implement these changes in their software on a set date. The most practical way to manage these changes is to implement Waterfall across the organization, but allow the teams themselves to work Agile and plan upcoming features as part of their sprints.
Waterfall can work well combined with Agile if the Waterfall component sits above the teams, with an Agile approach at the team level.
You might also take a temporary hybrid approach when transitioning to Agile to minimize disruption to your organization and cash flow. But it’s important to note that while this is a more conservative approach, it can also frustrate your teams, muddy the process, and take a lot longer. You’ll find it tricky to manage dependencies between teams when one team is doing Scrum and delivering small chunks, and another team is waiting to finish a whole project and get sign off before they take on anything else.
There’s no single definition of Agile
Just like cars, bikes, and buses are all different modes of transport, there are different ways to do Agile and get to your destination. The Agile Manifesto doesn’t say you need to do standups or Scrum, but it does say “Individuals and interactions over processes and tools”.
Here are some good places to start:
- Getting your team face-to-face and working on a problem together
- Communicating more often
- Jumping straight in and implementing something of value to the customer
- Daily standups
- Retrospectives
- Scrum
- Sprint planning
- Sprint reviews
Every team will adopt Agile in different ways, and every organization will roll it out a little differently. Agile in itself should be “agile”. So, start with one change that you believe will have a positive impact on your team and be open to further change from there. Meanwhile, continue to learn as much as you can about Agile so you can support your team through the changes.
Learn more about Agile
If you want to go deeper, I can recommend some excellent books on Agile:
- Running Lean: Iterate from Plan A to a Plan That Works by Ash Maurya
- Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland
- The Lean Startup by Eric Ries
Mike Cohn also writes some really great blog articles about Scrum and Agile.
And of course, you should check out our previous blog for tips for building successful agile development teams.
We’ve got more Agile-related content coming up on the blog, so make sure you follow us on Twitter so you don’t miss out. Tag us @joinTiny to continue the conversation on Agile and Waterfall – if you’ve worked both, which do you prefer and why?
