Combining Scrum Ceremonies With External Organizations - Good or Anti-pattern?
Good morning,
Our company transitioned to Scrum last year. This year we brought on a new client that is also doing Agile and Scrum. Their project manager keeps trying to bake us into a single scrum team by attempting to schedule scrum ceremonies between our teams (daily stand-up, retro, backlog refinements, even sprint planning to ensure our internal sprints lineup with their sprints, etc). However;
⁍ We do not share each others backlogs. We maintain our own internal ticketing systems as well as work on our own servers.
⁍ Each company has their own teams, own workflows, unique sprint cycles, etc.
Every warning bell in my scrum-head is ringing these are anti-patterns and pretty much go against the fundamentals of Scrum. The simple fact our companies are separate creates dependencies on each other and outside of each other's control. I understand as stakeholders, our client can and should be attending OUR Sprint Reviews, but to be linking our sprint and scrum processes together????
They are not the only customer we have and thus do work for.
My question is, are my warning bells correct? Does anyone know of cross-functional COMPANIES? If my bells are correct, how best can I guide our client away from this wonky path?
"Their project manager" is also an alarm bell -- think about the implication for self-managing teams.
What problem is he or she actually trying to solve? You mention "cross-functional companies", and dependencies between teams. Is one or more of those teams insufficiently cross-functional, to the point that the integration of a "Done" increment proves hard...and if so, is this an attempt to compensate?
This year we brought on a new client that is also doing Agile and Scrum.
They are not the only customer we have and thus do work for.
@Tara Conklin, The above two sentences makes me seek clarification. This client you are referring to, is your company working for their Product or vice versa? When I say Product, it could be a physical product or a service. for example, iPhone is a product, Windows OS is a product, Uber is a product.
Is your Product Backlog, aligned only to this client or does your Product Backlog have the work of multiple clients?
Does anyone know of cross-functional COMPANIES?
Could you clarify what you mean by this?
I share all of the concerns stated by @Ian Mitchell and @Steve Matthew, This sounds like a company using Scrum terms but not Scrum practice.
I have a suggestion. If I were a Scrum Master for your company, I would suggest the alternative of having a sort of Scrum of Scrums with their company. My suggestion would be for the Product Owners and Scrum Masters to meet on Tuesdays and Thursdays to discuss cross team topics. This will give insight into what kind of coordination is needed, if any. Over time, the two companies can work out a process that will benefit both of you. This might even help your company to develop processes that can be used with other clients to help ensure the transparency and flow of information is occuring as needed.
Thanks, Steve and Ian for the feedback. Apologize for the confusion. It is a very convoluted situation for sure.
We have a software product that is used by multiple clients. It is our IP. However, due to the nature of the product (related to Medical records), certain aspects of our software do have to be customized to individual clients. However, these customizations are more configuration than features and functions.
This is a newly implemented client that recently went live on our product. Regardless if my company was Agile or not (which we are), this new client is attempting to integrate my company into their Scrum practices.
For example, they want us, being our Product Owner, Scrum masters, primary leadership, implementation managers, and Customer Support Manager, to attend a daily standup meeting with their team, to literally answer the three primary standup questions. As mentioned, my company's sprints contain work relevant to our product and other customers.
They've scheduled our leadership to attend a bi-weekly retro to cover the work WE did whether related to any configurations unique for them or just features and functions we are developing for our IP software.
They've created their own backlog of feature requests and defects related to our product and want us to attend refinement sessions to refine and estimate these items. Granted, this is without my company even agreeing to implement these features into our product and put them on OUR backlog. All bugs and defects reported by any client are automatically added to my company backlog and refined, estimated, and sprinted accordingly. This client is behaving as if they now own our product and teams, and we are simply an extension of their development team. Instead of two companies that both happen to do Agile & Scrum, they see us as two parts of the same scrum team.
Has anyone experienced this with a customer?
I do hope this helps provide a bit of clarity. It's the Twilight Zone of Agile and rather difficult to convey. I'm simply not sure how much I should be pushing back, coaching my leadership, and the client for that matter.
You already have some good answers, and there's a lot of validity in what has been said already. It is entirely possible that doing this would be a bad idea.
But I'll offer an alternative perspective, simply because despite whatever else is going on, there might be some good in the proposal.
First it's important to note that nothing in the Scrum Guide mandates that a Scrum Team can only be formed from one company; but it would be unusual, and would bring its own set of challenges.
Do your two companies share a regular moment when mutual inspection and adaptation would be useful? Does either team produce a releasable Increment, that can lead to adaptation of the other's Product Backlog?
For example, maybe your company makes engines, and your team release an upgraded specification of a car engine each sprint. Perhaps the other company builds racing cars, and risks wasting development resources if changes in your engine invalidate their aerodynamic efforts.
In such a case, it may make sense to align the end of the sprints, and potentially hold the Sprint Review as a mutual event; or to at least have the two Sprint Reviews within a short period of each other. This may eliminate waste, as a new sprint can be planned very soon after valuable insights are gained from the end of the other team's sprint.
Hello Tara,
This situation is becoming relatively frequent in companies in healthcare and medical device sector. I understand your pain.
May I suggest something investigative. I would look through the partnership/implementation contract if there is any agreement on working together or any periodic knowledge transfer clauses that have been put in place.
As EHR and other MedDevices sector is highly regulated (which you must be knowing already), the trail of work may need to be established in order for faster regulatory approval or deployment. Certain clauses in HIPAA and ISO 13485 (if applicable) may be guiding this. I would also check if there is any underpinning regulatory concern for both the parties and suggest speaking with your client.
Nonetheless, the client requiring your members attend every Daily Scrum is unreasonable. If the Dev Team are independent in both organisations, I think it is also pointless to ask anyone from your organization to attend their Daily Scrum.
The agenda of Retro also seems to be somewhat questionable. I would prefer not to call it Retro but "Touching-base" meeting. It might be because they want to call all their meetings with the titles Scrum Guide provides, though it seems to me that this misnomer gave an incorrect idea to your organization. However, I also feel that they might want to have that information may be to optimize and deploy their APIs sooner. Following statement made me think that.
retro to cover the work WE did whether related to any configurations unique for them or just features and functions we are developing for our IP software.
Hope you get something to inspect and adapt.
Thanks
You are creating the product for the client. The client's role should be to observe, use and provide feedback. There is nothing wrong with syncing up with your client, but that should be more of check-in and not a merging of the two Scrum Teams. What the project manager is suggesting will not work and will lead to confusion and wasted effort.
We have a software product that is used by multiple clients. It is our IP. However, due to the nature of the product (related to Medical records), certain aspects of our software do have to be customized to individual clients. However, these customizations are more configuration than features and functions.
@Tara Conklin, Thank you for going into detail and helping us understand the situation. Here's my take on this...
Since, you and your Scrum Team are doing some customization and it appears that there is some kind of feature development involved, you could treat this as a sort of new Product for this client because it is unique in some ways (based on what you describe). The Product Backlog (at your end) for this client could contain the customizations, features etc what this client wants. Every Sprint your Scrum Team can decide what to accomplish and you can review that with the client at the Sprint Review.
Why would the client want to unnecessarily have a Daily Scrum or any other Scrum event when it is your Scrum Team that is doing the work. To me, they are stakeholders for the value being delivered. They can Inspect the Increment produced each Sprint and if necessary the Product Backlog (at your end) can be adapted based on their input.
If both your company and the client can work in this manner, wouldn't it be more valuable for everyone? Have you tried explaining it like this to them?
Thank you all!! I completely agree with your suggestions and logical recommendations. This is also what I believe to be the better course.
It makes no sense to have a Retro hosted by the client where our leadership and project mgrs attend and answer
"what went well, what can we improve, what are our blockers?"
Having them attend our Sprint Review is the logical step since that is what SR is for.
I'm not in charge of this client relationship and sadly being brought on only at the end of a seven-month implementation. My company is completely new to Agile and being we are rather small, it's been a challenge coaching, educating, and transitioning the group to proper Agile practices. I came from a global conglomerate where I was a certified Scrum Master for five years. It's a challenge for sure.
I've stated that while this process is maintainable presently, albeit convoluted and anti-scrum if we were to bring on ten clients of this size, this process would not be sustainable.
Steve, it would certainly be more valuable to everyone involved to work in that manner. The magic will be in trying to make both the client and my leadership understand. Old ways die hard. :)