Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf

Software is increasingly crucial in our lives, but developing effective software systems is still a major challenge. This issue often comes from teams focusing on solutions rather than deeply understanding the business problems they are trying to solve. A crucial shift towards Collaborative Software Design is needed; it brings together technical expertise with a solid grasp of both user and business needs. As an important part of Domain-Driven Design (DDD), this approach jointly optimises user journeys with business processes. It enhances team communication, facilitates in making well-informed decisions, minimises errors, and removes blockers to flow between stakeholders, user designers and the team thus maximising the software's value and impact. Most importantly, it establishes a shared understanding among all stakeholders and the team. Adopting this strategy is vital for the creation of high-quality, resilient, and user-centric software.
The challenge is in requiring all stakeholders to actively collaborate in the same physical environment, managing complex social dynamics. The key to success in Collaborative Software Design is managing these interactions within a sociotechnical framework.
Join Evelyn and Kenny as they show how Collaborative Software Design enables teams to develop a shared understanding with stakeholders. This understanding becomes a living record of the current business needs and the software landscape, guiding the design for future developments.

Transcript

1. Bridging the Design Gap: How Collaborative Modelling removes blockers to flow @kenny_baas @kenny_baas@mastodon.social Photo by Agnieszka Ziomek on Unsplash
2. @kenny_baas @kenny_baas@mastodon.social Photo by Bernard Hermant on Unsplash
3. @kenny_baas @kenny_baas@mastodon.social In the meantime at a grocery shop around the corner from Evelyn Context changes everything
4. @kenny_baas @kenny_baas@mastodon.social Home deliveries Flow of change Restaurant POS Photo by Ana Vieira on Unsplash The Takeout Customer wants to know an accurate ETA before completing the order Some Stakeholder Payment team Who will they ask? *note: this is a made up example!
5. Restaurant POS Home deliveries @kenny_baas @kenny_baas@mastodon.social Home deliveries Restaurant POS Payments Restaurant POS Home deliveries restaurant system Takeout app Home delivery ordering Takeout Customer Select products for home delivery Know delivery time Legend / Key User Need capability External capability User Depends on Process Software System Make an order for home delivery Pay For home delivery order Home delivery Fulfilment Restaurant employee Accept order Request food deliverer for a specific time Prepare order for home delivery Hand over order to deliverer Product page Home delivery order page Payment module Home delivery service restaurant service Payment service Payment provided Restaurant service Delivery broker Takeout app Takeout Customer When does my delivery arrive? What orders do I need to prepare Home delivery service Food delivery services Restaurant backoffice SPA Food Deliverer Deliver food Home delivery service Restaurant service teamtopologies.… Exploring team and service boundaries with User Needs Mapping - Team Topologies User Needs Mapping refers to the first four steps of the Wardley Mapping process that can provide significant value when helping understand users/customers, their needs and the dependencies required to deliver those needs within an organization. By mapp… Stream-​ aligned team Platform team Complicated Subsystem team Enabling team This is quirky! Quirky, why is delivery broker not with the other team? The landscape is never "aligned" *note: this is a made up example!
6. @kenny_baas @kenny_baas@mastodon.social Photo by Simon Kadula on Unsplash Everyone who communicates within an organisation that is building software is a software designer!
7. @kenny_baas @kenny_baas@mastodon.social indiyoung.com X Explanations Problem Space The problem space is a person's domain. It's where they are addressing something they want to make progress on, or put off, or just think about. The problem space is separate from your solutions, although the person may reach out for your tool along the… https://indiyoung.com/explanations-​ problem-​ space/ 💡Software design starts HERE However stream-​ aligned teams are usually involved somewhere here
8. @kenny_baas @kenny_baas@mastodon.social https://amplitude.com/blog/journey-​ to-​ product-​ teams-​ infographic AKA blockers to flow
9. Purpose, needs & Problems Value stream: All activities a team performs from understanding the purpose & problem to building that solution without being blocked Solution Feedback Stream-​aligned team: Long-​ term design + build + run for software-​ enriched services in a small, stable team of around ~5-9 people Team first! @kenny_baas @kenny_baas@mastodon.social 💡You DESIGN it, you build it and you run it! Stream aligned teams, should aim to become product teams!
10. @kenny_baas @kenny_baas@mastodon.social Software team Stakeholders design, build, run solution(s) Express purpose, needs and problems Feedback The delayed feedback loop creates a knowledge gap between the implemented solution and the stakeholders' understanding. At times, there is a product owner, architect, UX designer, or other role acting as an intermediary. Individuals or groups, either within or outside the organization, who are invested in the outcome of solving these business problems 💡Stop managing dependencies start unblocking flow Code Tests Diagrams Documentation Observability
11. Projected in @kenny_baas @kenny_baas@mastodon.social Software team Stakeholders design, build, run solution Pool of shared meaning the sum total of knowledge, perspectives, opinions, meaning and feelings that participants in a conversation have regarding the topic at hand 💡The pool can vary in size. The delayed feedback loop creates a knowledge gap between the implemented solution and the stakeholders' understanding. Not all knowledge is returned, like technical knowledge Code Tests Diagrams Documentation Observability
12. @kenny_baas @kenny_baas@mastodon.social Unblocking team flow requires continuously cultivating the shared pool of meaning. And that cultivations happens in interactions Photo by Dragan Miljkovic on Unsplash
13. @kenny_baas @kenny_baas@mastodon.social Software team Code Tests Stakeholders design, build, run solution The delayed feedback loop creates a knowledge gap between the implemented solution and the stakeholders' understanding. Pool of shared meaning Projected in Market User research Strategy Projected in The delayed feedback loop creates a knowledge gap between the implemented solution and the stakeholders' understanding. Not all knowledge is put into the pool 💡User experience design of the product should be part of the team! Diagrams Documentation Observability
14. @kenny_baas @kenny_baas@mastodon.social The pool can quickly become a whirlpool when navigating the problem space Photo by heraldscotland
15. @kenny_baas @kenny_baas@mastodon.social Collaborative modelling is a visualisation technique to analyse complex and conflict-​ laden decision-​ making processes with all relevant stakeholders and decision-​ makers to create a shared understanding.
16. Domain is a sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software. An area of interest or an area over which a person has control It is all about grouping concepts. Within Domain-​ Driven Design we call the entire problem space we are modelling the Domain. We decompose that space into several subdomains. If the space is big enough those subdomains can be potentially split into several subdomains again. @kenny_baas @kenny_baas@mastodon.social Using it for Domain Modelling
17. @kenny_baas @kenny_baas@mastodon.social Use collaborative modelling to create a shared understanding
18. @kenny_baas @kenny_baas@mastodon.social Users and stakeholders Code Stream-​Aligned Team Tests Domain Model Other people possibly involved in designing and building software Managers Architects User researcher .....
19. DDD is a discipline rooted in the belief that creating good software systems for problems in the complex domain cannot be done without a deep understanding of the business problems you are trying to solve in the domain. @kenny_baas @kenny_baas@mastodon.social Domain-​ Driven Design
20. @kenny_baas @kenny_baas@mastodon.social We share context, meaning and categorise business needs, purpose and problems. Through that we DESIGN a language and model to solve complex business problems Photo by Travel by Kilts
21. @kenny_baas @kenny_baas@mastodon.social Home deliveries Restaurant POS Payment team Flow of change Bring User Experience and User interface design (UX/UI) in Teams Enable or off-​load User research Home deliveries Restaurant POS Payment team Flow of change User research Enablers User researchers Facilitating Facilitating Facilitating 💡When user research are initiatives 💡When user research is done continuously. Alternate between these two User researchers Xaas Collaboration
22. @kenny_baas @kenny_baas@mastodon.social @EvelynvanKelle What could possibly go wrong?! Let's go!
23. @kenny_baas @kenny_baas@mastodon.social What could possibly go wrong! RIGHT?
24. @kenny_baas @kenny_baas@mastodon.social
25. @kenny_baas @kenny_baas@mastodon.social Humans and their interaction Humans and their interpersonal relationships Humans and their sense of hierarchy and ranking Humans and their assumptions Humans and their personal feelings and opinions Humans and their personal interest …. Humans.
26. @kenny_baas @kenny_baas@mastodon.social Ranking theory Conflict & Resistance Cognitive bias Polarities ... Behavior!
27. @kenny_baas @kenny_baas@mastodon.social Photo by ESIGNECOLOGIST A lot of problems exist because people are ignoring the “socio” in sociotechnical systems
28. @kenny_baas @kenny_baas@mastodon.social Adapted from "Assessing the impact of new technology on complex sociotechnical systems", South African Journal of Industrial Engineering August 2016 Vol 27(2), pp 15-29, R. Oosthuizen & L. Pretorius https://www.researchgate.net/publication/306242078_Assessing_the_impact_of_new_technology_on_complex_sociotechnical_systems Licensed under https://creativecommons.org/licenses/by-​ sa/4.0/
29. @kenny_baas @kenny_baas@mastodon.social Collaborative Modeling is a sociotechnical happening
30. @kenny_baas @kenny_baas@mastodon.social Choosing a certain technology might increase a skill gap that needs to be managed Defining boundaries of bounded contexts might imply team changes Decisions will (most likely...) lead to resistance and conflict ... Technical choices have social consequences and vice versa
31. @kenny_baas @kenny_baas@mastodon.social Who's taking the lead? Who talks first? Who talks a lot? Who isn't talking? Which subgroups emerge during the sessions? Are there a lot of discussions going on? Are people understanding each other? Who is moving stickies around? How much detail is required in this session? How is the group handling decision making? Lots of people in a room...
32. @kenny_baas @kenny_baas@mastodon.social A facilitator! (That can be anyone!) Who you gonna call?
33. @kenny_baas @kenny_baas@mastodon.social Collaborative software design Catalyst What do you need to go along with this decision?
34. @selketjah @kenny_baas @EvelynvanKelle @kenny_baas @kenny_baas@mastodon.social
35. @kenny_baas @kenny_baas@mastodon.social Thank You #CatTax kenny@weave-​ it.org - weave-​ it.org Get the book here