Software development is like a high-stakes game of Jenga. The player on top is constantly changing, the higher you reach the greater the risk, and things don’t always go according to plan. The problem is software development is no game. Delays are more than cost overruns and wasted resources, they are now a competitive disadvantage.To stay on top, industry leaders need to be first to market with digital offerings that attract a critical mass of users.
If you are a product owner, commercial lead or are in any way accountable for the outcome of a large digital initiative, what may seem to be a technical problem for your developers to solve is actually your problem. The following scenarios illustrate why digital offerings are set back by months, leaving your business to catch up rather than take the lead.
Development delays may not be the reason you think
Software is no longer built by a single team, or even multiple teams at the same company to deliver applications. Any large software product is a feat of engineering requiring multiple teams to coordinate across organizations to bring a single vision to life. 
Like the sport of crew, it’s no coincidence that the team that rows best together has the fastest boat. The challenge is to make sure all team members are rowing in unison. The Agile development process is designed to facilitate continuous collaboration and communication across business and technical teams. However, teams are not always rowing in lockstep.
- The “team” may be spread across time zones, languages and cultures.
- They will have different internal cultures and processes.
- They may use different standards of measurement.
Case In point: if two countries use different units of measure and the instruction is to “change the unit of measure for X country on this table”, the single table will be updated, but the ACTUAL issue is that all calculations need to be changed. It is no longer a quick fix. It is no longer just the engineering teams’ problem.
The impact of oversights on inter-team communication
If one development team doesn’t seek to understand why something is being done, they may not identify when multiple teams need to be involved. This can make the difference between an application that meets users’ needs and one that falls short. It’s important to define the intent of a task, not just the task itself.
Example:
- Task: “Change UK to use kilometers instead of feet.”
- User Story: “As a user, I want to see measurements in my native units, so I intuitively understand how big something is.”
- Task: The developer proceeds to return the height of a corn stalk in kilometers.
- User Story: “Oh I see. They probably mean metric rather than specifically kilometers. We need to discuss…”
When developers are brought in who don’t ask these questions nor understand their significance, they fix the specific item which breaks everything else. Days are spent doing extra testing to make sure nothing else slips. Months of development time are lost “re-fixing” features and functions not developed in context. Development slows to a crawl on new features to keep patching old features that break. This is a communication problem, not a technical problem.
The challenges in synchronizing multiple teams
When multiple engineering teams are involved, there are larger issues that can affect your project’s delivery that are best addressed by an external product owner with the requisite experience and leadership skills:
- Development teams may have fidelity to many different concerns that may override their ability to be dedicated to the project.
- External teams may be dedicated to their own product more than the collective offering.
- The blame game: no one wants to acknowledge it’s their fault for missed milestones.
The majority of the time, the root cause is simply that each team or team member is just trying to focus on the piece of work on the plate in front of them and are largely unaware of what’s happening in other teams. When that happens – and it does – months of development time are lost and milestones missed.
How to get multiple development teams to work as one
Over 10 years of working on large digital applications with other software engineering teams, it’s been our experience that one or more teams working on parts of a large digital project will fall out of sync at some point. As each team is an interlocking part of the larger project, when one team isn’t meeting milestones, it’s hard to move forward.
When this situation occurs, what can you do to avoid delays?
- Make sure you have an external product owner who can sit in the middle and act as a “switchboard” to keep all parties on track. This should be someone with the experience to make sure all dependencies are identified.
- Set clear cross-team expectations that make it clear where teams need to be following the same process versus where they can use their own.
- Involve the technical teams early in planning and design. The technical implementation shouldn’t restrict what you want to do with your software, but it can help you prioritize it.
- Make sure all external teams have a depth of experience in both agriculture and technology. They need agtech background to prevent any one individual or team from holding back the others.
- Include all teams on triage calls, with representatives from engineering and product ownership of each team.
- Choose an external partner with an uncommon ability to coordinate, communicate, coach and course correct.
Coordination and communication are theoretically supposed to be solved by project management and product owners, but the people filling those roles are often at the mercy of other demands or simply may not have the technical, functional and business expertise to identify coordination that isn’t occurring.
Digital readiness is the lynchpin of your business
Software is your competitive advantage if you know how to develop it at a faster pace, with fewer failures, and to scale within a digital ecosystem.