-
I'm experimenting with a way to visualize 👉 Capability/Domain Responsibilities Boundaries 👉 Process Coupling 👉 Team Structure to deliver them! I'm trying to combine: 👉 Business Capabilities 👉 Business Processes 👉 @TeamTopologiesPermalink On twitter.com
♻️ 2 Retweets ❤️ 7 Favorites Mood +2 🙂
-
I'm using Business Capabilities and Business Processes that I learned in the @VaughnVernon and @tjaskula book I saw less barriers to communicate intention and meaning with business instead of the DDD language about Bounded Contexts and Subdomains amzn.to/3a2gYvyPermalink On twitter.com
-
@VaughnVernon @tjaskula I think this type of diagram could lead to some Framing Bias. We might think that the optimal is to have one Steam-Aligned Team per Business Capability. Which might or might not apply depending on the business needs... Doing another iteration in a mnt en.wikipedia.org/wiki/Framing_effect_(psychology)Permalink On twitter.com
-
@VaughnVernon @tjaskula Organizing Teams based on Business Processes instead of Business Capabilities. This can be also an option. Yet, building teams around business capability looks more sensible due to their nature.Permalink On twitter.com
-
@VaughnVernon @tjaskula 👉 Business Capabilities don't change often 👉 Business Processes are rapidly changing to adapt to the user needs. If we aim for Long-Lived Teams, building teams around business capabilities looks like a better approach IMHO.On twitter.com
-
It also can be a good exercise to do with other people. 👉 Which teams are delivering those business capabilities? 👉 How are teams communicating this business process dependencies? We can have great outcomes in understanding how other people think of teams are organizedPermalink On twitter.com