Agile Projects with Third Parties: Anti-Patterns, Challenges, and Best Practices

Introduction

Whether by coincidence or a genuinely widespread phenomenon, in recent weeks, I have found myself engaged in conversations with various individuals from my network on the same topic - a topic that has consistently made me ponder professionally over the past year:?"How can we ensure a highly agile workflow when collaborating with third-party suppliers in a joined set-up?"

Let us assume from the outset that both the client and supplier share positive intentions and possess a fundamental understanding of agile principles, values, and methodologies. However, challenges often arise in the collaboration model between these parties. Given their awareness of these foundational (agile) principles, it becomes evident that divergences occur due to contrasting business interests. To simplify matters – without any offense – the client seeks a cost-effective solution, aiming to maximize value for their investment, while the supplier aims to maximize profitability. Additionally, is there a potential "political" element at play, involving the preservation of reputation or "saving face"? In such cases, the dialogue between the parties becomes even more asymmetrical.

This article provides valuable insights into the most common challenges and anti-patterns associated with collaborating with suppliers in an Agile context, along with best practices and strategies for proactively addressing these issues.?

Bellow you`ll find:?

# 1 – Most Common Anti Patterns

# 2 – Most Common Negligence

# 3 –??The Biggest Dispute of all Time: User Story Estimation

# 4 – Best Practices and Strategies

# 1 – Most Common Anti-Patterns

Collaborating with third-party suppliers in Agile projects can sometimes lead to anti-patterns that hinder progress and undermine collaboration. Drawing from my network and personal experience, this chapter aims to highlight the most prevalent anti-patterns that arise in such scenarios. By understanding these common anti-patterns, we can better navigate the challenges and foster successful collaborations:?

1.????Introducing a proxy Product Owner to safeguard control.

Suppliers often tend to assign a Proxy Product Owner, creating a single point of contact for the customer at the product level, while having a Project Manager or "Resource Manager" at the team level. This approach can lead to the following consequences:

• Communication gaps?
• Lack of direct involvement
• Delayed decision-making
• Reduced accountability and ownership

SPOILER: On this very popular anti-pattern I plan to share a dedicated article

2.????Conducting "shadow dailies" or other unofficial alignment meetings to discuss project status quo without the customer's knowledge.

In an attempt to maintain face and prepare for official meetings, suppliers often introduce internal dailies, planning sessions, reviews, and other formats as "pre-meetings" to get the team ready beforehand. However, this approach leads to the following outcomes:

• Significant time loss and reduced development time.
• Frustration among team members due to redundant activities.
• Senior developers, who are often involved in shadow meetings as team experts, experience time constraints as they also guide junior developers and conduct code reviews.
• Suppliers exhibit strong determination influenced by agreements reached in the shadow meetings, which can introduce biases in their decision-making during the actual sprint events.

3.????Using a separate project tracking tool with different metrics than the customer

This anti-pattern is often driven by two main reasons that I have observed. Firstly, the supplier may have its own project planning tool that is primarily focused on resource management, allowing for efficient planning and coordination across multiple projects in their portfolio. Secondly, in cases of project delays or difficulties, especially when senior management is closely involved, there is a tendency to adopt a "micro-managed" approach to the project. This can involve using creative tools like "Jira to Excel exports" providing granular view of project progress. The impact of such measures is evident:?

• Confusion and miscommunication arise due to the application of different perspectives.
• Misinterpretation of data occurs, especially when the focus is on output rather than outcomes.
• Organizational overhead increases due to the maintenance of multiple tools and the need for additional discussions.
• There is an increased risk of missed expectations –?lines of code are growing, but no deployment is in sight.

4.????Billing the project based solely on the number of delivered User Story Points

Billing a project solely based on the number of delivered User Story Points may stem from a desire to achieve an agile project, characterized by enhanced predictability, performance-driven approaches, and increased maneuverability. Additionally, it may serve as motivation to avoid the challenges associated with a "big bang" increment handover that typically occurs at the end of a quarter or target date. As a result, the following implications arise:

• Misaligned incentives for the supplier, prioritizing quantity over quality.
• Flawed performance measurement from the client's perspective, emphasizing "delivery volume" rather than "release enablement"
• Neglecting business value by favoring "horizontal delivery" over "vertical delivery."
• Incorrect expectations, as "project progress" does not necessarily translate to progress in developing potentially shippable software.
• Introducing technical debt and, in some cases, inadequate software architecture.

5.????Too formal and rare communication

Most likely, it is a legacy from the era of traditional project management, where the collaboration between the client and supplier is governed by a classical contractual structure, such as a framework or delivery contract. In this setup, there is a distant relationship between stakeholders (client) and the development teams (supplier). This becomes particularly evident when attempting to facilitate ad hoc information exchange, whether it's an extended daily stand-up, additional backlog refinement, or early feedback on completed product increments, only to be dismissed with a response like?Let's use the sync slot next week.

This type of collaborative model often stifles the "spirit of innovation," as the dialog is restricted solely on official deliveries and given requirements. Consequently, this leads to longer feedback loops and wasted potential for innovation.

6.????Hero Culture

Hero culture in an agile project arises when there is a strong reliance on individual heroics, particularly from experienced lead developers, instead of fostering a culture of teamwork and collective responsibility for project success. This often occurs in high-pressure situations, during time delays, or when faced with technical uncertainties. This anti-pattern often undermines the project's progress and proves to be an unfavorable investment for the supplier, as it results in:

• Bottlenecks arising from excessive reliance on these individuals.
• Substantial loss of information and paralysis upon the resignation of such individuals.
• Team degradation due to limited knowledge sharing.
• Burnout and employee dissatisfaction.
• Information bias stemming from “blind trust” in the hero individual.

In summary, there are numerous prominent anti-patterns to be aware of. Throughout this chapter, I have highlighted the ones that my network and I have observed all too often. However, the solution to these issues (maybe with exception to the “Proxy Product Owner” topic) is straightforward: Just don′t do it!?

# 2 – Most Common Negligence

The issues outlined below are not exclusive to the "third-party model" and can arise in any project setup. However, their impact on third-party collaborations is notably significant due to the comparatively slower or restricted adaptation process. Additionally, the mentioned anti-patterns serve as amplifiers for these prominent instances of negligence, magnifying their inhibitory effects to a greater extent:

1.????Exploitation (Cherry Picking) of Agile Principles

Claiming all the benefits of the agile approach for themselves, while disregarding the associated responsibilities. Agile ways of working, no matter how cliché it may sound, require empowerment, willingness to take risks, and prompt inspection & adaptation.

2.????Imposing Agile conditions without understanding them or explicit definition

I have come across contracts that stipulate?we work in an agile manner?as a requirement for the supplier.?If fortunate, it is followed by a statement like?we align with Scrum principles. However, the actual project setup deviates significantly from true agility and Scrum, with custom processes and vaguely defined roles and responsibilities. This lack of clarity leads to oversights and communication gaps.

3.????Accumulation of unpaid or unsupervised Change Requests

Depending on the contract arrangement, the following phenomenon can be observed in agile third-party collaborations: Under the guise of "inspect and adapt," time-consuming or complex changes are surreptitiously introduced iteratively during the sprint. Deviations from the original request or not meeting the goals can negatively impact the supplier, who is often left dealing with the consequences of these unpaid change requests.

SPOILER: Stay tuned for a dedicated article where I delve into this popular issue and discuss the corresponding contract design.

4.????Blindspots in Testing

In an agile collaboration model with third-party suppliers, testing presents several challenges. These include ambiguity around test data ownership, availability of test environments that mirror production and the effort of test automation integration as well as maintenance of the written test automation suite. These challenges can be relatively straightforward tackled by establishing clear responsibilities within the collaboration model or contract, yet they are often overlooked or taken for granted.

5.????Unused potential of joined retrospectives

Interestingly, within the third-party collaboration model, I have noticed something that is often overlooked during in-house retrospectives: the structured and formal approach of addressing technical and structural impediments in the project. Unfortunately, the opportunities to discuss collaboration dynamics and address any underlying issues, including those that may be uncomfortable, are frequently missed.?

In summary, this chapter has highlighted a few selected mistakes that often occur in third-party collaborations. By being aware of these challenges and taking proactive measures to address them through clear communication, well-defined responsibilities, and a collaborative mindset, teams can enhance the effectiveness and success of their agile collaborations with third-party suppliers. Embracing these principles will lead to better partnerships and unlock the full potential of working together.

# 3 – The Biggest Dispute of all Time: User Story Estimation

Among all the anti-patterns, neglect, and challenges, the issue of user story estimation in tense or unfamiliar third-party collaborations remains the biggest dispute. When user story points have a direct or indirect impact on project costs, it can lead to a contentious battle between the client and the supplier. Simplifying the situation, the client is interested in keeping the user story points low to avoid exceeding their budget and to see results quickly, while the supplier aims to keep the points high. At this point it is important to note that ideally, such a connection between user story points and costs should be avoided. However, if this model is chosen for any reason, based on my experience, the diplomatic delicacy of the situation – simply because customer is king – this dispute is being often resolved in favor of the client. The desire to lower the user story points by the client is often driven not solely by monetary motivations but also by the assumption that fewer points will lead to quicker results.?

Once the conflict arises, it sets a toxic foundation for the project, making all the previously mentioned issues worse. In response to a wrongly underestimated user story point, the supplier's countermeasure is to strictly adhere to the agreed-upon tasks or perform only the bare minimum. Any deviations, iterations, inquiries, or investigations are considered additional effort that must be formally documented, estimated, and planned. Incorporating this extra effort into future sprints gives the supplier a stronger position, which may be perceived as coercive by the client.

I believe that this topic requires a deeper exploration and is merely a symptom of a series of (unspoken) issues between the client and the supplier. Depending on the working model, they`re may be a range of potential suggestions for improvement. In this article, I will focus only on the following advice:?When you find yourself in a situation where you are arguing with the client/supplier about user story points, don′t unsee the red flag! Don't let too much time pass and address the situation as soon as possible. Consider involving an independent third party to resolve the dispute or inform the management on both sides so steps can be taken to mitigate the situation.

