Collaborative Software Design How to facilitate domain modeling decisions (Evelyn van Kelle, Gien Verschatse etc.) (Z-Library)

(This page has no text content)

       Collaborative Software Design HOW TO FACILITATE DOMAIN MODELING DECISIONS   Evelyn van Kelle, Gien Verschatse, and Kenny Baas-Schwegler   FOREWORDS BY DIANA MONTALION AND TROND HJORTELAND   To comment go to liveBook     Manning Shelter Island

  For more information on this and other Manning titles go to www.manning.com  

Copyright For online information and ordering of these  and other Manning books, please visit www.manning.com. The publisher offers discounts on these books when ordered in quantity. For more information, please contact    Special Sales Department Manning Publications Co. 20 Baldwin Road PO Box 761 Shelter Island, NY 11964 Email: orders@manning.com    ©2025 by Manning Publications Co. All rights reserved.    No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in the book, and Manning

Publications was aware of a trademark claim, the designations have been printed in initial caps or all caps. ♾ Recognizing the importance of preserving what has been written, it is Manning’s policy to have the books we publish printed on acid-free paper, and we exert our best efforts to that end. Recognizing also our responsibility to conserve the resources of our planet, Manning books are printed on paper that is at least 15 percent recycled and processed without the use of elemental chlorine. The author and publisher have made every effort to ensure that the information in this book was correct at press time. The author and publisher do not assume and hereby disclaim any liability to any party for any loss, damage, or disruption caused by errors or omissions, whether such errors or omissions result from negligence, accident, or any other cause, or from any usage of the information herein.        Manning Publications Co. 20 Baldwin Road Technical PO Box 761 Shelter Island, NY 11964    Development editor:   Karen Miller Technical editor:   Charles Schafer Review editors:   Adriana Sabo and Dunja Nikitović Production editor:   Andy Marinkovich Copy editor:   Julie McNamee Proofreader:   Jason Everett

Typesetter:   Tamara Švelić Sabljić Cover designer:   Marija Tudor       ISBN: 9781633439252

dedication To Roger, Beasty, Lulu, and Mr. Noodle, our cats who were absolutely no help at all.

contents          Front matter forewords preface acknowledgments about this book about the authors about the cover illustration      1   The need for collaborative software design   1.1   Design decisions gone wrong at BigScreen Understanding the landscape BigScreen’s attempt at refactoring   1.2   BigScreen: How collaborative modeling helped to improve design decisions Our approach for BigScreen The new architecture A brief history of software design The Agile theater Enabling teams to do collaborative software design   1.3   Collaborative software design as a catalyst for better design decisions Collaborative modeling, design, and architecture Collaborative modeling ingredients and potential benefits of facilitation

The effect of social dynamics on collaborative modeling sessions Collaborative decision-making   2   What is collaborative modeling?   2.1   Understanding the business problems What problems are we trying to solve? What is collaborative modeling? Exploring business problems using collaborative modeling   2.2   Domain-Driven Design and collaborative modeling What is Domain-Driven Design? Who are the stakeholders? Why DDD and collaborative modeling go hand in hand   2.3   Different collaborative modeling tools Collaborative modeling in the problem and solution space EventStorming Example Mapping Domain Storytelling When to use what tool   2.4   Collaborative software design catalysts   2.5   Further reading   3   Using collaborative modeling for design and architecture   3.1   What is software design and architecture? The importance of meaning and definitions What is software architecture? What is software design? What are sociotechnical systems? Design decisions and collaborative modeling

  3.2   Heuristics for collaborative modeling What are heuristics? Competing heuristics How to use heuristics   3.3   Driving the design by understanding the business Designing boundaries Why boundaries are designed through collaboration From design to architecture   3.4   Collaborative software design catalysts   3.5   Chapter heuristics   3.6   Further reading   4   The ingredients of collaborative modeling   4.1   The collaborative modeling stages Why use our stages? The stages   4.2   Preparing for a session Preparing the content Preparing the space   4.3   Sensemaking Conscious and unconscious minds Opening up conversations What is sensemaking? Why would you do sensemaking? In-person or remote? Premortem   4.4   Check-in and check-out What is a check-in and check-out? Characteristics of a check-in and check-out

