Business Process Team

The Agile (Communication) Revolution

September 27, 2019
The Agile (Communication) Revolution

There have been a number of recent articles documenting Airbus 737 Max failures. Coming from an aviation engineering background, I am fascinated by mainstream coverage of a world I inhabited for years. One article in particular caught my eye. Bloomberg ran a piece on Boeing’s practice of outsourcing aspects of software development to less costly developers in other countries; the implication being that the practice was partially to blame.

Outsourcing is an ongoing topic as companies seek to save on what is inherently an expensive part of the product development lifecycle. When you consider the numbers, it’s easy to make a case for the international outsourcing of software development. If you can find someone to perform at a fraction of the cost, why wouldn’t you? Even if that developer is only half as productive, you still come out ahead.

Research suggests that there is a considerable range of productivity among developers. While there may be disparities in talent, I believe there’s an even more important reason to think twice before outsourcing. It’s a lesson that has less to do with the person actually writing the code and more to do with the outsourcing process itself.

If there’s one lesson I’ve learned over my career, it’s that handing developers a requirements document and expecting them to build to spec is a recipe for failure. Whether that person sits next to you or halfway around the world, there are often two main issues:

  1. The requirements document is incorrect.
    Requirements documents often assume one has learned all there is to know during the requirements gathering phase and are adequately prepared for implementation. The Agile revolution is built on the (often correct) notion that you actually don’t have all the answers—and even more importantly—that no single person can know everything at the start of the project. Instead, we iterate in learning cycles, experimenting and incorporating new findings into the product.
  2. The requirements document is insufficient
    Even if you presume requirements can be gathered up front, you still need to thoroughly communicate them to an external team. In my experience, frequent conversations between the development team and stakeholders are the only foolproof solution.

The crux of the problem is communication. By choosing to outsource, channels of communication are often formal and immutable (requirements document, legal documents, etc). Language barriers between the stakeholders and the development team also get in the way. While this can be overcome with the right structures in place, it adds a layer of confusion. And, even if you address the above challenges, teams are in a different time zone, on a different continent, and generally less available to chat. All of these conspire to make communication the greatest detractor to international outsourcing.

So what is the alternative? We can’t change the fact that organizations are increasingly turning to remote forms of collaboration, either across the country or across the world. The question is how to overcome the inevitable gaps in communication.

Heavily regulated industries lean towards formal requirements for good reason. We need to determine how best to improve upon them. We also need to come to the realization that documents can no longer be the sole method of communication. Well-documented conversations are an equally essential component. Or perhaps even more essential. As the Agile Manifesto makes clear: “Individuals and interactions over processes and tools.” While processes and tools offer value, individuals and interactions create even more.

Joshua Hulst
Joshua Hulst
Co-founder & Managing Partner

Looking for more like this?

Sign up for our monthly newsletter to receive helpful articles, case studies, and stories from our team.

Build vs. buy: How to decide between custom software, off-the-shelf, or hybrid solutions
Business Development

Build vs. buy: How to decide between custom software, off-the-shelf, or hybrid solutions

October 9, 2024

Deciding whether to build custom software or buy off-the-shelf involves weighing factors like cost, flexibility, and scalability. While off-the-shelf solutions are quick and affordable, custom software offers more control and long-term adaptability. Sometimes, a hybrid approach combining both options can be the most effective for a business’s unique needs.

Read more
Business Model Canvas: Helping business leaders create meaningful digital products
Business Process

Business Model Canvas: Helping business leaders create meaningful digital products

January 17, 2024

When it comes to custom software, it’s easy to feel stuck between needing to deliver value quickly, while also ensuring meaningful, long-lasting results. Learn why the Business Model Canvas can help you identify the right digital product for your business needs.

Read more
Between the brackets: MichiganLabs’ approach to software development
Development Team

Between the brackets: MichiganLabs’ approach to software development

February 12, 2024

Read more
View more articles