There are many factors to consider when shipping a new product, service, or feature to production. Does the product meet the business requirements and provide an excellent experience to the user? Has the service been load tested? Does the service have the appropriate logging, performance monitoring, and tooling to be able to debug live site issues? Did the team make time for engineering investments and pay down technical debt if it is leveraging an existing service?
All of these factors can provide interesting challenges, but they are all within the scope of the individual or the team. So if you are a determined engineer, you can control destiny. But what happens when your product has dependencies? If your success depends on the success of another team, or vice versa, this can present an entirely new set of challenges. At Rally, we are at the intersection of healthcare and technology. We work with internal and external partners, third-party vendors, employers, and other healthcare companies to navigate the complex healthcare system and simplify it for the user. In order to be successful at this, we must succeed in managing dependencies. Below are some critical tips for how to handle dependencies.
Embrace the Unknown: Be Agile
A typical product launch starts with a high-level idea and few requirements or old feature enhancements. However, unless you and the team have invested a copious amount of time and effort to collect/refine requirements, you will never have the complete scope identified. The ideal way to handle this situation is to be agile, break scope down to smaller areas of focus, and keep doing it until all scope is identified and solved for. You and the team are agile, and as you are dealing with scope in small chunks, you can optimize to drive the outcome.
Most software product launches are risky because of the range of potentially severe problems that can arise, especially when there are many cross-dependencies from internal and external teams. The benefit of risk identification and complexity of features will help you manage the risks better. Here at Rally, we do the following to identify and manage risks.
- Create a plan for potential risks at the beginning of the project, and keep revisiting and adding/removing risks on every milestone.
- Try to implement the most complicated part of development first.
- Keep an eye on potential delays that end up becoming risks later.
Set Expectations Up Front
If your product has dependencies on other teams, first and foremost, you should let those other teams know what the dependencies are. At Rally, we do this through a kickoff meeting with representatives from all groups involved and all stakeholders. During the kickoff meeting, dependencies are identified and tracked, and we establish who is delivering what and by when. We also develop roles and responsibilities for those contributing to the project. If there are dependencies on teams at external companies, we let them know too, and make sure the interfaces are documented (in the form of an API contract, file format, etc.).
When you work toward delivering a product that has dependencies, your success is dependent on the success of others. It is therefore vital to be in constant communication with those on other teams to help enable each other’s success. At Rally, we have formal mechanisms for communications: status emails, daily standups, a scrum of scrums, etc. On the most successful projects, essential communication happens from engineer to engineer, working side by side. Whether in person, on a video call, or on chat, Rally engineers are always bouncing ideas off each other, collecting feedback on the design or implementation of decisions, and jumping in to help others regardless of what team they are on. When team boundaries break down, many groups working together can operate as one.
Plan for pivots
If you work on a project where everything goes as planned throughout the entire project, then that is the exception rather than the rule. When engineers across teams, companies, and geographical locations come together to deliver a product or feature, there are usually obstacles along the way. When these obstacles arise, you should be flexible and willing to adjust. If your team is running ahead of schedule and another team is falling behind, then jump in and offer to help. Allocate time to support end-to-end testing and to debug issues, whether or not they are in code that you wrote. If problems arise, put yourself in the other person’s shoes. A bug that is minor for you may be critical for another engineer if it is blocking their development. When different components are hooked together, there can be gaps, but a great engineer will work to make sure that those gaps do not affect the success of the team.
When launching products with scope and scale, managing dependencies is critical to success. Setting clear expectations upfront, over-communicating, and making adjustments along the way will make the process go as smoothly as possible.