Why would you do a check-in and check-out? Capturing feedback through check-outs   4.5   Different collaboration styles for modeling with tools Together, Alone Split and Merge Small Group Diverge and Converge Liberating structures: 1-2-4-All Ensemble Fishbowl Anarchy! Guerilla The secret modeler How to use the styles   4.6   Retrospective Evaluating the outcome of the session When we don’t do a retrospective   4.7   Collaborative software design catalysts   4.8   Chapter heuristics   4.9   Further reading   5   Facilitating collaborative modeling   5.1   The role of a facilitator The facilitator as an observer Other stances of a facilitator   5.2   The core competencies of a facilitator Neutrality Observing Compassion Using and learning the core competencies   5.3   Skill set of a facilitator

Clear communication Active listening Holding space   5.4   Facilitating sensemaking and collaborative styles Why do you need a facilitator? The role of a facilitator during sensemaking Facilitating check-ins and check-outs Preparing to facilitate sensemaking Facilitating collaborative styles What if you’re not the facilitator?   5.5   Dealing with remote facilitation Benefits and potential downsides of the different forms Preparing a remote facilitation   5.6   Collaborative software design catalysts   5.7   Chapter heuristics   5.8   Further reading   6   The influence of ranking   6.1   Ranking explained What is ranking? Implicit versus explicit ranking Symbolic violence Epistemic injustice   6.2   Becoming aware of ranking during collaboration and software design Group ranking People   6.3   Facilitating ranking Analyzing the group rank Own, play, and share your rank

Making the group aware of their rank   6.4   Collaborative software design catalysts   6.5   Chapter heuristics   6.6   Further reading   7   The effect and opportunities of cognitive bias   7.1   Cognitive bias explained What is cognitive bias? What does cognitive bias look like? System 1 and System 2: A crash course Embracing cognitive bias   7.2   Cognitive bias during collaboration and software design Confirmation bias The law of triviality False-consensus effect Availability bias Loss aversion Additive bias   7.3   Facilitating cognitive bias Self-fulfilling prophecy Altering behavior through nudges The different dimensions of nudges Becoming a choice architect   7.4   Collaborative software design catalysts   7.5   Chapter heuristics   7.6   Further reading   8   Resistance and conflict resolution

  8.1   Why people show resistance and have conflicts What conflict is all about Edge behavior What is resistance?   8.2   Resistance and conflict during collaboration Recognizing resistance and conflict in collaborative modeling The effect of resistance and conflict on software design Resistance and conflict as learning opportunities   8.3   Facilitating toward a resolution Resistance and conflict in practice Kissing the group over the edge Creating role fluidity   8.4   Collaborative software design catalysts   8.5   Chapter heuristics   8.6   Further reading   9   Making sustainable design decisions   9.1   Decisions, decisions, decisions What is a decision anyway? Decision vs. outcome What you need to make a decision Reactive vs. proactive decisions Sustainability in software design   9.2   Decision-making styles and levels of buy-in Autocracy vs. democracy Creating buy-in on decisions Buy-in on software design decisions   9.3   Facilitating sustainable design decisions Moving toward a majority vote

Go fishing!   9.4   Collaborative software design catalysts   9.5   Chapter heuristics   9.6   Further reading 10   Managing unsolvable problems 10.1   Polarities: Some problems can’t be solved What are polarities? Recognizing polarities Common polarities in collaborative modeling Crusaders and tradition bearers 10.2   Visualizing a polarity Creating a shared understanding of a polarity Managing the polarity 10.3   Managing polarities during collaborative modeling Getting stuck in a polarity Managing a polarity as facilitator Letting the group manage the polarity 10.4   Collaborative software design catalysts 10.5   Chapter heuristics 10.6   Further reading 11   Communicating and documenting decisions 11.1   Formalizing a decision Finding the consequences Capturing the decision 11.2   Spreading the knowledge through the company Communicating decisions

11.3   Keeping the decision alive The modeling process as a whirlpool Don’t fall in love with your model 11.4   Collaborative software design catalysts 11.5   Chapter heuristics 11.6   Further reading 12   Collaborative modeling beyond software design 12.1   Moving toward understanding the context Focusing on customer needs Connecting business strategy, product, and software architecture 12.2   Collaborative modeling beyond software design Different roles, different modeling needs Customer journeys and EventStorming: A love story Aligning capabilities with your strategy 12.3   Moving toward implementation When to go from collaborative modeling to coding From collaborative modeling to code 12.4   Collaborative software design catalysts 12.5   Chapter heuristics 12.6   Further reading    Appendix   A.                       index

