Back to Forum

Three scrum teams on same mission with different software

Last post 06:16 pm December 13, 2023 by Ralf Grabemann
2 replies
Ralf Grabemann
11:55 am December 12, 2023

Hi community, I just recently took over three scrum teams as a scrum master. I have worked as a product owner and in a development team for almost 9 years - so I know at least two sides well. Being a scrum master now challenges me with a team set up, I have never had before. I simplify the set up and description a bit, but believe me, the basic set up can not be changed (but the space here is not big enough to describe it in detail).

There are three teams. All work on software that does something in the same area. The aim is to fuse all three software into one software, but at the same time keeping the original software alive. There are quite good reasons for that - so we need not to discuss this here. 

My problem is now to have a good dependency management. So, say, software A does a change which goes into main software M, and software B does a change which goes into software M and software C does the same … who do I track that changes in main software M go back to software A, B or C and vice versa?

They do not work on the same code base (to make it more confusing) one uses C the other C++ and the third Python. So each time a change occurs one has to translate the code from one to another. And, to ad one further complication - the teams work not on the same site…so face to face meetings are a rather rare occasion.

We use JIRA as an issue tracking tool. Does anyone know, whether I can have an alert set, so the teams get a heads up if a change was done to the other software?

We do have two weekly meetings for now. I know that scrum would advice to have one daily each day - but we are not there yet. I have to do some basic work in order to convince some members that agile working (scrum, kanban, XP, and the like) does not hurt. So I know the shortfalls in the team set up. 

Would any of you agree, that for starters kanban is good, in order to translate the code, for instance, from Python to C++, and then introduce scrum for the common main software M? Or would you rather go for scrum right away? My thought was, that kanban would make it more easy, since the code is already there - just needs a translation, and once the main software is mature enough we continue with scrum all the way. 

Any better ideas?

Thanks a lot

Ralf

Ian Mitchell
11:50 pm December 12, 2023

I have to do some basic work in order to convince some members that agile working (scrum, kanban, XP, and the like) does not hurt

You're right in the sense that agile change won't cause hurt. What it will do, however, is to further expose the constraints and dependencies you describe, and make their consequences for empirical value delivery painfully clear. A finished Increment of immediately usable quality must be provided at least once every few weeks.

The immediate experience of those involved, therefore, will be that agile change hurts like hell. Issues are exposed, brutally, so they might then be dealt with. None of the palliatives, band-aids, and cover-ups organizations typically resort to are provided at all.

My advice is to make this quite clear, so people know what they are in for, and can then actually own any agile change attempt they make. This is perhaps the most "basic work" which you ought to do.

Ralf Grabemann
08:53 am December 13, 2023

Thanks for your reply, Ian.

I totally agree with you about that agile changes hurt. I also see the need that things have to change rapidly. Unfortunately some had really bad experiences in the past or a total misconception („…our Sprint Reviews lasted 5-6 hours for a two week sprint“, „… the developers have to put in the acceptance criteria into the User Stories - as a product owner I don‘t do this“, and many more …). Some have to be healed first before I can turn things around. 

I have only good experiences with agile methods, but I have also seen „agile gone bad“ … and I believe this is here the case. 

But again, thanks for your input!

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.