Today, agile is more than a methodology. It’s a marker, an exclusive club, a shibboleth. If you use agile, you’re legitimate. If you don’t, then you clearly haven’t read enough of the Harvard Business Review.
Because of the importance granted to this label, teams often claim that they use agile when, actually, they use parts of it or even just a single feature. There’s nothing wrong with that. Software development teams should use the process that best lets them achieve their business goals and product roadmap.
Most of the time, this process ends up like agile software development. But there are some instances where agile is not the best solution, whether for budgeting purposes or other constraints in the market.
When Agile Is the Best Solution
There are some indisputable benefits of agile methodology, especially for SaaS applications.
- At the end of the day, it’s usually less expensive than traditional development.
- It forces process optimization and innovation.
- It encourages constant feedback and therefore continuous improvement.
- Agile provides the ability to pivot quickly, without “wasting” time and resources on failures.
There are more benefits too, which is why so many users live and die on the agile hill. The above benefits will improve the process for many digital products, but not all.
When Agile Isn’t the Best Solution for Your Product Team
In order for agile to make sense, first, the cost of change needs to be quite low. Second, you need to be able to gather feedback from users in a timely manner. And third, you need the opportunity to be retrospective — to look at the system you’re building and analyze what’s working.
In many cases, these three requirements are not met, and so it’s necessary to explore non-agile options of development. Here are some possible scenarios where that might happen.
Iteration or Deployment Costs Are High
Iterations occur every two weeks in a standard agile environment, but this requires iterations to be inexpensive, which is not always the case.
One example might be hardware integrations.
If you have a software component for a piece of hardware, you have to take into account the components of the hardware and build the factory around it. If you switch components, then you must rebuild your factory, which is not cost-effective.
Similarly, if the hardware is not connected to the internet (for example, an electronic bike or medical device), then deployment costs are high. Choosing to deploy often will leave users fragmented on different versions of the same software, increasing the costs associated with supporting those users.
One more example is anything that requires approval from government agencies, like the Food and Drug Administration. Any changes made after an FDA approval will require another round of approval, which is incredibly time-consuming and expensive.
What to Do Instead: While not ideal, your product team will need to strategically build a product roadmap that considers iteration and deployment restrictions. Measuring the success of an annual update, for example, is difficult and can blur return on investment (ROI) calculations. In cases like these, you’ll need to create an iteration and deployment process that serves your team and product.
You Can’t Gather Timely Feedback
The idea of feedback is useful, but if it’s too expensive, then it’s not able to fit into an agile process.
Take the electronic bike example again. Because purchase patterns and use cases are so scattered, you might not be able to collect timely or consistent feedback.
What to Do Instead: Ask yourself if there are proxies for the customer. Can you build and run an automated test? Is there a simulation you can run based on the hardware’s chemistry? Tests and simulations can certainly help you gather productive feedback on your software’s experience.
You Can’t Be Retrospective
Even in pure agile environments, retrospectives aren’t easy.
People can be dishonest or complacent, going through the motions without providing any real insight. Throw additional layers of remote work and hierarchy on top of that and your retrospective is no longer valuable.
What to Do Instead: Whether you do traditional retrospectives or not, it is essential to discuss what worked in your process and what didn’t. Find a process that works for you and implement it. Encourage everyone to speak up, break out into smaller groups, or create prompt questions to increase participation.
Ultimately, Find What Fits for Your Team
Today, agile is mostly a word. What’s important is finding a process that works for your team, product, industry and legal limitations.
Traditional agile development ceremonies are formalizations. Oftentimes, they miss the point if agile becomes burdensome.
Instead, take a step back and analyze your unique environment. Ask yourself how your process could be improved. If it’s with strict agile ceremonies, great. But if you must veer from scrums and two-week iterations for business reasons, don’t be afraid to do so. After all, the entire agile methodology is based on finding the best possible process, no matter what.
