Subscribe by Email


Showing posts with label Collaboration. Show all posts
Showing posts with label Collaboration. Show all posts

Wednesday, August 7, 2019

Coordination with External Teams – Why Regular Meetings Matter

Sometimes, when I review the posts I write, I wonder—why even bother documenting something so obvious? Surely everyone already knows this, right? But then real-world experience kicks in. Time and again, I come across situations where professionals, even experienced ones, fall into issues that were already covered in one of these posts. That’s when I realize the importance of capturing even the seemingly obvious practices.

The goal of this post isn’t to restate the basics but to help individuals reflect on their processes. If you're doing something better than what’s mentioned here, I would genuinely appreciate it if you shared it in the comments. These insights help all of us grow.


📌 The Reality of External Coordination

For any team—especially those working on product development—it is inevitable that you will need to work with external parties. These could be:

  • Internal teams within your organization that depend on your deliverables or supply essential components.

  • External vendors or partners—third-party developers, marketing agencies, manufacturers, etc.

Let me give you an example. Our marketing team once struck a deal with a phone manufacturer to preload our app on their devices. At first glance, this seemed straightforward—just give them the APK and you’re done. But the reality? Far more complex.

We had to integrate special tracking parameters to monitor usage statistics:

  • How often the app was used if preloaded

  • How it compared to installs from other sources

This required not just technical changes, but intense coordination. And it’s one of the many examples where assuming things will “just work” can lead to missed deadlines or poorly tracked deliverables.


🛠️ Challenges in Cross-Organization Coordination

When you're dealing with external teams, one big mistake is assuming their work culture and structure mirrors yours. This assumption can be costly.

You need to:

  • Clarify deliverables

  • Map roles and responsibilities

  • Track timelines accurately

  • Define escalation paths

Communication gaps, time zone issues, different management styles—these can all derail a project if not actively managed.


✅ Best Practices for Effective External Coordination

Here are some core practices to adopt when managing collaborations with teams outside your organization:

1. Define Clear Responsibilities

Start by identifying stakeholders on both sides:

  • Who owns which part of the work?

  • Who is the decision-maker?

  • Who handles testing, approvals, or rollbacks?

Have a contact matrix or ownership chart. Ensure it's documented and shared.

2. Establish Clear Communication Channels

Create dedicated channels for formal communication:

  • Email threads with clear subject lines

  • Slack or Teams channels for informal queries

  • Project management tools (like Jira or Trello) to track progress

Avoid mixing multiple discussions in a single thread—it leads to confusion.

3. Set Regular Meetings

Regular sync-ups are crucial. These meetings help:

  • Resolve roadblocks early

  • Ensure accountability

  • Track action items and outcomes

Depending on the project phase, these could be:

  • Weekly status meetings

  • Daily standups (during integration or release phase)

  • Ad hoc calls for urgent issues

4. Phase-Wise Role Adaptation

In the early stages, marketing, legal, and business development people might be heavily involved. As you transition into development, QA and release engineers take over. Ensure that:

  • The right people are in meetings

  • Transitions are smooth

5. Track Deliverables and Dependencies

Have a shared tracker (Excel, Notion, Jira, etc.) that both teams update. Include:

  • Milestones

  • Deadlines

  • Blockers

  • Review comments

Maintain visibility. Transparency prevents finger-pointing.

6. Issue Management and Escalations

Not all issues can be resolved at the same level. Define:

  • What constitutes a blocker

  • Who gets informed

  • Expected resolution times

Escalation should be a process, not a panic button.

7. Define Acceptance Criteria Early

To avoid disputes, both parties must agree on what “done” means. Define:

  • Functionality expectations

  • Performance benchmarks

  • Test coverage

  • User acceptance testing (UAT) criteria


💡 Tailor Your Process, But Keep the Structure

While the steps above are generic, the application of each depends on:

  • Team maturity

  • Nature of the partnership

  • Project complexity

A lightweight integration project with an external CMS vendor may not need a full-blown steering committee. But a core integration with a payments processor? That absolutely needs structured touchpoints.

Create templates for:

  • Kickoff checklists

  • Weekly status updates

  • Risk registers

  • Communication protocols

These documents become lifesavers during escalations.


🚫 What Happens When You Don’t Coordinate?

Let’s revisit the pre-installation app example. Suppose we had:

  • Skipped UAT

  • Failed to add tracking parameters

  • Assumed marketing had done the heavy lifting

The result? A product on millions of devices with:

  • No user insights

  • No uninstall metrics

  • No feature usage stats

In a data-driven world, this is a disaster. And entirely avoidable.


📝 Wrap-Up: Coordination Is Not Optional

Working with external teams—be they partners, clients, or vendors—is inevitable. How you manage that collaboration defines whether your project succeeds or drags into chaos.

So don’t assume. Don’t delay. Build coordination into the DNA of your process:

  • Communicate clearly

  • Document rigorously

  • Meet regularly

When done well, coordination becomes invisible—just like the best-run projects.


📚 Amazon Books for Further Reading


