Three scrum teams on same mission with different software
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
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.
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!