Organising teams around bounded contexts

[Andrew Easter]

Hi everyone.

I'm interested to hear ideas/opinions/anecdotes around how people align teams to bounded contexts. It's fairly typical to read DDD related literature that talks about bounded contexts being owned by a dedicated team. This can feasibly lead to situations where an engineering organisation may lean towards 'component teams' rather than 'feature teams', although this does somewhat depend on what a particular BC encompasses (e.g. some people will design their BCs as vertical end-to-end slices, UI to data layer).

Agile practitioners generally talk about favouring 'feature teams' over 'component teams' and so there could be some conflict here.

I'm particularly interested to understand if people have worked in environments where there are multiple BCs with multiple feature teams diving in and out of the various BCs where applicable. Is this something that can work? On the face of it, one could imagine such a setup lacking ownership, unless, of course, there are maybe BC experts who attach themselves to whatever team is currently working in 'their' context.

Interested in your thoughts!

Cheers,

Andrew

[Kijana Woodard]

As a baseline, check out the spotify model.

https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Easter]

An excellent read, thanks for the heads up.

Andrew

[@yreynhout]

Having each team own one or more BCs is a strategic advantage, since, as requirements change and shift from one BC to another you could downscale/upscale resources. I do believe you need to keep a set of core team members around, otherwise things turn to waste fast. The amount of communication overhead and cognitive overload associated with context switching/bounded context hopping is something that isn't perceived until it's too late. In general I try to make the boundaries as stable as possible first, orient teams around BCs, keep a core team on the BC after bootstrapping/few initial versions. "Feature teams" meh. Story telling, scenario exploration, making contracts and expected behavior between BCs explicit, and someone that may oversee a feature reaching completion from a high level should be adequate. Hopping teams bring their own styles and preferences, polluting a code base one iteration at a time. "Team"="Bounded Context" is where it's at for me.

[Alberto Brandolini]

In a small company, a team will end up managing more models than what could be fitting into a single Bounded Context. What might be handy in those cases is to have a visually available context map to point to in a "where are we" fashion.

In general I prefer to use Purpose as a primary indicator for a Bounded Context. This normally maps to a single stakeholder/domain expert, and language consistency turns out to be facilitated. However different bounded context (i.e. one for planning and another one for execution) might still be on same team & same stakeholder. So that's where purpose come in handy for smaller consistent models.

However, that's not the easiest starting point with legacy apps, where naming tricks have been applied to ensure consistency within larger-than-needed bounded contexts, that end up not having a single purpose.

A "Feature Team" might well work on different bounded context. I'd be happier if the feature team is also aware of this by looking to a context map and state: "this feature will require us to work in BC 'A' and in BC 'B'" even if in most cases, features would be contained into one BC.

Alberto 

--

[Kijana Woodard]

I like this.

Even when working alone, I like to think of myself as "switching teams" when crossing boundaries.

[Andrew Easter]

@yreynhout - your views on feature teams are interesting to me. I've seen plenty of people advocating the continued use of feature teams when scaling agile, but I've seen plenty of evidence of large dev teams in the real world structuring themselves around components/contexts. I've personally not had great experiences of trying to scale the feature team approach - it's tended towards a rapidly deteriorating codebase as it's difficult for developers to feel the same level of ownership that one garners from feeling intimately responsible for a specific component/context. It's certainly not a black or white type thing, there's no right or wrong. There are always trade-offs with any approach, and it's important to be aware of those.

@alberto - i really like the idea of encouraging individuals/teams to explicitly identify when they are context switching. I also agree that, if the boundaries are drawn correctly around purpose, teams will naturally end up sticking to one BC for a lot of their development. An obvious exception I can see to this is where there is a heavy reliance on one or many Composite UIs. This raises the question as to whether each Composite UI is itself a separate BC...if so, things begin to look less feature team oriented, unless there are clear strategies for supporting context switching. As @yreynhout alludes to, I think there's still a lot of value - in large systems - to have some consistency in terms a core set of people (or person) permanently aligned to a BC to prevent chaos whether or not context switching is embraced.

[@yreynhout]

In smaller setups, where the # team members (e.g. 2 - 4) is less than or equal to the # of bounded contexts (or models), I found it valuable to know the "value" of a context/model. The team could apply the right dose of "quality" to each model. Even the testing strategy tended to be somewhat different. There's also an aspect of empowerment for team members that would otherwise live in the shadow of others - there are now chunks of functionality they can take on themselves - the occasional screw up doesn't have to be that big a deal anymore - I'd even attribute an aspect of growing and maturing as a developer/modeler. One thing to watch out for is that only one person is intimate with the details (truck factor and all that) - it's not about sole ownership. We're just recognizing that not everybody knows every detail about every context. Boundaries are great for having conversations on the overall feature at a different level of abstraction/granularity. It's also a way to negotiate the pace at which one can progress or figure out intermediate solutions on the road to completion. The fact that work can happen in parallel, that bottlenecks become clearer, etc ... allows for a better plan d'attaque. Like Alberto, I tend to favor visualization using a context map, and augment any conversation with visualization techniques that fit the problem. Every feature, every story requires a whiteboard session - if only to surface that we still have to many unknowns and more analysis/research is required or that we want to reduce scope due to the sheer amount of work or to explore lighter, just as effective alternatives.