Ugrás a fő tartalomra

How a relaxing coffee turned into strategic modeling...

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!

We have been living in our house for half a year now, and a couple of weeks ago, 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? 

If you want to learn more about the different options how to align teams and design organizations, come to mine and Nick Tune's  workshops later this year:
Or you can contact us with any questions or for more details:

Megjegyzések

Népszerű bejegyzések ezen a blogon

The 12 meter: where sailboats and EventStorm Walls meet

If I say  12 meter   what do people associate it with? They imagine it as a distance, but it is also a rating class for racing sailboats that are designed to the international rule. But since last week I also know that it can be a space where a mid-sized company's let's say "normally healthy business' story" can fit in 😉   Well, yes I finally managed to attend an EventStorming workshop. But this workshop wasn't just any  EventStorming workshop. This was  The  EventStorming Workshop This was a Master Class for  EventStorming enthusiasts directly from the Master, the Inventor: Alberto Brandolini .  Even better this was the first  EventStorming Master Class in Italy that was held in English. Yeah actually otherwise it wouldn't have been too useful for me to attend,right?  And it is not just Alberto (sorry, Alberto) who makes the training awesome, but Enrico who  always tries his best to arrange everything that participants need or might n

Why constructors don't want to learn from their mistakes?

This is the third morning I wake up very early because our neighbors are very loud and they are continuously arguing on something. 😠 I couldn't fall asleep again so I was thinking. Was thinking about why I can hear every single word they are yelling at each other.  I had bunch of thoughts then, a mini root cause analysis in my mind.  Why I am hearing these stuff?  W hy isn't there good enough insulation in the house?  W hy the hell I cannot make the constructor change this?  Well, w hy the hell we hadn't discussed it with them in advance, when it would have been easier to amend anything?? Actually...why the hell they don't care/don't want to know these stuff?  And that's the point! They don't want to know. Constructors never want to learn from their mistakes. Or they don't dare to learn?... The "normal" way of a house handover is if the constructors manage to hand it over and if the buyer doesn't notice the deficiencies