# 4 – Best Practices and Strategies

Just like always, there is no magical or effortless solution to the challenges at hand. However, I would like to offer my personal collection of effective approaches and preventive measures, I've learned from my own experience. These are strategies that have worked for me personally, and I think they might come in handy for your unique situation, too:

DISCLAIMER: Please note that the suggestions provided below are primarily pragmatic "workarounds" aimed at promoting agility within the project or mitigating factors that hinder agility. It is important to acknowledge that, from a theoretical or ideological standpoint, some of these suggestions may potentially contradict certain ideals.

1. “Agile Coach” involvement during contract negotiation

Involving an Agile Coach (or similar role) in contract negotiations ensures that Agile principles and practices are considered and incorporated from the beginning. At least one could contain the "collateral damage" at the expense of agile principles.

2. Defining responsibilities along the given Jira workflow

Using a (generic) Jira workflow as a reference helps define responsibilities and align expectations between the client and supplier. Within the workflow you have the opportunity to establish a simplified RASCI framework and align it with the required roles and meeting formats.

3. Resist the temptation to add (more) unnecessary meetings

I always strive to adhere to the traditional Scrum ceremonies and resist the temptation to schedule a meeting for every new topic that arises. In urgent situations, it's acceptable to hold an ad hoc alignment, but an overhead of recurring meetings should be avoided. If regular alignments are required, consider implementing a "pyramid meeting scheme", similar to a Scrum-of-Scrums approach:

