If your application is not progressing as expected and it’s taking more time and budget to develop it and get it to market, then you may be suffering from “Single Project + Several Teams” collaboration issues.
In this blog we´ll explore some good practices that will help solve some of these issues.
Typically we see difficulties emerge when different teams responsible for different parts of the project need to work collaboratively together for the best results. For example, consider the following scenarios:
- Timing for developing the UI. For example, we have a top level application where the user experience (UX) is the most valuable part. The UX Design team completing the UI (that will be re-used) works together and shows the Product Manager/Product Owner how the application will look to the final user. This process needs to happen before taking the product to the UI developers. In terms of time, the review process can be done in 10-15 minutes and may not even require a formally scheduled meeting – ping them immediately and ask if they can take a look. But this also has the potential to become a bottleneck.
- Collaboration during Agile testing. For example quality assurance (QA) needs to have advances of the implementation early on in the Sprint, to start running the test cases outlined, and also interacting with developers in order to conduct early preventive testing. Different QA teams running regression will need to collaborate to be on time.
When several teams work together towards one common goal, numerous challenges emerge. In particular these challenges emerge because:
- A team may estimate more conservatively or aggressively depending on their confidence.
- Regardless of the points, the teams need to deliver to their planned capacity. If we just raise a team from 25 to 30 points, the capacity remains the same.
- By raising points beyond sizes established by teams (to match hours) we artificially inflate the value of the delivery
What can help?
- Teams becoming more efficient- and teams showing this efficiency in the form of more aggressive, yet attainable estimates.
- Good pre-sprint story sizing that is relative to the sizes the teams are familiar with. In my experience, teams typically do a good job of this.
- Product Manager/Product Owner review meetings.
More helpful techniques are technical, grooming and business impact meetings. These meetings are not included in the general Scrum process (although sometimes grooming or backlog refinement occurs in Scrum), but they allow the Technical Leads/POs from different teams to join together and define the roadmap for the project.
Here the critical project flows need to be discussed and defined, based on prepared questions, defining alternate flows that could happen, and also gathering that information in a tool shared with all stakeholders.
The most important part of this collaboration is to define the shared goals:
- What value will you deliver to the customer? (delivering something of value to your customer every iteration)
- What is the customer perspective?
- What do you want to see from the developers working on your project?
- Status reports or working code?
- Concurrent testing.
Software development projects are challenging and even more so when they involve several teams which need to be collaborative and goal focused. There’s no simple solution for this, but applying the best practices outlined in this blog will increase the chances of success.
Finding the right balance between getting teams working together, motivated, and coordinated, while meeting time and budget constraints is crucial for achieving success in software development.