Agile has been all the rage in software development for many years now. Its popularity exists mostly among smaller teams that iterate quickly and release frequently. Agile software development promotes an environment of rapid feedback and continuous improvement. At its core, it helps teams ship fewer high quality features instead of shipping a bunch of features that don’t quite work. In general, agile is highly regarded in the software development word.
But in some larger organizations, agile is often the subject of much criticism and can be found difficult to adopt. After all, how do you get a big, complicated company to adopt a small, simple philosophy? Larger organizations often struggle to make the agile methodology work for a variety of reasons. Here are some of them:
Agile is a Cultural Shift
Moving away from established rules and procedures can be difficult for large organizations. A big change like this might even require a rigorous change management program. Management needs to get comfortable with their teams organizing their own work. Developers, testers, and designers need to get comfortable working side-by-side rather than simply throwing their work “over the wall”. Everyone needs to share responsibility for the quality of the software.
Communication Breakdowns Across Departments
We’ve all heard of the “silo effect”. In larger organizations where silos exist, failure in communication across those silos leads to an organization that is out of sync. With agile, communication is more important than ever. If your teams are out of sync, your company is out of sync and you’re not functioning as effectively or efficiently as you could be. Focus on communication and you’ll have an easier time implementing agile.
Documentation Gets Left Behind
One of the big principles of agile is less documentation, more work. This can be difficult for large organizations and government organizations as documentation is often required for compliance, legalities, etc. Some teams might employ documentation teams that are responsible for compliance-driven requirements so that the development team can remain truly agile and focus on moving the product forward.
Getting the Customer/Client Onboard
Getting your customer to understand the concept of agile is one thing. Getting them to believe in it and buy-in to the process is another. Some customers see this “new way” of doing things as a risk. As the customer who’s paying you money, they need to feel good about what they are investing in. It’s important to train your customers on agile methodologies – make sure that you set the expectations up front and discuss any concerns to avoid surprises down the road.
Agile is Fragile
Agile is a lean process and therefore it’s prone to breaking down when things don’t go right. Just as your customers need to understand agile, your team needs to believe in agile methodologies. It’s easy to get comfortable with the way things are. It’s easy to avoid change.
With agile, you should always be on the lookout for ways to improve the process, just as you’re always on the look-out for ways to improve the software. Keep your eye out for bottlenecks, weaknesses, and failures. Once you identify them, fix them immediately (e.g. poorly written user stories, flows, tools, team members, etc.).
When implemented properly, agile can truly change the culture of an organization. But it can be difficult for some organizations to adopt due to the reasons I’ve outlined above. Despite the difficulties you may face, try new things and don’t be afraid of change, as hard as change might be. Attempt different “types” of agile, and find the one that works for you and your team.
About the Author
[Jake Bartlett is a software tester and blog contributor for TestLodge where he writes about software testing, culture, and software development. TestLodge makes it easy for teams to collaborate on test documents and report on test results. Try it today to improve your testing process. Jake is also a Customer Advocate at StatusPage and has experience working with software teams on a variety of different projects.]