4. Establishing a change control process

A clear change control process should be defined in the contract to handle scope, timeline, or budget changes, including how changes will be requested, evaluated, approved, and communicated. Keep in mind that, on one hand, you have a "safety net" - safeguarding your change process - certainly impede your development speed, while on the other hand, you desire swift decision-making and adaptability.

5. Including quality assurance activities in the contract

While it may be tempting to place the entire burden of testing on one party, typically the supplier, it is crucial to address testing activities and responsibilities when engaging in an agile software development project with a third-party supplier. This involves explicitly defining the testing scope, delineating the expected deliverables, specifying the test environment requirements, assigning responsibility for test execution, establishing a defect management process, setting acceptance criteria, implementing change management procedures, and creating a mechanism for dispute resolution.

ATTENTION: Although it may require time and effort to properly define these aspects in the contract, it is necessary to avoid the greater and more severe conflicts that can arise from an insufficient testing agreement.

6. Agreeing on review lead times with the client

Establishing review lead times helps manage expectations and ensures timely feedback and decision-making.

7. Implementing a tracing ticket for change requests

Implementing a "tracking ticket" for change requests can enhance transparency, accountability, and accurate billing in the project. It is recommended that each team maintains a dedicated "tracking ticket" for every sprint to document any deviating effort or deviations encountered. This approach enables the feature teams to proceed with their work smoothly, without major disruptions, as the evaluation of whether the changes fall within the agreed scope or necessitate additional billing can be handled separately by the management.

