Complications, contention, and complexities will often emerge when attempting to integrate a non-Agile vendor implementation within an Agile organization or team. From my experience, many vendors already have a phased project plan template established for their portion of the work and this can seem somewhat. What is an Agile team to do if they are dependent on a vendor for a piece of an overall solution?
While this can be a challenging scenario, here are the elements I look at when establishing a framework for “blending” agility between seemingly dissimilar frameworks and mindsets:
Shared Language. Establish a common and shared language. Are we going to have a period of requirements gathering or product discovery? Are we going to use function points or story points to size and scope? Remove any ambiguity between the two groups. Infuse as much “agility” into the language as possible. Developing a language map will anchor and guide our future conversations and frame the context of our working relationship. While a coach may need to initially help with this, developing a language map works best when co-created by those performing the work. Ideally, this language is worked into the contract but this often happens after the contract has been signed.
Note: Without establishing this shared context, everything else becomes challenging.
Roles. Ensure roles are clear and concise across all team members. Is there a Scrum Master locally but a Project Manager coming from the vendor? Will testing be performed by local testers or by the vendor? Does everyone understand their role and how each role should interact with each other? Here is an exercise to develop role clarity if you need one.
Developing empathy between roles and understanding the expectations of each role is important here. For example, the Project Manager from the vendor is most likely being requested for specific information and status from vendor leadership. What can we do to help them get what they need while still aligning to Agile values and principles?
Work Products. Each role, spanning both groups, should know what they are responsible to create or build. Will we have a project plan, product roadmap, or a release plan (or all three…or none of the three)? How will requirements be captured? Will we be writing user stories or work items? Will we have one shared product backlog or will there be a separate one for the vendor? Much of this can be resolved by aligning around the common language established together.
Ceremonies. Determine how and when we will communicate and synchronize with each other. Will we have daily stand-ups or weekly check-ins? When and how will we demonstrate working software? This is often when it gets tricky as the vendor may pull out their phased project plan and expect the Agile team to wait until they complete a phase before seeing any progress. Again, fall back to the common language and find opportunities to see progress frequently and iteratively.
Activities. Determine the activities each role will need to do to support the creation of the work products and facilitate the ceremonies. Who will be facilitating the ceremonies? Who will be responsible for grooming the backlog, how will we size the work, etc.? When will we plan, build, and test together? Be explicit but modify and improve as you go.
Information Radiation. Establish the means to communicate our progress and be accountable to each other. Vendor teams are often remote so this obviously means setting up some kind tool for shared visibility and interaction.
Escalation. Establish the approach to escalate impediments across all groups involved. Who needs to know what and when? What is the protocol when the team can’t solve something or doesn’t have what they need?
Have you worked with a vendor to create a blended agile environment? What worked for you? What didn’t? Would love you hear your thoughts.
