0

Problems:

  1. A team should be able to do the increment. But with multiple team the product may become unstable because the changes from different teams may create code or functional conflict. Who should solve this problem and how?

  2. We have no architect role (all members are developers without additional titles), and code quality rules may be different in teams. One of the teams may always add technical debt to the product and the other teams will suffer from it. How to solve this problem?

Assumption: project is a big monolith application with tight coupling.

Improve this question
0
3

There are different scaling frameworks. There are three that are heavily based on Scrum - Large-Scale Scrum, Nexus, and Scrum@Scale. Both have slightly different takes on how to organize teams and events, but may be a useful starting point for multiple teams working on a single product with one product backlog.

A team should be able to do the increment. But with multiple team the product may become unstable because the changes from different teams may create code or functional conflict. Who should solve this problem and how?

A common theme here is that the teams should be responsible for this.

A baseline Definition of Done can help significantly. Teams can introduce additional requirements, but a common core to the Definition of Done can ensure that all teams are working toward the same expectations for work.

Automated testing from unit through acceptance can help significantly as well. Even with a single team, automated testing improves the repeatability of tests, reduces the waiting for feedback, and allows for massive amounts of tests to be run frequently. If the tests are good, you can get very rapid feedback on any conflicts.

Frequent integration of work will also help. When coupled with automated testing, you can make sure that everything has been integrated properly. Some may advocate for continuous integration, but this may not make sense for your context. Increasing the frequency of integration is a good start.

We have no architect role (all members are developers without additional titles), and code quality rules may be different in teams. One of the teams may always add technical debt to the product and the other teams will suffer from it. How to solve this problem?

A common Definition of Done will also help here to make sure that the team's are achieving a baseline quality. Work that doesn't meet this bar should not be integrated into the mainline.

Some level of cross-team communication is also beneficial so others are aware when decisions are made to increase technical debt so this can be accounted for in planning, either to work around it or to pay it down in the future by the team or one of the other teams involved. There are different strategies for how to enable and facilitate communication across team boundaries.

Improve this answer
3
  • But if the tests are good, but the code from one of the teams is awful? And who is responsible for the increment, if the code is shared across teams? And team cross-communication is broken because different teams have different vision for code quality. – Dmitry Jul 1 '19 at 11:30
  • @Dmitry If you have a common, shared Definition of Done, then all teams should have at least the same minimum understanding and vision for code quality. It's OK for teams to go above and beyond the minimum, but the minimum needs to be set. As for who owns the increment, it depends. In Nexus, there's a Nexus Integration Team that is responsible for coordinating across the teams to ensure the increment is done and integrated. LeSS provides several options for teams to coordinate, ranging from ad-hoc talking to communities of practice to cross-team meetings and events. – Thomas Owens Jul 1 '19 at 11:38
  • The code can always be written in a way to satisfy rules, but awful. Thanks for the increment question. – Dmitry Jul 2 '19 at 10:52
1

One way to reduce problems from several teams working on the same product codebase is to use continuous integration and automated regression tests.

This is how it works...

All the important functionality in your product is covered by an automated regression test. As new functionality is added, corresponding automated regression tests are also added.

When a team commits some code it automatically triggers continuous integration which in turn runs the suite of regression tests. If the new code breaks any tests then the team knows they have caused a problem. They will typically roll back their commit until they figure out what went wrong.

Using this approach you can maintain a stable codebase.

We have no architect role (all members are developers without additional titles), and code quality rules may be different in commands. One of the commands may always add technical debt to the product and the other commands will suffer from it. How to solve this problem?

There is no simple answer to this question. The best thing you can do is get the teams to work together. In Scrum we often have something called a Scrum of Scrums, where the teams regularly communicate over issues such as technical debt, architecture, etc.

You may also want to consider having communities of practice, which may help you to establish standards across the teams.

Improve this answer
5
  • 1. We have CI, code style tests, basic code quality tests, ~1500 tests. It's not enough. – Dmitry Jun 23 '19 at 19:17
  • 2. But what should we do if we can't reach an agreeement between teams? – Dmitry Jun 23 '19 at 19:18
  • I have seen lots of different approaches. One approach is to look for consensus, but if you fail to reach it then have the majority agree on recommendations, rather than standards. At least that way you get the majority of teams working the same way. I have seen other organisations that have voting on standards and if, say, 60% vote in favour of a standard then it is introduced. – Barnaby Golden Jun 23 '19 at 19:29
  • "1500 tests. It's not enough" - perhaps worth asking a separate question about this? How to achieve effective automated regression test coverage? – Barnaby Golden Jun 23 '19 at 19:31
  • The problem is not in the tests, it's in technical debt. Other teams should waste their time to clean up after one of the teams. – Dmitry Jul 1 '19 at 11:36
1
  1. A command should be able to do the increment. But with multiple command the product may become unstable because the changes from different commands may create code or functional conflict. Who should solve this problem and how?

One product has one Product Owner and a one Product Backlog.

In your case, the issue is that you have split the application in multiple non-independent parts which are lead by multiple people. These people are not in agreement and have different opinions, creating the conflicts you stated.

