Two Scrum teams working on Technical Dept / Standardisation project
Hello all.
I am a freshly minted Scrum Master, having been in the job for less than a year. Long time reader of the forum though, and first time poster!
So, I am not sure if my subject is clear enough, so I will elaborate here. Essentially, my colleague and I are running two Scrum teams, I one, and he the other. Both teams are working on similar technologies but are separated by the vertical as described by my company.
So lately we have decided we need to do some standardisation across our products, and try to clear up some of our technical dept. Management have decided they want to do this over two quarters, which is fair enough, at least to get on top of it. So we will have an 80/20 split on this and our normal BAU tickets.
So my question is, what is the best way to approach this with two Scrum teams? At the moment they both have separate backlogs of course, and I don't really want to change this. My idea was to introduce the relevant 'project' tickets into both backlogs, but ensure work does not get duplicated (maybe keep a spreadsheet separate to record this), by having representatives from each team, meet in an event or meeting. I read about this in the Nexus approach.
Both teams are working pretty well, and they know each other and are friendly with each other. I think we would have the flexibility for members of each team to pair up on tasks also.
What are your thoughts on this, have any of you encountered this before? I don't want to over think it, or introduce any big changes to the teams, as they are working really well at the moment.
Thank you all, have seen fantastic feedback on this forum before :)
Never mind what you or management think about this, it isn't your decision and others will be accountable.
Ask:
- How many products are there and what do the Product Owners think? Technical debt is a Product Owner concern because it influences value delivery.
- What do the Developers plan to do about the technical debt they seem to have incurred, since they are accountable for work being Done and for quality?
- Suggest for consideration that the Definition of Done might need to be improved in order to mitigate technical debt and to meet new standards.
Hi Ian,
Thank you for your reply. Let me try and answer your questions and expand a bit more.
- Let's say 5 products per Scrum Team, but we generally look at them as one big product (several websites of similar theme basically.)
- The dept was inherited, the company has grown quickly and this dept exists from well before we adopted Scrum. The team is committed to work through this dept asap.
- Yes we are working on a Definition of Done as we speak, it will take some time though.
We will ask the teams of course what they want to do, it was more about guiding them on the specifics of having two scrum teams working closely on the same 'project'. Can it just be as simple as having some events / meetings between the two teams to keep them aligned?
Many thanks!
it was more about guiding them on the specifics of having two scrum teams working closely on the same 'project'. Can it just be as simple as having some events / meetings between the two teams to keep them aligned?
I doubt so, precisely because they are working on the same 'project' as you put it. If they were working on clearly defined products, they'd have Done integrated increments to align to at least once every Sprint. Empirical outcomes would be regularly inspected and adapted. Therein lies simplicity, even under complex conditions of high uncertainty.
In Scrum, each artifact gives transparency over something. A 'project' gives transparency over nothing and obfuscates everything.
Hi Ian,
Thanks again.
In fact we did have a meeting about it today, and the teams decided to (for now) create tickets based on the tech dept and standardisation and add them to their respective backlogs, and work through them accordingly per product. They will use the Done increments from each sprint to align.
We will probably need to have a few meetings between the two teams to facilitate this but the teams are willing to give it a try. We can look at the outcomes and adapt from there. I guess these meetings will not be true Scrum events though.
Rgds