Every digital business lead I know is stretched
too thin, which is not to say they’ve cornered the market on being overextended. But the relentless pursuit of digitization to make business more efficient, productive, and competitive has put digital teams in the hot seat.
Coordinating with multiple stakeholders is essential but time consuming; managing dispersed engineering teams is a challenge all its own. Software is no longer built by a single team. Any large digital product is a feat of engineering that generally requires multiple teams to coordinate across one or more organizations. 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 (perhaps one uses “feet” and the other, “meters”), and the instruction is to change the unit of measure, the values will be updated, but the ACTUAL issue is that all calculations need to be changed, according to which country the viewer is in. It is no longer a quick fix. It is no longer just the engineering teams’ problem.
Focus on the intent, not the task
While the Agile development process is designed to facilitate continuous collaboration and communication, differences between teams can create disconnects.
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. For 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…”
Challenges in synchronizing multiple engineering teams
When developers are brought in who don’t ask these questions nor understand their significance, they fix the specific item which can break everything else. Days are spent doing extra testing to make sure nothing else slips. Months of development time can be 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.
When multiple engineering teams are involved, there also 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 – milestones are missed.
Lessons learned
Over 20 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. Find a technology advisor with the requisite experience and skill communicating and coordinating diverse and dispersed technology teams for those projects with no room for error.