The solution is to appoint a single person Product Owner over the whole product. The rest can be advisors and they can form a comitee, but only one person leads.

  1. We have no architect role (all members are developers without additional titles), and code quality rules may be different in commands. One of the commands may always add technical debt to the product and the other commands will suffer from it. How to solve this problem?

One product has one Definition of Done.

The Definition of Done is a one document which describe the "quality rules". All the Development Teams contribute to it.

All the technical people needs to sit at a table, propose, discuss and agree on the Definition of Done. Then everybody uses it as a reference.

The teams have different components (e.g. A, B, C, D) of the application inside one big monolith project. And some stories requires changes in several components (e.g. A + C), so people from one team (A) can be affected by code in component (e.g. C) of another team.

While scaling Scrum, the Scrum events are common, meaning all the teams are aligned to them and have them all at once.

Remember: There is a single production (monolith application) and the purpose of using Scrum is to deliver a potentially releasable Increment by the end of the Sprint.

It's clear that all the teams need to collaborate to achieve this. So, during Sprint Planning, the User Stories are discussed in technical details before starting working on them.

In this particular case, the Developers of the two teams agree on how they are going to implement the User Story so that it's compatible. They also they agree on when they will be working on it so that there is enough time to put it all together and deliver the functionality by the end of the Sprint.

The level of details is just enough to reach an agreement, because anyway they might change along the way. When they change, the two teams communicate this in a common Daily Scrum, call it "Scrum of Scrums".

I suggest you scale the Daily Scrum like this:

  • First, the Scrum of Scrums takes place. It has a timebox of 15 minutes and it's focused on the collaboration of the two teams and integration of work. The Developers from both teams join and discuss.
  • Second, each Development Team has its own Daily Scrum.

Any technical topics are discussed right after, with the Developers working on it. They may be from different Development Teams.

To quote Ken Schwaber, one of the founders of Scrum:

Scaling carries with it the responsibility that all of the attributes of the smallest element are found in the sum of all of the elements (100 or so teams perform like one team)

So, when a Development Team grows beyond the optimal size (at most 9 members), it is split into two Development Teams. These two teams need to work together as one or the essence of Scrum is lost.

Scaling Scrum is tricky and is not a one size fits all solution. There are many frameworks that claim to do this, but fall short because the essence of Scrum is lost along the way.

To quote Ken Schwaber again:

The introduction of things like the Scaled Agile Framework, disciplined agile delivery, and enterprise shared services started to reintroduce methodological, prescriptive, one-size-fits-all thinking back into software development, at the same time claiming that it was agile. However, all of these approaches fall apart at the software development level. They typically just say, "use scrum," but scrum is a one-team, one-sprint thing. Also, these methodologies don't tell you how to run large, multi-team scrum projects or programs.

In a successful scrum implementation, when organizations want to execute large projects or releases for up to 3,000 people, they devise their own techniques for working out dependencies, cause frequent integration to unearth festering dependencies, and adopt continuous integration and build.

In conclusion, teams and organizations should use Scrum "as is" for one team and devise their own techniques for working out dependencies when greatly scaling Scrum.

In practice, team and organizations try to customize Scrum for one team (because Scrum raises many issues) and use a fixed framework (SAFe, LeSS etc) when scaling Scrum (because they are losing it completely). This is how the essence of Scrum is lost, but everybody claims they are Agile.

Improve this answer
8
  • 2. The problem is we can't describe all the technical rules because each case is individual. We already have about 40 complex rules. Another problem is to find additional time to review the code from different teams (and it's not the part of the goal of our sprint). The last problem: we found these pieces of bad code in weeks and months after it's merged. We do code review, but primary for our own teams. – Dmitry Jun 23 '19 at 19:16
  • 1
    To me it looks like your teams are unbalanced skills wise. The code review is done by another person inside the same Development Team. If the writer and the reviewer can't catch the bugs you are talking about, then maybe they are not skilled enough. Consider putting the person that found the bad code in the team that wrote it, so that he/she finds it earlier. This would also help with the "our teams" - "their teams" issue. It's the same product, you are all colleagues, remove any things that make you think that you are not. – Alexandru Jieanu Jun 23 '19 at 19:31
  • The teams are balanced by hard skills, but not soft skills, one of the teams works much faster. It it adds technical debt for another teams. And they don't want to slow down and write more reliable code. – Dmitry Jul 1 '19 at 11:34
  • Sounds like the two teams have different Definition of Done criteria. Try to reach them out to have a common DoD. Inform the Scrum Masters. Use the management authority to get people on the same table to discuss. Don't force an outcome. Now it's "we want" versus "they want", hence the conflict and the practical issues. Do your best and reach a middle ground. – Alexandru Jieanu Jul 5 '19 at 17:52
  • Let me give you a short example. One of the teams for their story created a code with a lot of nested arrays with configs instead of ValueObjects. DoD says that the code should be of goog quality. Coding guide says thet we should use strong static typing when it's possible. Should, not must, because each case is different. And code review from our team says that this code is not good (not Done), code review from that team says that it's good enough. And scrum masters do not have enough expertise in this area. And we don't have an architecture team that is able to solve this problem – Dmitry Jul 6 '19 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.