4

About a year ago we started on the journey of slowly breaking apart our legacy E-commerce platform and replacing it with smaller rewritten services. We now have several teams each focusing on separate areas of the website e.g. Checkout, Cart, Search etc etc

Each of these teams looks after a number of services that deliver the functionality they are responsible for. The challenge we are facing is how to keep these teams co-ordinated, following the same practices, respecting the high level architecture requirements, maintaining API's that are suitably similar (e.g. using the same terminology for concepts such as the cart/basket) without dumping a load of meetings and process on to them? One of the big benefits of our current setup is that developers feel empowered and we don't want to remove that entirely!

  • "Your questions should be reasonably scoped..." (help center) – gnat Sep 24 '17 at 17:32
  • 1
    If your developers are empowered, why don't you ask them or just trust that they will achieve this (as long as you clearly communicate the need)? Or do they just feel empowered? – Derek Elkins Sep 24 '17 at 18:54
  • 1
    Did these communication and coordination problems exist prior to breaking your monolith application apart? – Greg Burghardt Sep 25 '17 at 0:00
  • @GregBurghardt not to nearly the same degree no – Sutty1000 Oct 3 '17 at 20:25
5

In order to facilitate the mutual understanding of the different teams, you may consider domain driven design. It brings the following benefits:

  • use of a same terminology across the teams ("ubiquitous language")
  • use of bounded contexts for delimiting independent sub-domains deserved by different teams (e.g. sales and accounting)
  • use of a context map, to clarify the relationship between bounded contexts and related terms used by different teams.

Domain driven design also defines principles to design a good API. However, design principles are not sufficient. You also need some cooperation between the teams in order to identify the respective needs and requirements, so to define the most appropriate API. One way to handle this is to have an integration team (one representative of each team to make the link between the global integration team and the sub-teams). This is best organized to the scrum of scrums principle.

Beyond integration issues, the scrum of scrum approach is also suited to scale scrum beyond a small team. As such it is also a good option to keep the releases and the sprints in sync across the sub-teams.

  • To add to what @Christophe said, you may find yourself looking at a scaling framework like LeSS, DAD, or SAFe for ideas. You may find that a practice like scrum of scrums may be sufficient, or decide to adopt a framework wholesale, or to forge your own path. – neontapir Oct 18 '17 at 22:52

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.