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:

Címkék:

Megjegyzések

Megjegyzés küldése

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
Megjegyzés küldése
További információk

A real life example why it is better to focus on the problem first

Let me share an experience from real life where I realized why it is important to focus on the problem and not the solution.. We bought a house recently, but this story is from the time right before we bought it. Probably most of you've already gone through the process of applying to a bank loan in your lives. There is a point at which bank comes and check your house and estimate its value. The amount you can get from the bank depends on this estimated value.  But let me just start at the beginning… We were in a DIY shop looking around for the latest things our builder had asked us to buy. Anyways. Steve told me that we also needed to buy a house number. I was like ok let's look at the house numbers in the proper aisle of the store.  We went there and after a while we managed to pick the numbers and we realized we needed a slash sign as well. So, only three numbers and a slash; however as you probably know you can never find more than three things that match
2 megjegyzés
További információk