front matter forewords I was lucky. Early in my software engineering career, I worked on teams where collaborative modeling and collective reasoning were the norm. Whenever we didn’t know what to do, we whiteboarded. Sometimes, we were a group of engineers solving a technical problem. More often, we were a cross-functional group that included business and product people, technology implementers, software users, UX designers, a vendor or two, and/or subject matter experts from other teams. Thinking well together, synthesizing expertise, and learning from each other were critical to our success. We understood, from painful experience, that “all models are wrong, but some are useful.” This doesn’t mean that people make inaccurate models. This means that modeling is the cultivation of shared understanding, not the production of an artifact. A model conveys a point of view. Modeling integrates relevant points of view into something useful. My teammates and I knew that to design a solution, we had to understand the problem. We had to be in the room where the modeling happened. Our success depended on creating conceptual integrity, which Fred Brooks said “is the most important consideration

in systems design.” We liked to solve hard problems and take on hard challenges. To meet those challenges, we never had the luxury of being 10x individuals. We had to be 10x teams. Over the years, I’ve seen processes that support conceptual integrity break down. As relational complexity in our software systems increases, roles and teams are increasingly siloed. Problem thinking is decoupled from solution thinking. Wars break out between product and tech. Decision-making is progressively hierarchical. The self- organizing aspiration of Agile turns into “We hate Agile, now what?” As a systems architect, this breakdown has made “modernization” and “transformation”—things many organizations want and need—a Sisyphean effort. Jay Forrester, a pioneer software system scientist who taught at MIT, said that organizations can usually identify their problem spots because people are busy fixing them. Alas, their fixes often make the problem worse—“pushing it in the wrong direction,” Forrester said. Referring to this counterintuitive phenomenon, he stated, “The known and intended practices of the organization are sufficient to create the difficulties being experienced.” He also discovered that, inevitably, organizations blame the wrong causes for their problems. We are, in my experience, pushing things in the wrong direction. Creating and maintaining conceptual integrity is more important than ever. Yet we are fighting for control of software design and blaming each other for causing the

problems. I see fewer teams demonstrate the critical learning-together skills they need to design relationally complex software systems. Our lack of collaborative software design is creating many of the difficulties we experience. I understand, to some extent, why this happens. When I contributed code to monolithic software, I could envision the relatively synchronous context in which users engaged with it. I could follow established best practices. The scope of what we needed to understand seemed vast but was boxed nicely into a codebase or two. Now, everything I work on is a system of software parts interacting with and structured by other software. The same information structured for one context (on a desktop web browser) needs a different structure for another context (when asking Alexa). Information systems change quickly. The paradigm is shifting around us, and we are all scrambling to figure out what to do about it. We are lucky. In Collaborative Software Design, Evelyn van Kelle, Gien Verschatse, and Kenny Baas-Schwegler help us develop, or discover, these critical skills. They know from experience that social skills are the “hard skills.” Our biggest blocker is rarely “We don’t know enough about Kubernetes,” but instead, “How do we think well together?” Fortunately, they’ve written a book that helps us transform the social dynamics that hinder sustainable software design. When I’ve felt out there on my own, I’ve learned from them,

tested their teachings in the real world, and improved my professional impact as a result. You’ll learn how to structure, participate in, and facilitate collaborative experiences that generate significantly better software outcomes. You’ll understand the social dynamics that are currently blocking our ability to think well together. This understanding will help you navigate change, make effective decisions, and model effective thinking practices in your organization. Through their BigScreen examples, you’ll see that your pain is not unique. We are all experiencing the painful limitations of our current approaches. This book offers us approaches that help alleviate our pain. You might be surprised that a book with no code samples can improve code quality. By illuminating the most common impediments we face as knowledge workers, this book helps you avoid them. And, it encourages you to provide leadership by experience and example in situations where shared knowledge is key to your success. —DIANA MONTALION, SYSTEMS ARCHITECT AND AUTHOR OF LEARNING SYSTEMS THINKING Have you ever been to a workshop that not only created a desirable result but even made you all feel energized and wanting to get started realizing what you as a group had created? Maybe you even had a newfound respect for people who were not like you at all and worked on things you didn’t even think necessary. Or perhaps you’ve been to

Statistics

Uploader

Collaborative Software Design How to facilitate domain modeling decisions (Evelyn van Kelle, Gien Verschatse etc.) (Z-Library)

Tags

Text Preview (First 20 pages)

Registered users can read the full content for free

Comments 0

Statistics

Uploader

Collaborative Software Design How to facilitate domain modeling decisions (Evelyn van Kelle, Gien Verschatse etc.) (Z-Library)

Tags

Text Preview (First 20 pages)

Registered users can read the full content for free

Comments 0

Reply to Comment

Edit Comment