We are a project that for external reasons has to run in a Scrumish fashion. We consist of two subprojects : A backend data and services provider that I am a part of, and a UI+BPM layer that interacts with it. The backend also serves a few other consumers and both parts are implemented in two completely separate stacks (by different vendors). The developers of either side are experts on the tool set of their vendor and have no knowlege about the respective other technology or functional design.  It's to the point where we don't have the slightest idea what the others are talking about at the daily standup meetings and we are completely incapable of estimating stories from the other side of the aisle.On the other we still have to release together, have a lot of points where we interact and sit in the same room. We have the same PM, PO and SM and some of the testers work both sides. In total we are 7-9 developers and 3-4 testers and a few other roles at the meeting each morning. We cannot easily be trained on the respective other stack or functional design, for budget, licensing and time reasons.So from a budget and project sponsorship point of view this is one big project whereas from the inside it is more likely two. In the beginning we had our standups, review, retro and planning as one team but with separate refinements. After a while the discontent with the boredom at sprint changes led to the review, retro and planning being split into two different appointments and the sprints are now ending one week apart.How would you implement something like scrum better in this setting? Is there a value in continuing to run an inclusive daily or should it also be split? If we keep it together how do we improve it? If we split it, how do we make sure the important interteam questions get addressed?
How to deal with losely coupled sub projects in Scrum?
agile;project management;scrum;teamwork
I would actually take a step back and ask the question - for your own satisfaction - as also of the team's - Is there a problem? and What is the problem?, if the first answer is Yes.Next, the question - Why Scrum?  Even if there are external reasons, it might be worthwhile to see what will work better for the team. How can you make changes in the process to address specific problems you are facing, so that rather than look from the point of view How can I implement Scrum better?, you can look at How do I deliver software better/ faster? And the teams happier, less bored, more engaged and productive? - and get the team to collaborate on solving that problem.If this makes sense, then one approach I would suggest is to apply Kanban principles (visualize your work/ workflow, implement Pull and WIP Limits, and manage/ optimize flow) to improve your Scrum team's performance. It is possible I might be accused of using a Kanban hammer for every software nail, but I do believe your situation needs greater analysis and understanding before concluding that doing Scrum better will help you get to a better place.Some specific things that the application of Kanban principles will do for you - Help you manage the two teams' work in separate swim-lanes on a Kanban board and just provide an easy visual understanding to both teams of what the other is doing, how loaded they are, where the bottlenecks are, etc.Since their delivery is decoupled, you can look at multiple options to sync. up, integrate and make customer releases in a cohesive manner, while providing opportunities to both teams to take up intangible work such as technical debt reduction. In the process, you might decide to change or remove an artificial time-bucket of 2 or 3 weeks that an arbitrary process definition imposes on you.    In the example shown below - each of your teams could drop code for integration at their own cadence and post-integration processes could follow at a business-required cadence. If any of the teams had any slack between release events, they could pick up work in the Intangible lane (technical debt) - and do those while waiting for the other team to complete their work.Over a period of time, you might either continue to make releases in this manner - or move to a more continuous delivery model, if the cost (effort) of making the release is lower than the cost of waiting (opportunity cost/ time to market).  (If you have not yet come across this approach (Scrumban/ Kanban), you might be interested in reading more on this here - What is Scrumban?