🎥 YouTube Video on Cross-Team Coordination


Challenges of Working With an External Design Team





Saturday, April 27, 2013

Learning - Setup groups within the company and share experiences - Part 1

The first question is about why such a topic would belong in a blog about software processes ? Seems a bit strange to have a blog about experience sharing, since it seems to something that is not specific to the software area. However, I have found that the busy nature of the software professional leads to a scarcity of time, leaving little time for reviewing ones own experience, what to talk about trying to do experience sharing with people from other teams. This being busy nature has only increased due to the economic problems of the last few years, with the same number of people expected to do more.
So what is this post about ? In any decent sized organization, whether it be a product development organization or an organization that works on projects, a number of teams do similar kind of work and hence are in a position to learn a lot from each other. Even though their products or projects may be somewhat different from each other, the level of difference with each other would not be significant enough. As a result, if there was coordination (or rather, let us not use the term of coordination, rather let us talk about how they can share their experiences), then the teams and their managers can learn a lot about how each team handled some situations which are common.
This is best served through an example. We had a situation where we were running into problems with an external vendor (not even a vendor, more like a open source component maker who would post new versions of their component with updates and notes on a regular basis, every 6 months or so). We did not have any clarity as to what were the contact details of the key people in the component maker, we did not know details about the kind of testing processes that they had, and so on. This was causing us problems, since the component was important to us (it saved us a lot of money that would otherwise be needed to buy a professional software that did the same function).
At that time, we recollected that another team in the company was doing something similar in terms of functionality. We did a quick engineering discussion with them, and realized that they were far ahead of us in terms of figuring out these kind of details that we were looking for. They had knowledge of the key people in that open source project, and they had discussions which provided them far more comfort in terms of the testing processes and the level of quality in the released version of that component.
Because of this particular discovery, we had a senior engineering person within our group interact with a similar person from their team on a regular basis for these kind of discussions. We also created an email group with the specific name of that component, and made it open for other people within the company to join. The resultant was that over a period of time, we discovered 2 smaller project teams within the company that were also looking to evaluate such a component, and they got a head start based on the discussions that they had with us and with the other teams.
Now, if you do such discussions, not only for such an example, but for other cases where you are running into problems, such as problems with the latest seeds of MS Windows or OS from Apple, or where you are running into other problems, such groups can provide a lot of help, since it allows people to share issues and share solutions. However, it takes time and effort to do this kind of sharing and coordination, even though the rewards that you get from such sharing can be well worth it.

I will add more about this in the next post in the series (Sharing experiences within the company - Part 2 - TBD)


Friday, July 22, 2011

Introduction to Class-Responsibility-Collaborator (CRC) Modeling

Class-responsibility-collaborator (CRC) modeling is a means to identify and organize classes relevant to system requirements. CRC model is a collection of index cards and it consists of three parts:

Classes : It is a collection of similar objects.
- Entity classes or business classes are obtained directly from statement of the problem. The information contained in these classes are important to users but they do not display themselves.
- Boundary classes are used to create interface which user sees and interacts with as software is used.
- Controller classes are designed to manage creation or update of entity objects, instantiation of boundary objects, communication between objects and validation of data.

Responsibility : something that a class knows or does. Some guidelines that can be applied for allocating responsibilities to classes are:
- System intelligence should be distributed across classes to best address the needs of the problem.
- Each responsibility should be stated as generally as possible.
- Information and the behavior related to it should reside within the same class.
- Information about one thing should be localized with a single class not distributed across multiple classes.
- Responsibilities should be shared among related classes when appropriate.

Collaborator : another class that the class interacts with to fulfill the responsibilities.
- It takes one of two forms : a request for information or a request to do something.
- If a class cannot fulfill all of its obligations itself, then a collaboration is required.
- Collaboration identifies relationship between classes.


Tuesday, July 12, 2011

What is Adaptive Software Development (ASD)? What are three phases of ASD?

Adpative Software Development (ASD) is a method for the creation and development of software systems. It focuses on rapid creation and evolution of software systems. ASD is a pat of rapid application development.

Adaptive software development life cycle is mission focused, feature based, iterative, time-boxed, risk driven, and change tolerant. In adaptive software development, the developer has a basic idea in mind and they g to work. The focus is in the computer code.

In ASD, there are no pre-planned steps. The software is made very quickly. New versions can come out very quickly as the development cycle is very short. The structure of adpative software development and rapid application development are similar, difference lies in the fact that:
- adaptive software development does not allow the time when the project is finished, rapid application development does.
- adaptive software development does not have a real end point whereas rapid applicatio development allows the end of project.

Adaptive Software Development life cycle comprises of three phases:
- Speculation
- Collaboration
- Learning

In speculation, user requirements are understood and an adaptive cycle planning is conducted. It depends on bug and user reports.
Effective collaboration with customer is very important. Communication, teamwork, individual creativity are a part of effective collaboration. The individual developers combine their portions of work.
Learning cycles are based on the short iterations with design, build and testing. ASD teams can learn through focus groups, formal technical reviews and postmortems.


Facebook activity