Software developers have used Agile since the early 2000s. Since then, Agile frameworks have found their way into other industries such as HR management, marketing, banks, and even governmental institutions.
But what if you can’t get Agile to work for your company? Should you bother trying to get it to work at all?
Nine times out of 10, my answer would be yes, you absolutely should try to use Agile at your company. But it’s not right for every company.
What Is Agile?
What makes Agile frameworks so unique is that they allow you to deliver business value from the very first weeks of product development. They require a strong focus on the minimum viable product (MVP), a product with just enough features to satisfy the core needs of prospective users.
Developers continue to add on to the MVP until the final product is finished and released.
For example, a homepage is the MVP in the development of a corporate website. It’s not much, but it only takes one to two weeks to complete, and you can use it to upload content and attract customers, even if the rest of the website is incomplete.
Agile also calls for regular feedback — and the more frequently you get feedback, the fewer resources go into implementing changes in terms of both time and finances. Essentially, Agile frameworks enable you to make new products faster and cheaper.
Despite all these benefits, I did say I’d recommend using Agile 9 times out of 10, which brings me to the first reason why Agile might not work for your company.
1. Your Business Model Isn’t Compatible With Agile
Agile isn’t universal. Some products, companies, and teams simply cannot work effectively within Agile frameworks. These may include healthcare, financial, or other types of strictly regulated organizations.
These organizations typically develop their products within an already-existing model, so employees usually know exactly what functionality their product will have at the end and what steps they need to take to get there. They don’t expect any changes in the course of development — the whole process is quite rigid.
If your organization happens to be in one of these camps, there’s no need for you to implement Agile frameworks. If you have a very detailed and well-defined specification that you need to comply with, and changes to the scope are not expected, it’s better to use Waterfall, an approach that takes the software development life cycle (SDLC) within successive stages, so the next stage cannot begin until the previous one is complete.
Agile is ideal if you have a general understanding of what the end result of your product will be, but you aren’t quite sure and expect a lot of changes.
If your product is more traditional and you know exactly what the end result will be, develop detailed product specifications and a step-by-step project plan. Stick to more traditional development methodologies such as Waterfall.
2. Your Team Doesn’t Understand the Value of Agile
If someone on your team — or perhaps your entire team — is convinced that Agile has no value, you will have trouble influencing him or her to use it effectively.
If you’re set on switching your organization and product development to Agile, it’s best to do it with people who are as enthusiastic about it as you are and whose personal values are in line with Agile values.
If your staff isn’t as enthusiastic, try engaging an Agile coach. No one can explain the values and core principles of Agile better than someone who is professionally trained to do just that.
The coach will also help implement the practical side of Agile and supervise your team as they’re getting used to working with the new system during the first couple of months.
I recommend ICAgile and Scrum.org certifications. Both organizations keep open registers of certified professionals, so you can do a LinkedIn search to find an Agile coach in your area and check what type of certification they hold and when they received it.
You can also harness the power of networking — ask around to your fellow product owners if they can recommend a good Agile mentor. Just make sure to steer clear of anyone who doesn’t have a portfolio of successfully completed Agile transformations.
3. You’re Implementing the Agile Framework Incorrectly
A close cooperation between business and development is the very foundation of Agile. If the development team is Agile, but the management isn’t ready to invest time and effort in daily communication and regular feedback, then this approach is useless.
When business and development are isolated, the development team doesn’t get enough information to work efficiently, and the management team doesn’t get enough information to adjust the requirements.
This can lead to a vicious cycle of misunderstanding, where no one knows what everyone else is doing, and nothing gets done on time.
So before implementing Agile, make sure both the development team and the management team understand its value and are prepared to cooperate closely on a daily basis. Don’t hesitate to hire an Agile coach if you don’t think you can walk this path alone.
Note that “doing Agile" is not equal to "being Agile." It's very important to make sure that you think of your Agile transformation in terms of "being" rather than “doing” prescribed practices.
Agile is not a specific methodology or a set of rules. It is an umbrella embracing a certain mindset/way of thinking, values, and principles.
Agile methodologies (RUP, XP, Scrum, Kanban etc.) are on the lower layer. They serve as tools you can use while leveraging the Agile philosophy in your business.
You cannot use Agile properly until you know the purpose of this tool, what it does, and the mechanics behind the process.
Another common way of implementing Agile incorrectly is using just some of its practices while ignoring the rest. I’ve worked with a number of teams that called themselves Agile, while in reality, the only “agile” thing they did was having daily stand-ups, or short meetings attendees commonly participate in while standing.
Daily sync-up meetings have great merit on their own, but you can’t expect to leverage the Agile culture fully unless you go all the way.
When adopting Agile, follow the ShuHaRi pattern. ShuHaRi is a Japanese martial art concept that describes the learning stages from beginning level to mastery.
Start with following the principles and practices of the Agile framework you’ve chosen, without any deviations (shu).
Once the team has mastered these, adjust your processes to better fit their needs (ha).
Ultimately, you end up developing a completely original process that works well for you (ri).
Make your process as simple as possible and understand why you're using this practice.
Implement Agile Successfully
If you want to implement Agile, do it right or don’t do it at all.
Of course, the three reasons above can’t possibly cover every product and team. Still, they do make it possible to spell out the three rules of a successful Agile transformation:
- Make sure the Agile culture is a good fit for your business model and values.
- Build a team that aligns with the core values and principles of Agile.
- Transform your whole organization, not just the development team. Both the business and the development side should share the Agile mindset, and be prepared to work in close cooperation with each other.
The Agile methodology doesn’t fit all businesses. In order to check if it suits yours, you need to perform a profound analysis to extract the reasons.
The above-mentioned reasons can help you figure out the possible obstacles that prevent your business from benefitting from Agile.
About the Author
Igor Tkach is CTO of Daxx. Igor is a Forbes contributor who writes about agile development best practices, product management, development team structure optimization, and more. He helps tech companies from all over the world create and run value-driven R&D centers, build robust and scalable business processes, and improve their performance.