8. Establishing a bilateral reporting mechanism

It is advisable to establish clear agreements on how the progress and quality of software development will be reported from the outset. Joint reporting is recommended, and it is important to avoid retrospective calculation of KPIs in separate tools. These KPIs should be readily accessible from an official source or tool at any given time. It is essential to agree on the medium of reporting, such as e.g. a shared dashboard via email, and define the roles from both sides responsible for maintaining and communicating/reporting those reports, either to the project team or exclusively to the management.

9. Establish shared communication channels (for management)

To enhance the relationship between the client and the supplier and foster a more collaborative, informal, and responsive information exchange, it is recommended to implement shared channels or communities for specific topics. By introducing such joint channels, both parties can have a platform for open communication, facilitating efficient knowledge sharing, problem-solving, and promoting a stronger sense of partnership. This approach encourages a more fluid and interactive exchange, improving the collaboration.

10. Consider establishing a User Story Estimator

Implementing a User Story Estimator tool or process can help facilitate accurate estimation of user stories by the supplier. This tool can provide a standardized approach for estimating the effort required for each user story, considering factors such as complexity, dependencies, and technical feasibility. By having a transparent and consistent estimation process, both the client and supplier can better understand the scope of work and manage expectations.

ATTENTION: This undertaking is challenging and a double-edged sword. Allow room for improvement and avoid treating the estimator as an inflexible addendum to the contract.

11. Regularly reviewing and adapting the collaboration model

As the project progresses, it is important to periodically review and adapt the collaboration model based on the evolving needs and challenges. This includes assessing the effectiveness of current practices, identifying areas for improvement, and making necessary adjustments to optimize collaboration. By remaining flexible and open to change, the client and supplier can continuously enhance their working relationship.

12. Conducting regular (joined) retrospectives, also on project level with the management

Regular retrospectives are crucial for continuous improvement and fostering collaboration between the client and supplier. These retrospectives provide an opportunity to reflect on what is working well and identify areas for improvement in the collaboration process. In my opinion, it would be preferable to avoid a "pure management retrospective" approach. Instead, I would recommend conducting a project-wide retrospective, similar to the concept of a Scrum of Scrums. This would involve having at least one representative from each team and/or role, along with the management, participating in the retrospective session. By including representatives from various teams and roles, a more comprehensive and inclusive perspective can be obtained.

13. Embrace the possibility of involving a conflict coach when needed

Unexpected challenges can arise, and I've witnessed their occurrence firsthand. If attempts to address underlying issues in the project prove ineffective, don't hesitate to consider engaging an external conflict coach. While it is crucial for the supplier to deliver as required, it is essential to acknowledge the collaborative nature of software-driven projects rather than treating them as mere orders. In such cases, mediation through a conflict coach is demonstrably better as simply demanding that the supplier improves at all costs. Being realistic about the nature of the collaboration can lead to better outcomes.

Conclusion

Collaborating with third-party suppliers on Agile projects can present challenges, but by implementing best practices and strategies, these challenges can be effectively addressed. Clear communication, defined roles and responsibilities, transparent processes, trust, and continuous improvement are key elements in ensuring a successful collaboration. By proactively addressing potential anti-patterns and fostering a partnership mindset, the client and supplier can work together harmoniously to deliver high-quality results in an Agile environment.