This is a story from summer of 2018…We had one simple idea: to enjoy a relaxing coffee in our garden. I didn’t expect that I would need to use all of my Domain-Driven Design skills for this!
We had been living in our house for half a year that time, and one day when the weather was perfect, we had a “crazy” idea: why not sit outside and have our coffee in the terrace?
Sounds reasonable, right?
Little did we realize the implementation was a bit more complex than it sounded. Because in order to sit there and enjoy the sunshine (with the coffee of course), we realized we needed to take all the stuff away from the terrace to have enough space there for the garden furniture.
Oh, wait! We had no proper furniture that time. And we also had no idea where to put the stuff from the terrace.
So first thing in the priority order was to buy a storage shed. Then it needed to be assembled. Then if that was done, we needed to pack everything that we wanted into the shed to free up space on the terrace. Only then could we put the furniture there — which we also needed to buy — and sit outside finally with the coffee!
These dependencies were strict and we couldn’t change the order of them (1. shed project 2. furniture project, 3. coffee project). But those could’ve been well separated if we would’ve had more “teams” to collaborate. One to buy the furniture (and then put it together), one to buy the shed and one (or maybe the same) to put the shed together. And one to pack stuff into the shed.
But we were like ToC (Theory of Constraint), one single team did everything in a much longer time (having no other options 😊)..But at least keeping the “business” goal in mind all the time: the ice coffee on the terrace..
So if you had more let’s say teams to do this whole backlog in a weekend, how would you align them? Would you have a separate buy and an assemble context maybe? And then you have the possibility to further divide into more teams; one for buying the garden furniture and one for buying the storage shed? As these things probably need to be bought in separate stores…
Or would you rather have a furniture and a shed context? In this case, you shouldn’t forget that you need mixed skillsets for your people in teams: specialist skills for buying the shed, and specialist skills for assembling the shed. And likewise for the furniture..
Anyhow, your teams either way need to collaborate. Either when “buy context” hands over stuff for “assemble context”. Or if you have the other setup, when furniture needs to be put into the shed context. You probably see that you would need another team that does the packing and cleaning (tidying up the terrace before the furniture can go there). You might or might not want to make this done by separate teams but probably when shed context’s team/s are done they could do it.
So there are many options even in this small real life context I brought up here… it’s not easy to group things and put boundaries around them, because a thing may share characteristics with one group of things (e.g. furniture) and different characteristics with another group of things (e.g. buying).
Not only is it hard to find boundaries, but we live in eco-systems that are constantly evolving, and we continuously need to adapt the designs of our teams and software systems to remain competitive. Which reminds me… which context should the BBQ live in 😉?
There is always the question: should we align teams with user journeys, business sub-capabilities, business process steps or something else?