diff --git a/book/proposal/outline.md b/book/proposal/outline.md new file mode 100644 index 0000000..45f8b59 --- /dev/null +++ b/book/proposal/outline.md @@ -0,0 +1,185 @@ +# Outline for Domain Centric Software + +## Chapter 1: Introduction + +Organic software: + +- Seeks a natural progression of its environment. +- Flows and changes effortlessly with its domain. +- Satisfy social needs responsibly. +- Focuses on communicating consistently across the implementation and domain. +- Seek empowering solutions over narrowly targeted solutions. + +Organic software is the modern ideal and quality needed if we seek to perpetuate the success and social responsibility of open source to a wider set of problems. We seek to serve the whole of life, seeking solutions which effortlessly enhance our environments in an informed, thoughtful and responsible manner. + +Crafting organic software is challenging! Solving problems in an appropriate way without first exposing yourself to the situation is impossible! But this is consistently how we approach software development. A product manager tries to understand a feature someone thinks they need, the product manager then condenses this down into an issue that can fit into our software project management process of choice and a developer to implements. + +This leads to a series of problems with the solution, a lack of domain knowledge throughout the organization, misleading code, poor data structures, un-maintainable codebase, insufficient or incorrect solutions and worse. + +We will explore the intersection of the fields of design thinking, agile and domain-driven design as a better way to build products. Taking some of the best ideas from each while escaping some of the implementation details that can limit adoption. + +In this first chapter, we will take a look at what design thinking is, outline the commonly referred to process and pick apart whether it needs to be done in totality. We will explore + +- Discovery +- Ideation +- Prototyping +- Validation +- The Double D method + +Design thinking process can offer an excellent way to engage domain experts in the creation of a product. Domain-driven design offers a set of tools for taking these findings and creating software implementations that more concisely capture the knowledge we have learned. + +I will also introduce domain driven design ideas we will be covering in this book: + +- Ubiquitous languages +- Glossaries +- Context boundaries for primary and supporting domains +- Domain events +- Org personas + +## Chapter 2: Discovery +We will outline the steps a development team is taking to implement a new warranty tool for a bike company. Working on any problem first requires learning everything you can about the problem. This critical phase is often one that software developers are left out of. We will explore why this is and why it should not be the case. + +In this chapter we will introduce the following tools: + +- Stakeholder mapping +- Context Boundaries +- Bounded context diagrams + +The first exercise introduced is a Stake Holder Mapping. This is a method for identifying potential domain experts to consult regarding the current process in place for warranty issues. The StakeHolder mapping also serves as a nice first pass at a bounded context diagram. + + +## Chapter 3: Interviewing and Job Shadowing + +Now that we have identified all the stakeholders and processes we will impact, we can develop a picture of day to day operations. Job shadowing and interviewing are two valuable tools for exploring how the user does the task you are looking to augment every day. + +In this chapter, we will outline how to conduct a successful interview and how to do job shadowing. This includes + +- Using our stakeholder map and context bounding to identify interviewees. +- Getting permission. +- How to run a successful interview process. +- Finding inroads for future collaboration. +- Capturing ubiquitous language. +- Diagramming process flows and updating our experience diagrams with the new context. +- Identifying domain events. +- Looking for hacks and other contextual clues. + +## Chapter 4: Gaining Context + +In this chapter, we introduce two methods for contextualizing information we gained in the prior exercises: + +- Affinity clustering +- Rose, Bud, Thorn. + +Affinity clustering is a method which helps to sort our notes into contextually similar groups. Through this process, we sort the findings and observe groups that naturally start to emerge. Often we find numerous groupings inside a problem area that may map to or expand upon our contextual boundaries. We will use the output of this exercise in three ways, first to redefine our contextual boundaries. Next, we will seek related sets of problems we can later prioritize. Finally, we will introduce ways to utilize affinity mapping to organize our collected language, processes and domain events. + +The second method introduced is Rose Bud Thorn. This is a tool used to categorize findings into positive (Rose), negative (Thorn) and items with potential for improvement (Bud). We will then use this as a way to discuss identifying potential areas for improvement. + + +## Chapter 5: Creating and Using our Ubiquitous Language Glossary +We now have a collection of language and bounded context that will allow us to create a glossary. We will explore what a glossary is and how to create one from your findings. + +- Breaking apart your domain by context boundaries +- Keeping language contextual +- Context Mapping +- Escaping implementation details +- Maintaining ubiquitous language and context boundaries long term. + +The book will also show some pseudo code examples of how this language and context-bound idea can be implemented to lead to cleaner implementation and separation of concerns. We will explore techniques for name-spacing code, organizing files, naming methods vs. objects and separating concerns. One tricky thing in the world of domain driven design is the level of implementation detail, this can prevent adoption or cause friction with timelines or frameworks. We will explore how to accept some ideas but not others. + +We will also explore how to keep these glossaries up to date and useful in your projects. + +## Chapter 6: Defining a problem statement + +Often times our problem statement is handed to us due to business needs, however, the process by which we choose the problem to work on and state the problem are often difficult tasks that can be aided by the process. There are also situations in which we may be using design thinking to explore a new process inside our development processes. + +Defining a problem statement can be political and difficult to write. Our Rose, Bud, Thorn and Affinity Clustering activities have exposed a number of areas which we can focus on but picking one to focus on is a matter of aligning people. When we do define it we need to ensure the language we use is open enough to encourage our creative process, yet bounded enough to keep us focused on our problem area. + +We will utilize explore the proper language for phrasing problem statements and why language matters. Once we have identified the problem statements, we will look at two methods of choosing the problem to work on, bracketing and star voting. + +- How to phrase a problem statement to encourage exploration. +- What is broad enough vs too broad in a statement. +- Choosing one problem statement among many potentials + +## Chapter 7: Ideation + +Now that we have a problem statement to work on we need to start thinking about how to approach our problem. Ideation is a process of generating as many ideas as possible. These techniques are useful in a number of scenarios where you need to generate potential solutions to a well-understood problem. + +We will introduce a few exercises to help with the brainstorming process. + +- Creative matrix +- Story boarding +- Expanding statement starters + +First, we will try redefining the opportunity by changing our statement starter by turning it into a question in the phrases of who, what, when, where, why and how. We will use each of these prompts to define as many answers as possible. + +Next, we will look at creating a creative matrix. In this process, we define 5 assets we have at our dispense to solve the problem and we align those with our domain areas to brainstorm how the statement starter could be solved, approached etc in different combinations of tools and subdomains. + +## Chapter 8: Ranking competing ideas + +At this point we have created a number of competing solutions, deciding which ones to pursue is often politically charged. We need tools to remove the personal attachment we hold to ideas and look at them subjectively. We will look at three exercises for doing this work. These tools are exceptionally valuable for going through backlogs, ranking company alignment goals like OKRs or getting stakeholders to express their needs accurately. + +Method: +- Importance difficulty mapping +- Buy a feature +- Bracket voting + +First, we will look at Importance Difficulty Mapping. In this exercise, we create an (x,y) graph to visualize the importance and difficulty of every item we came up with during ideation in a quadrant. This visualization shows us the low hanging fruit, high-importance difficult items, low-importance low- difficulty items, and low-important high-difficulty items; assisting us in choosing what to work on. + +Buy a Feature is a game in which each player is given a budget and can choose which features they would pay for. This show which features are most valuable to which stakeholders. + +Brackets are a fun way to have features compete against each other for votes. As you work through the bracket people voting are allowed to change what they are rooting for so everyone's voice is heard to completion. + +## Chapter 9: Prototyping + +Now that we have the ranked ideas we wish to implement, it is time to validate our ideas and experiment with competing implementation details. + +There are two types of prototyping that make sense for software developers that I have experienced. + +The first is a user-facing prototype that shows off a feature that they will be working with, this is an invaluable alignment tool for working with stakeholder. + +The second is a technology prototype, often when we set out to build a new feature, app, etc... much of our architecture decision is based on the strongest political position in the room or the most familiar tech. Technology prototypes allow us to break out of this and offer a space to experiment and validate different ideas. We will outline how to run a successful technical prototyping session. + +Methods: + +- User facing prototypes. +- Implementation prototypes. +- Setting up rails to encourage safe experimentation. +- Encouraging playful development. + +## Chapter 10: Validating and learning from Prototypes + +We prototype in order to ensure we are choosing the right direction, but learning from prototypes is an art. We need to separate our preference and bias and see what the prototype is really telling us. We will look at user testing our stakeholder facing prototypes and how to iterate. + +We will also look at tools for qualifying technical prototypes, setting criteria, validating new tech and outlining how to assess risk. + +Methods: +- Inviting users to the testing table +- Paper prototype testing +- Validating technical prototypes by risk assessment +- Combining competing ideas. + +## Chapter 11: Cooking with ingredients + +Throughout this book, we have followed a very defined line of discovery, ideate, prototype and validate. This recipe is common in design thinking, however, the dogma of this process is misleading. Much like a great chef starts by following a recipe, they soon learn to break the ingredients apart and use them appropriately in different scenarios. We can utilize any one of these different methods in a number of scenarios and add a dash of ideation here and a prototyping session there without following the entire process. + +In this chapter we will look at running better retros, aligning a backlog, blameless incident response, prototyping the competing implementation details, and how to run partial or full design thinking process in short periods of time. + +Methods: + +- Bridging the gap with agile +- Developing a design sense +- Slowly introducing teams to these methods. +- Retros. +- Scrum planning + + +## Chapter 12: Going remote + +Many of the tools in this book are possible to do remotely as well. Let's take some of the common methods in this book and discuss how we can bring them to remote teams. + +- Google docs +- Post it note applications +- Story telling sessions +- Sharing videos +- Code as documentation +- Test that represent intention \ No newline at end of file diff --git a/book/proposal/proposal.md b/book/proposal/proposal.md new file mode 100644 index 0000000..53ef73f --- /dev/null +++ b/book/proposal/proposal.md @@ -0,0 +1,160 @@ +# Proposal for Domain Centric Software +### By: Cory Gwin + +## Overview + +Technology is simply a tool for solving a problem. Arguably the most valuable tool any developer has in their tool chest is the ability to understand, communicate about, break down a problem and ultimately provide a proven solution. Most organization find this incredibly difficult to do and often organization focus on how fast they can ship instead of how well their solutions solve a problem. As software developers our problem-solving tools get nowhere near the attention that our text editor skills, language of choice or deployment skills get. Instead, we hand it off to other parts of the organization and later complain about them throwing requirements over the wall. The time has come to break down the wall and become closer to the problems we are solving. + +The agile manifesto states we should prefer customer collaboration over contract negotiation. Most developers live in a process I will call task board shuffle leaving implementation to be done in a knowledge vacuum. This leads to a number of problems: + +- Downstream communication issues. +- Misunderstood requirements. +- Incorrect implementations. +- Developer frustration. +- Scope change or creep. +- Lost context over time. +- Code that does not properly convey the domain. +- Poorly modeled data. +- Mis-prioritization. + +Our workflows and structures create communication barriers we must break down in order to move our implementations closer to their domains. As developers, our goals should include moving ourselves and our code closer to the domain. This requires understanding not only the problem being solved by a feature but also, more broadly an understanding of the field we are working in. + +We seek to develop a toolset for gathering insight into the domain that can help engineers understand a user's problem leading to: + +- A better understanding of the entire domain. +- A path toward a domain language. +- Bounded Contexts. +- Understanding problem nuance. +- Capturing valuable insight from domain experts. +- Clear task prioritization. +- Identifying focused solutions. +- Foresight into how an implementation may evolve. + +Following the path of a team replacing a legacy application with a new application, this book will explore tools from Design Thinking, Domain Driven Design, and Agile introducing methods that can be utilized to break down a domain and better communicate with domain experts. + +After reading this book developers will feel equipped to: + +- Interview domain experts. +- Capture domain knowledge and translate it into domain centered language in a software application. +- Better understand the problem space they are developing a solution for. +- Learn how to clearly communicate with domain experts about their business problems. +- Evaluate potential software solutions and implementation choices without bias. +- Engage domain experts earlier in implementation for feedback, in order to avoid mistakes as soon as possible. +- More cleanly represent the domain in code and data stores. +- Run blameless retrospectives. +- Engage methods to learn from outages and identify solutions. + + +## What this book will cover: + +- Introduce the concept of design thinking. +- Introduce the following design thinking methodologies from the perspective of the developer: + - Stakeholder mapping. + - Interviewing. + - Job Shadowing. + - Rose Bud Thorn. + - Affinity Mapping. + - Experience diagramming. + - Importance/Difficulty matrix. + - Feature Voting. + - Creative matrixes. + - Technical prototyping. + - Storyboarding UI's + - Stakeholder validation. + - More?? +- Introduce domain driven design concepts: + - Ubiquitous language. + - Context bounding. + - Domain events. +- Outline effective tools for using design thinking to create ubiquitous language, bounded contexts and domain events. +- Outline rules for effective design thinking on agile teams. +- Discuss ideas for bringing these methods into teams that are not familiar with design thinking. +- Processes for rapid prototyping. +- Tools and processes for beta testing features. + +## Audience: +This book is targeted at developers and architects seeking ways to work more closely with domain experts in order to understand complex problems and craft informed domain centric implementations. + +## Why is your book different? + +This book will offer a number of methods from design thinking, agile and domain driven design aimed at bridging the gap between domain knowledge and implementation. This marriage of skills will be separated from heavy handed implementation details and instead focus on methods for interacting with domain experts to extract information useful in crafting domain centric software and more creative solutions. Skills emphasized include: + +Design Thinking: + +- Communicating effectively with stakeholders. +- Identifying when to utilize design thinking methods and when not to. +- The discovery, ideate, prototype phases of design thinking. +- Individual design thinking methodologies and when to use them in the software development lifecycle. +- Methods for prototyping. +- Hack weeks. + +Agile: + +- How to run better retros. +- Methods to prioritize tasks during sprints. +- How to evaluate what to build given competing priorities. +- Time boxing. +- Encouraging design spikes with guide rails. +- Fitting research into your sprints. +- Team switching for knowledge transfer. + + +Domain Driven Design: + +- Capturing business details from domain experts in a way that transfers to software details. +- Identifying domain entities, domain events, context boundaries, and a ubiquitous language. +- Translating domain knowledge to code via testing, method naming and object naming. +- Understanding bounded contexts in software. +- Building long-lived communication tools that impact internal/external communication and code design. + +## Competing Books +- [Domain Driven Design Distilled](https://www.amazon.com/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420/ref=sr_1_fkmrnull_1?crid=33UZDG9LM3BY0&keywords=domain+driven+design+distilled&qid=1550802381&s=gateway&sprefix=Domain+Driven+Design+D%2Caps%2C303&sr=8-1-fkmrnull): Unlike a traditional domain driven design, domain centric software will focus more on the customer interaction process and how to effectively run these processes. I will largely avoid implementation details and offer more design thinking techniques. I also think domain driven design is limited in that it often leads to automating inefficient processes, thus making fast inefficient process due to it often skipping the ideate and prototype steps that I will be covering. +- [Design It! From Programmer to Software Architect](https://www.amazon.com/Design-Programmer-Architect-Pragmatic-Programmers/dp/1680502093/ref=sr_1_1?keywords=Design+It%21&qid=1550802621&s=books&sr=1-1) This books is a great companion book to mine and I hope to work with Michael to run workshops together. I will be covering more of the design thinking processes in depth then this book as it focuses more on Architectural patterns and choosing implementation by using design thinking to evaluate risk. In an implementation point of view I will be focusing less on architecture and more on capturing the language of the domain in your implementation and also on crafting solutions that meet the problems head on by exploring and becoming familiar with the problem the domain expert is working on. +- [Lean Customer Development](https://www.amazon.com/Lean-Customer-Development-Hardcover-version/dp/1449356354/ref=sr_1_1?keywords=lean+cindy+a&qid=1550802543&s=gateway&sr=8-1) This book covers a number of similar methodologies but it is slanted more towards product development as opposed to gathering information for implementation. I am less interested in finding and validating a market and more interested in creating software that feels like it belongs to the domain. + +## Why we should get excited about your topic: + +In the Cathedral and the Bazaar a number of important ideas were set forth related to working more closely with our stakeholder: + +1. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. +1. Release early. Release often. And listen to your customers. +1. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. +1. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource. +1. The next best thing to having good ideas is recognizing good ideas from your users. +1. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong. +1. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupéry) +1. To solve an interesting problem, start by finding a problem that is interesting to you. +1. Provided the development coordinator has a communications medium at least as good as the Internet and knows how to lead without coercion, many heads are inevitably better than one. + +Interestingly the book contradicts itself pointing out a major issue with the way we develop software: + +> Every good work of software starts by scratching a developer's personal itch. + +The implication here is that we do not know how to collaborate with our users in the same way as when we develop to solve our own problems. + +Domain Centric Software makes a case that in order to solve problems we need to move the solution architects closer to the domain space. I believe in order to replicate the success of the open source movement in a broader way, we need to find ways to bring domain experts together with solution architects to create a new way of interacting. If one is to believe "We are as gods and might as well get good at it" then we need to focus on creating tools for others in a manner we ourselves would accept. + +I intend to present a set of tools to help developers take action on this premise, equipping developers to discuss complex problems with their domain experts in new and collaborative ways. + +## Author Bio: +Growing up I enamored by the house my grandparents lived in, designed by a associate of Frank Lloyd Wright I could sense the oneness it had with the immediate environment. This experience has left me continually frustrated with our inability to create software that encompass the environment of the software in a fluid way. + +In my career I have worked in UI, project management and as a backend developer trying to move myself closer to a place where I can see the thread connecting the problem space back to the solution implemented in our code and how we get there. + +Working at GitHub and watching/participating in the open source movement has made me realize there is a promising pattern available when we collect opinions at a massive scale and understand the domain well, but we do not posses tools and techniques to work on domains other then the domain of the programmer in such a fashion. + +I began trying out design thinking on a job where I was given total control, the results were better then other projects I had worked on and I think it is an incremental improvement. I have found success marrying the ideas found in Domain Driven Design, Design thinking and Agile. I think this combination is unique and beneficial to all significant development efforts. + +## Marketing Ideas +- I live in Pittsburgh near Michael Keeling and we have been discussing teaming up for workshops. +- I like to speak at conferences and run workshops. +- I do some twittering but it is minimal. +- I would be open to podcasting. + + +## Page count: +- 250-300 pages? + +## Timeline +Realistically my first draft will take a year, I am expecting a baby in late May so I think that will slow me down a good bit. + diff --git a/book/proposal/sample chapter.md b/book/proposal/sample chapter.md new file mode 100644 index 0000000..f928854 --- /dev/null +++ b/book/proposal/sample chapter.md @@ -0,0 +1,146 @@ +# Interviewing and Job Shadowing + +What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. Now we will explore some methods for engaging these domain experts to increase our awareness of their language, workflows, entities and problems. + +After working through these exercise with our domain experts we will look to develop internal documents that can be leveraged for current implementation, future on-boarding and to guide conversations and decisions in the future. We will examine interviewing and job shadowing as our two main methods. + +## Aside on note taking +Each of these will provide notes and insights we can capture simply. I like to collect these notes on post it's sometimes I color code them for context but this is up to you. Note taking can be simple scratches of words, crude drawings or complex long form notes. + +I tend to prefer post it notes in most situations as they force me to compress ideas down. In this world I try to create hundreds of notes if possible. It is always ideal to go into any creative process with as much information as possible. + +## Getting Started + +The first step in interviewing or job shadowing is to pick a topic. Picking a topic will often steer us toward job shadowing or interviewing. I finding interviewing to be a good method for getting insights into general experiences or broad stroke conversations. I often find job shadowing to be a better tool for augmenting and optimizing existing processes. + +Often times our topic is chosen by business alignment tools like OKR's, issues in the queue etc. The type of work and the amount of time you have to dedicate to the work will also steer you towards one direction or the other. + +Don't be afraid to shove this process into a short timeframe. Talking to 1 or 2 domain experts is usually better then talking to none. If you are good about time boxing and prep you can get through a couple interviews in 2-3 hours. You can also opt to interview people without adhering to the rest of what this book lays out as process. Just the act of talking with someone can inspire you to take a different more informed direction then you would without that conversation. + +That being said, interviewing properly is important for the output of the interview. + +## Your bias, So am I + +Creating interviewing questions or preparing for a job shadowing exercise can be a bit of a trap. As developers we have strong thoughts and opinions about our users and our products direction. These thoughts and opinions will impact the people we choose to talk to, the topics we lean towards, the questions we ask and how we listen. Acknowledging our biases before starting any sort of interviewing process is a good first step. + +There are a number of common biases to examine prior to entering any period of interviewing. Identifying these biases in ourselves and our team are not just useful for interviewing and job shadowing but can also help us to understand our team dynamics, inter-team communications and product decision influencers. + +The main biases I have seen include confirmation bias, survivorship bias, availability bias and social desirability. + +#### Confirmation biases +Confirmation bias is the tendency to interpret new evidence as a confirmation of one's exiting beliefs. An example of confirmation bias is someone who holds the belief that left handed people are more creative than right handed people. In confirmation bias this individual would place greater importance on this correlation confirming their bias in their mind every time they met a left handed person who was creative, they would ignore the right handed people who are creative. + +If you start to see questions that can be thought of as confirming an idea or seeking evidence of a belief you are probably in the middle of confirmation bias. Also be cognizant of the tendency humans have to ignore disconfirming information, this is how stereotypes perpetuate. + +#### Survivorship biases +During WW2 the US Military was attempting to strengthen the armor on planes. In order to do this they took stock of where the bullet holes on the planes where located and placed more armor in those locations. This is a great example of the problem with survivorship bias. + +The planes hit in the spot where the engineers where putting more armor was pointless because a plane could survive a hit in that location. They later realized they needed to put armor where they were not seeing holes because those planes where not surviving. + +We often see similar scenarios in our own interviews, we tend to interview our best customers or heaviest users. This may be helpful from a relationship perspective, but those users needs are mostly being met. Instead we should try to interview the users that abandon our product for another product. + +#### Availability Biases + +As we go through our day we are bombarded with the current events of our work; support's needs, issues you have been working on, parts of the codebase you wrote etc... Anything that is top of mind can influence how you see or think about a situation. + +This is why if your company just released a shiny new feature you are more likely to suggest it as a possible solution over something that maybe more appropriate that came out 5 years ago simply because it is top of mind. + +#### Social Desirability biases +Anyone being interviewed will be bias toward answering questions in a way that is socially acceptable. When was the last time someone asked you if you test all your code, how did you answer? If you are like most people you don't test all your code, but you said yes, or shaped some story to make it sound like you do most of the time, because you want them to think of you in desirable way. + +This is social desirability bias it is a bit like peer pressure, we have a reason to lie or color the truth because we are trying to align our practices with what we perceive as the socially desired values. + +### How do we interview people without these biases? + +Interviewing people is hard, we have to navigate both our biases and the interviewees. Really great interviewers are hard to come by, but not everyone needs to be Terry Gross to get value out of an interview. + +You can learn to follow a mostly formulaic interview process and get good at it. I am often reminded of a statement a friend of mine told me about interviewing, you have 2 ears and 1 mouth try to use them in that proportion. It really is all about listening. + +Most people love to tell stories, if you can get a person into a story telling mode they will usually become fairly honest and straightforward as opposed to people answering questions survey style. + +So how do we conduct such an interview? + +## Interviewing +Now the fun part, the interview. I like to make sure a few things are in place before I conduct an interview. + +1. A comfortable location with snacks is always nice to have. +2. At least one note taker. +3. An outline of the questions you want to ask. +4. Post it notes and pens. +5. If desired and ok with the interviewee a recording device. + +Next we need to write our questions, an easy way to do this is to use a question starter that encourages story telling. Story telling is the preferred method for interview responses as stories tend to be more organic. Survey style questions tend to impart an answer shaped by bias. + +A great question starter is tell me about, this encourages dialog. Other good questions to ask can include: + +- If you had to change one things what would it be? Why? +- Have you done x differently in the past? +- What do you tell new co-workers when they start? + +Once you have a dialog going, clarifying questions can be used to shed light on the conversation and add priority. + +- If you had x how frequently would you have used it in the past 6 months? +- Just be be sure I am clear if you had x, what would it allow you to do that you cannot do now? +- Tell me more about why you prefer the competitors feature over ours. +- If a genie granted you 2 wishes about the current situation what 2 things would you fix? + +## Asking for permission. + +We always need the participants permission when conducting an interview. Seeking permission often takes setup, this is a good time to set expectations. Why are you interviewing people, how will the interviewee be compensated, how many people are you interviewing, where will the interview take place, what will you talk about with them, will you be recoding, who else will be at the interview and any other relevant information is nice. When setting expectations you want to be clear about what you are doing, but don't get to specific. You can start to color response even before you have an interview. + +Expectations are also dependent on whom you are talking to. Internal users may have insight into what you are working on, while external users may not. Be sure to consider what is appropriate to share or expose in an interviewing process before releasing your companies hot new feature months before it comes out. + +### Template of an interview + +There is a common pattern to an interview you can follow to make things more natural, I even put this into a template to remind myself of the steps to take. + +The first step in the process is an introduction. In this portion of the interview we need to cover the following three items: + +1. Introduce yourself. +2. State your purpose. +3. Obtain consent to continue with the interview. + +Once we have done the introduction, I like to ask the interviewee something personal, to ease any tension. Ask them about their day, comment on a unique article of clothing or any personal question that is friendly and easy to discuss. I try to avoid cliche question or topics like the weather as they have grown to lack any depth and don't let the person talk about themselves. If you let the person talk about themselves they will be much more at ease. + +On to the questions, at this point we ask the pre-planned questions. I usually have 3-4, ideally these questions should be open ended. When getting answers don't feel like you need to stay on script and make sure to let silence hang a little longer then normal. Often the best interview veers in an unexpected direction naturally as you explore reasons and ideas that are unique to the interviewee and potentially introduce topics or ideas you had not considered. + +Once the conversation starts to dwindle I often will ask the users a straightforward question that prompts them to solve their own problem. Questions like how would you fix the situation or how have you dealt with this in another role often prompt the user to offer a solution. This may have value or not, but often is insightful in a different way. + +The time has come to conclude our interview, at this point you can thank the participant and exchange pleasantries. Before the interviewee leaves I always like to ask for permission to collaborate in the future. This helps build a pool of domain experts to tap when it come time to test prototypes, validate ideas or collect more information. + +### Avoid yes no questions + +It is always tempting to ask a question that the interviewee can answer yes or no to. I find that these are often the most bias answers and do not really offer any unique insight. If you are tempted to ask a yes/no question see if you can re-phrase the question in such a way that the answer ends up telling a story, explaining a process or exploring the reason a choice is made. + +Instead of do you test you code, consider how do you test your code? Another example could be have you used x feature, instead ask what has been your experience with x feature? These re-phrases encourage more information exchange that you can act upon. + +## Job shadowing + +Job shadowing is a tool to reach for when we are working on a very well defined process that we are looking to augment or change. I have approached this in two distinct ways with success. The first is silent observation, the second is engaging directly with the task and discussing it with the domain expert. + +Silent observation of someone doing a task can show you how they do a task day to day in a pure way. In this scenario you want to limit your exposure to the participant as much as possible. Don't ask questions, don't get in there way, maybe even consider spying on them when they don't know you are watching. The purer the experience the less bias you impose on their performance. + +When engaging in the activity, you get a different outcome. I like to approach this as if someone was training me to start a new job. Go through the actions of learning how to do the task. Ask questions, why do we do this, where does this go, how did this come to be? You are trying to clearly understand an entire workflow and get to know intimately why the decisions where made that lead to the current process. + +In either of these approaches you need to take extensive notes on workflows, conversations that occur between stakeholders, the materials being passed around or used, tools available and flow of information between contexts. + +### Look for the hacks +One thing to pay particular attention to are the hacks around the workspace. Sticky notes of keyboard shortcut, codes or steps are a good hint that a process is hard or confusing. Taking documents into and out of multiple programs can show formatting errors. I have even seen upc hacking to fix problems with upc numbers between factories. These are often low hanging fruit with a large impact. + + +## Capturing language, process and events + +Domain driven design offers a number of great ideas about using the language, entities, workflows and events of the domain in our code. In the interviewing and job shadowing methods a number of these items should have became evident. + +Often times we think we need to define the domain language, however the domain language is currently being spoken everyday. Our job is rather to extract, contextualize and define it in such a way that it is easy to reference and share. + +As we interview domain experts we have an opportune time to work on extracting their language and better understand it. When conducting an interview I recommend having the note taker write down any specific vocabulary that is discussed. Note any terms that are vague or overloaded and ask the interviewee to explain what they mean when they say x. Capture each of these terms so can later add them to our context boundaries and define them in the glossary. + +There are some patterns to look for when capturing domain languages. Try to pay attention to nouns, verbs, other stakeholders and processes. Often times nouns can relate to entities that are stored as some sort of document or can help us find context boundaries if they relate to other parts of the organization. Verbs often point to actions taking place, try to understand the context in which these actions happen and the verbs they occur upon. Stakeholders can show us new bounded contexts or help to re-inforce existing context boundaries. Finally process can show us places for further investigation. Another useful method for finding out about processes is event storming. + +### Capturing processes +There are a lot of ways to capture processes as you work through the job. Workflow process diagrams can show how different entities flow through the system and can capture language used to describe each step. We can also capture domain events that occur between each step of the workflow. + +There are a number of ways you can capture workflow processes, the first thing to figure out is what spatial dimension is important. For example, do you need to represent the process flowing between teams, over time or across physical locations? This can help us decide how to represent the workflow as it changes state. + + diff --git a/book/proposal/sample chapter2.md b/book/proposal/sample chapter2.md new file mode 100644 index 0000000..ae2f0a6 --- /dev/null +++ b/book/proposal/sample chapter2.md @@ -0,0 +1,427 @@ +# Interviewing and Job Shadowing + +What better way to learn about a topic then spend time with an expert. In our stakeholder mapping exercise we began to identify different types of users we should communicate with to better understand their working context and challenges. Now we will explore some methods for engaging these domain experts to increase our awareness of their language, workflows, entities and problems. Our goals are to reduce friction in future communications with stakeholders and code changes. We achieve this by better understand the language, processes and tools of the working environment, ultimately resulting in code that fluidly evolves with its environment by utilizing the common language of the environment, enhancing the ability of the tools already in place and seeking to co-exist in harmony with the processes important to the problem space. + +In this chapter we will introduce interviewing and job shadowing. We will use these methods to dig deep into the warranty workflow that exists today in order to understand the domain we are working within. We will be looking to gain as many key insights as we can to aid our implementation choices in the future. + +We will explore how to conduct better interviews, get stakeholder buy in, common pitfalls that could bias you implementation and how to collect common language, domain events, identify entities and processes. + +# Identifying an interviewing topic + +Our warranty process has been flagged for replacement because it is built in a legacy system that we believe is leading to tracking issues and slowing down communications. We have been implementing a new customer support portal in sales and management wants to tie the two systems together for a variety of reasons. The top down pressure is revolving around tracking costs in warranty, but warranty is expressing concerns about customer interactions and fearing a changing process. + +Our interview could go in a number of directions based on what we know. For example we could focus on: + - Tracking issue that management is prioritizing. + - The speed of communications for warranties. + - The sales/warranty overlap. + - The common warranty lifecycle. + +Often times hierarchies lead to this kind of approach. We are focusing solely on x problem. This sort of approach assumes that we are certain of the issue itself. It also assumes we are comfortable enough with the domain to not spend time exploring the warranty domain at all and instead focus on a single problem in the domain. In our scenario the original warranty system was implemented over 10 years ago, none of the knowledge accumulated during that implementation is relevant or available any more as the implementation tooling is changing and the work itself is ready to be re-examined because the new development team is in no way familiar with the tools, processes and language of the warranty dept or processes between departments. + +As is often the case we need to choose to seek the topic which is the most domain centric. We want to get at the most common workflows, entities, processes in the central workflows. The team needs to understand what is the common lifecycle of a warranty. This will ensure our solution first focuses on the primary work that needs to be completed, primary domain. We want to avoid getting into the weeds of how are cost being tracked at this point, although it is a motivating force in the org, once we have a solid core domain modeled we can move to cost tracking as a separate subdomain and explore that problem independently. It maybe a driver for why we are making the switch, but the important thing to tackle first is the core domain. + +Once we have a well defined knowledge of the environment, functioning ubiquitous language among different stakeholders and suitable basic implementation of the warranty system we can narrow down our areas of interviewing to more specific features, such as the tracking needs. Prior to defining these context boundaries and ubiquitous language you increase the risk of speaking different languages and increasing code friction by encoding these mis-understandings into you implementation. + +# Determining who to interview + +Different domain experts will work with our system in different ways and have differing needs of the system. If we refer to our bounded contexts we can gain some insight into different entities that may need to access this system, we can also do a separate stakeholder mapping exercise just for this project, it may show new bounded contexts to account for. + +We should interview a few people from each context to get some different perspectives, when possible these people should have very different backgrounds. For our warranty system we have identified the following domain experts to discuss this system with: + +- The warranty dept. +- Inventory and purchasing. +- Internal sales reps. +- Outside sale reps. +- Small bike shop mechanic. +- Large outdoor sporting goods store shop manager. +- Product management. + + +This represents the core group of domain experts that touch the warranty system on a daily basis today. Each of them have very different roles in the company and need very different things out of the system. This should give us a broad view of the domain space and how the different context view things. + +We have a pretty long list here, generally speaking it maybe hard to talk to this many stakeholders. Trying to talk to 2-3 is better then talking to none. + +Every interview cycle will have different interviewee needs. In our example we are seeking a broad audience as we are starting fresh. Once you have captured these perspectives for this broad sweeping project, future more focused projects can be limited to just the parts of the organization who's processes we are affecting. When limiting to less groups it is still a good idea to get some diversity in skillsets and application usage. I like to record interviews when possible so that I can reference them in the future should I need to. + +# Getting buy in from stakeholders + +We need to reach out to each of our domain experts and get their permission to do the interviews. The way we speak to each group will be different in tone based on who they are, our relationship with them, and their relationship to the project. + +Warranty should be aware of the project, getting permission from the core domain experts who's workflow you are affecting should be easy. When you need to deal with push back about changing processes use this as an opportunity to ease tensions and express your ambitions to improve their day to day work. You can build enthusiasm in a project by showing a willingness to work together. Doing so projects often go from dreaded to exciting as the domain experts start to feel empowered to change their day to day workflows in a positive way. + +Outside collaborators such as bike shops are often tricky, in this case try leveraging an internal relationship, in our case a sales rep has a relationship with a shop, or find a shop warranty particularly enjoys working with. Your domain experts can grease the wheels and even get outside collaborators excited about contributing back toward improving systems they dislike. + +Internal collaborators like sales may often state they don't have time to do an interview. In this scenario I have had success with drop in conversation or offering to take some one out to lunch, beers may also help. + +# Writing questions + +Now it is time to write interview questions. Interviewing people is a bit like hanging out at the bar with a friend asking them about their last great adventure. We want to go into it curious and with a beginners mindset. It is tempting to approach interview questions in a similar way to writing survey questions, by this I mean questions with yes/no, multiple choice answers, try to avoid this. + +We will be using some question starters to help create good interviewing starters. I think about interview questions as conversation starters. Our question starters are: + +- Tell me about the last time you did x. +- Have you done x differently in the past? Maybe at a different company. +- What do you tell new co-workers on their first day? +- What does a typical x process look like? + +Filling in our topic `common warranty lifecycle` we end up with the following questions: + +- Tell me about the last warranty you processed. +- Have you processed warranties differently in the past? +- What do you tell new warranty employees on their first day about the process? +- What is the process for a typical warranty? + +With these questions we are seeking real world stories. Ideally the interviewee will walk you through an experience they recall from recent work. In our warranty example, we want the warranty dept to tell us about a warranty claim starting at the place where they learn about a new claim, how they interact with the person who submitted the claim, how they decide what action to take and how they take said action. There is a lot to dig into with a story that tells the lifecycle of a whole process such as this. + +These question will spark a story and have plenty of room to breath. The goal is to remove yourself from the conversation as much as possible and let the domain expert explain their process start to finish. It is common to interject bias into questions and we want to avoid that as much as possible. + +Your number one priority is to listen, not to talk. From time to time something will come up in the interview that you think it would be nice to expand upon. Having some potential questions to help you expand a statement in a way that qualifies the statement or expands upon will improve the quality of your interviews. + +- If you had x how frequently would you have used it in the past 6 months? +- Just be be sure I am clear if you had x, what would it allow you to do that you cannot do now? +- Tell me more about why you prefer the competitors feature over ours. +- If you had to choose between x and y which would you choose? + +Each of these questions is designed to dig into the specifics of a task. The 5 why's is another good practice, if you ask why 5 times you will generally get to the end of someone's knowledge on a topic. We want to get as deep into their processes so we can understand what they are doing, why and how they talk about it. During this we are extracting as much language, process, domain entities, events, collaborators and tools as possible. + +At some point in the interview the conversation will wind down. I like to offer the domain expert the ability to solution at this point. Often they have stewed over a potential solution or better workflow but don't posses the skills required to implement it. Have some questions ready for this time: + +- How would you solve x? +- If you could change one thing today what would it be? +- If you had a magic wand what would you change? + +Often times this will not lead to a implementable solution, however it may spark an idea down the road of how you could approach the problem. It could also hand you the solution you need, don't dismiss any ideas at this point. + +I will add all these questions to a question outline so they are ready for interview day. + +## Identifying bias + +Creating interviewing questions or preparing for a job shadowing exercise can be a bit of a trap. As developers we have strong thoughts and opinions about our users and our products direction. These thoughts and opinions will impact the people we choose to talk to, the topics we lean towards, the questions we ask and how we listen. Acknowledging our biases before starting any sort of interviewing process is a good first step. + +There are a number of common biases to examine prior to entering any period of interviewing. Identifying these biases in ourselves and our team are not just useful for interviewing and job shadowing but can also help us to understand our team dynamics, inter-team communications and product decision influencers. + +The main biases I have seen include confirmation bias, survivorship bias, availability bias and social desirability. + +#### Confirmation biases +Confirmation bias is the tendency to interpret new evidence as a confirmation of one's exiting beliefs. An example of confirmation bias is someone who holds the belief that left handed people are more creative than right handed people. In confirmation bias this individual would place greater importance on this correlation confirming their bias in their mind every time they met a left handed person who was creative, they would ignore the right handed people who are creative. + +If you start to see questions that can be thought of as confirming an idea or seeking evidence of a belief you are probably in the middle of confirmation bias. Also be cognizant of the tendency humans have to ignore disconfirming information, this is how stereotypes perpetuate. + +#### Survivorship biases +During WW2 the US Military was attempting to strengthen the armor on planes. In order to do this they took stock of where the bullet holes on the planes where located and placed more armor in those locations. This is a great example of the problem with survivorship bias. + +The planes hit in the spot where the engineers where putting more armor was pointless because a plane could survive a hit in that location. They later realized they needed to put armor where they were not seeing holes because those planes where not surviving. + +We often see similar scenarios in our own interviews, we tend to interview our best customers or heaviest users. This may be helpful from a relationship perspective, but those users needs are mostly being met. Instead we should try to interview the users that abandon our product for another product. + +#### Availability Biases + +As we go through our day we are bombarded with the current events of our work; support's needs, issues you have been working on, parts of the codebase you wrote etc... Anything that is top of mind can influence how you see or think about a situation. + +This is why if your company just released a shiny new feature you are more likely to suggest it as a possible solution over something that maybe more appropriate that came out 5 years ago simply because it is top of mind. + +#### Social Desirability biases +Anyone being interviewed will be bias toward answering questions in a way that is socially acceptable. When was the last time someone asked you if you test all your code, how did you answer? If you are like most people you don't test all your code, but you said yes, or shaped some story to make it sound like you do most of the time, because you want them to think of you in desirable way. + +This is social desirability bias it is a bit like peer pressure, we have a reason to lie or color the truth because we are trying to align our practices with what we perceive as the socially desired values. + + +### How do we interview people without these biases? + +Interviewing people is hard, we have to navigate both our biases and the interviewees. Really great interviewers are hard to come by, but not everyone needs to be Terry Gross to get value out of an interview. + +You can learn to follow a mostly formulaic interview process and get good at it. I am often reminded of a statement a friend of mine told me about interviewing, you have 2 ears and 1 mouth try to use them in that proportion. It really is all about listening. + +Most people love to tell stories, if you can get a person into a story telling mode they will usually become fairly honest and straightforward as opposed to people answering questions survey style. + +So how do we conduct such an interview? + + +# Interviewing + +## Location + +I tend to prefer comfortable informal interviews, I feel people can be more authentic. You may also choose to simply meet people where they are, sometimes other people in the room can be good as it becomes a case of interviewing a group as people often chime in, other times social pressures can keep people from saying what they really think. In our case, the warranty system is ok to interview in an open context as there are not really pressing feelings involved or social pressure. + +To prepare our interviewing space I go through this checklist: + +- [ ] At least one note taker. +- [ ] Question we are going to ask. +- [ ] Post it notes and pens. +- [ ] If desired a recording device, make sure this is ok with the interviewee. + +## Conducting the interview + +There is a common pattern to an interview you can follow to make things more natural, I even put this into a template to remind myself of the steps to take. + +The first step in the process is an introduction. In this portion of the interview we need to cover the following three items: + +1. Introduce yourself. +2. State your purpose. +3. Obtain consent to continue with the interview. + +Once we have done the introduction, I like to ask the interviewee something personal, to ease any tension. Ask them about their day, comment on a unique article of clothing or any personal question that is friendly and easy to discuss. I try to avoid cliche question or topics like the weather as they have grown to lack any depth and don't let the person talk about themselves. If you let the person talk about themselves they will be much more at ease. + +On to the questions, at this point we ask the pre-planned questions. I usually have 3-4, ideally these questions should be open ended. When getting answers don't feel like you need to stay on script and make sure to let silence hang a little longer then normal. Often the best interview veers in an unexpected direction naturally as you explore reasons and ideas that are unique to the interviewee and potentially introduce topics or ideas you had not considered. + +Once the conversation starts to dwindle I often will ask the users a straightforward question that prompts them to solve their own problem. Questions like how would you fix the situation or how have you dealt with this in another role often prompt the user to offer a solution. This may have value or not, but often is insightful in a different way. + +The time has come to conclude our interview, at this point you can thank the participant and exchange pleasantries. Before the interviewee leaves I always like to ask for permission to collaborate in the future. This helps build a pool of domain experts to tap when it come time to test prototypes, validate ideas or collect more information. + +## The warranty domain expert interview + +It is time to interview our warranty domain expert, Nevin, we walk through our introductions and purpose statement, obtain consent one last time then jump into our questions. + +You: Can you tell me about the last warranty you processed? + +Nevin: This xl Vision mountain bike has a broken frame, Harrie's bike shop contacted me via email to notify me about the issue. We sent out a new frame once we identified it was a manufacturing defect. I found the frame in a warehouse close to the shop and placed a shipping order with the distribution center. + +There is a lot to unpack in that brief overview. From a note takers perspective we can identify: + +- A high level process: notification of issue -> assessment -> decision of action to take -> shipping arrangement + - Domain events in this process + - Warranty issue received. + - Warranty issue acknowledged by employee. + - Warranty issue assessed. + - Warranty issue resolution proposed + - Warranty issue resolution in progress + - Warranty resolution offered + - Warranty resolution accepted + - Replacement product shipment received at warehouse + - Replacement product shipped + - Replacement product delivered + - Warranty issue resolved. +- A number of potential bounded contexts: + - Bike shop. + - Manufacturer. + - External Warehouse. + - Shipping +- Domain entities + - Bike, + - size: xl + - category: Mountain Bike + - Product name: Vision + - Bike Shop: + - Name: Harrie's + - Shipping address? + - Warranty notification: + +These things could feed our ubiquitous language, expand our bounded contexts, add to our domain events and ultimately inform our implementation. + +### Sidbar: Fidelity in note taking +Depending on how well liked or defined your process is you may want to more fully capture the process. I tend to capture language in a higher fidelity if processes are well defined, liked or efficient. Lower fidelity is better when things are not as well defined, are inefficient or lack in some areas. As Henry Ford once said, if I asked the customer what they wanted they would say a faster horse. Allowing your team room to innovate is a matter often a matter of fidelity, at the point of capture you start to make value decisions of how much you want to replace, be aware of this during your note taking you are already making value judgments. + +In our example we know our system is gravely inefficient, so we want to capture notes that allow for room to improve. If we conducted the same interview in a well loved efficient process, or rigid environment driven by compliance our output should be higher fidelity for the process section. + +> Warranties are received via email then assigned to a warranty manager. The assigned manager then notifies the shop that they are starting work. Next follow up questions are sent to the shop. Once follow up questions are answered, the warranty manager asses the issue and offer a resolution. Given the resolution is accepted any needed parts are then shipped to the shop. Upon receiving the parts the warranty is marked as resolved. + +This higher fidelity process outline captures more information about the process. If you are following BDD this could be dropped in as a spec. User stories such as this have their place, we can see the ubiquitous language, identify context boundaries and capture this directly in our code base. However, this level of fidelity offers a solution, which at times can prevent brainstorming pathways we will explore in future chapters. Feel free to use both approaches depending on your requirements. +### End side bar + +From the interviewer perspective we can now take this interview in a lot of directions. Since we are looking to rebuild the warranty system from the ground up, the first thing we want to focus on is the warranty notification data. + +You: Can you tell me more about how you were notified of the issue and what information you needed to assess this incident? + +Nevin: Sure, Harries emailed us about the issue. We require pictures of the bike, pictures of the broken part, the serial number, and a bit of info about how the break occurred. We have an email template we send them to fill in and ask any follow up questions over email. We also ask for a single point of contact with whom to work through the issue with on the shop end to simplify communications. Based on the type of break we assign a category to the issue. + +You: This is great would you mind emailing us that template? Can you forward us a few example customer interactions? + +Once again we have information that we can use to fill out our domain knowledge even more. It is great to try to collect any assets that may already exist to assist a process, often these organically grown processes built in a low fidelity way our early prototypes of what is really desired. We can also further develop our domain knowledge assets with this small question and answer cycle. + +- Domain entities + - Bike, + - size: xl + - category: Mountain Bike + - Product name: Vision + - Serial number + - Bike Shop: + - Name: Harrie's + - Shipping address? + - Email address + - Employees + - Warranty notification: + - Image of the bike + - serial number + - Image of the break + - How the break occurred + - Point of contact for warranty submitor + - Break type category + + + This process could go on to investigate shipping workflows, warehouse interactions, manufacturer needs etc... + + You: Thanks for all this information Nevin this is amazing. Would you mind if I reach out to you in the future for follow up information or to share ideas with you and get your feedback? + + Nevin: That would be great I am really excited to fix this. + + You: I am also wondering if you would let me shadow you for an hour or so while you work on some warranties to see what you workflow looks like? + +## Note taking + +It is tempting to try to model our database or layout our objects in our notes. Ideally notes will quickly capture ideas and not model things for us. Ultimately we are trying to understand our domain, not figure out implementation details. + +Try to keep your notes short, using post it notes for note taking will encourage this as space is limited. We want to capture just enough information to understand the domain. Notes like: + +- Bike, + - size: xl + - category: Mountain Bike + - Product name: Vision + - Serial number + +Are preferred to: + +> A bike has a size, category, product name and serial number. Each warranty has a bike and the warranty belongs to a bike shop. + +This is the start of a db model, you will get there eventually but it is far to early in the process to know if what you are doing enforces the domain properly. + + +# Job Shadowing + +Nevin has invited us back to do some job shadowing. In this process we are looking to gain on the ground experience to see all the parts of the process that are often not discussed in an interview because they are so ingrained in day to day activity they seem obvious to the domain expert. + +As an outside party we need to steep ourselves in the world of the domain expert a bit, as what they take for granted maybe completely foreign to us. We may also see extremely inefficient practices that computers could automate, that the domain expert may never recognize as a problem. + +## Setup +In a job shadowing exercise we are entering into the workspace of the domain expert. We need to try to set ourselves up to be as un-obtrusive as possible. Often times this means preparing ourselves as humans to be stealth. Have you pens and paper ready, get your coffee in hand or snack and prepare to sit back and be as quite as a mouse, what ever that means for you. + +You likely also want to arrange a time when the domain expert is actively undertaking the work you want to observe. Find a time that works well for this observation, ideally they should be moderately busy, meaning not to overwhelmed to answer your questions but busy enough to show some variety. + +When you come into their workspace expect there to be a bit of friendly interaction at the beginning and perhaps a bit of awkwardness as they start their day. Starting work is hard enough, doing it while being watched can definitely impact performance. You can try to ease tension by bringing donuts, telling jokes and then slowly receding back. + +## Observation + +While observing try to ask as few questions of the observant as possible. I like to take notes of any questions I had and save them for the end. It is normal to have a follow up short interview after the shadowing session. It may also be helpful to have the domain expert explain out loud what they are doing as they undertake their work almost like a stream of consciousness. I tend to reserve this to particularly complex tasks as it can influence their workflow. + +There are a few key areas I tend to hone in on when observing a domain expert doing their work. The main 3 are tools, processes and interactions. I find these high level categories I can hone in on and organize my thinking and notes around. + +### Tools + +Any tooling the domain expert interacts with is helpful to note. Often we are integrating with, replacing or augmenting tools. Having an understanding of what tools are in place, what they are used for, why they where chosen, where they fit in the process and what features are used is often handy to note for later use. + +It can also help us to understand were our tooling fits in the broader picture, are these outside system interacting with ours, could they? Should they? Are their patterns or language familiar to the domain expert from these tools that we can co-opt to simplify the environment of the domain expert? Tools in the environment are important to any domain expert, thus they should be important to us as augmenters of the environment. + +### Processes + +How are entities moving through the environments, what tools are taking inputs, creating outputs. What do these inputs and outputs look like? Is most of the process happening on a computer? Is there physical workspace to consider? + +Most of the workflow we are examining is process, whether or not it is recognized as such or any good. Looking for patterns in the workflow and things that could potentially become patterns is a good thing to note. + +This is a great time to outline domain entities, domain events and states that entities could exist in. You may want to actually draw timelines, comics, physical maps or process diagrams to show how things move through the process. + +### Interactions + +Interactions between different domain experts, processes or tools are all helpful to capture. Is there a point in time where a certain entity transfer to another group in you organization? Does the domain expert need to reach out to other places for information? Does information transfer from one system to another? How are the domain experts entering data into different places? + +All these interactions likely point to some piece of tooling you will need to be aware of or consider implementing. Try to map out how entities are moving around in the context bounds and what action is required to move them in an out of these interactions. + +### Looking for hacks + +This is not one of my top 3 areas for focus, but hacks are really valuable for finding confusing or troublesome parts of a system. If a domain expert has take the time to implement a hack to get around a situation it is likely that they understand something the implementors did not and got frustrated to a point that they fixed it themselves. + +Hacks can take many forms, post it notes with directions, macros in excel, browser plugins, copy and past patterns and more. Any thing where the user created a one off custom solution to a problem is worth exploring. + +## Observing our warranty process + +You: Good morning Nevin, I brought coffee and bagels. How is your day going? + +Nevin: Great now that I have bagels. + +You: Everyone loves a bagel, I am going to hang out back here and just observe your warranty routines. Mind if I look around at your space while you get your day started? + +Nevin: No problem, if you have any questions just let me know. + +You: Thanks + +You walk around and note a few computers, a barcode scanner with internet browsing capabilities, label printers and some notes with email addresses for different warehouses holding our products. + +Nevin: Hey Jim, I got a new warranty issue want to grab it? + +Jim: On it. + +You go over and watch Jim follow up on the warranty issue. He double checks that all the needed information is there in the issue, which it is. You take notes of all the items he is looking for in the email, it looks like there is an email template that they use to have shops submit warranties with, you take a note to get this template from them later. + +Jim: This looks pretty straight forward, we have seen a lot of these bikes break at this junction. Nevin do we still have any x-large, huff and puff frames left in the west coast wharehouse? + +Nevin: No it will have to come from the east coast. Should take about a week to get to them. + +Jim: Ok I will let the shop know and ship it out once they have given the go ahead. + +You capture notes about the location of the bike inventory driving delivery needs and dates. Also the process of notifying the shop. You also request that all the emails exchanged be forwarded to you for reference. + +From this exercise we have gained knowledge around a number of areas that didn't expose themselves during the interview. The warehouse inventory came up as did the tools that they use day to day. You could follow up and ask to see how any of these tools are used to try to drive insights into where you could further inject software into their process. + +## Developing your ubiquitous language +At this point we should think of things as developing an encyclopedia of institutional knowledge. In fact I would recommend taking on this task at this point. Every interview you undertake should be approached as an opportunity to collect and share very useful domain knowledge that may currently exist in a silo. + +Every group is different in how they like to communicate. Self describing software, document everything, automatically generated docs there are a lot of preferences in how we communicate amongst our teams. The method of communication is less important then the ability to capture the knowledge you have gained, so I am not going to weigh in on this religious war. If you can build a wiki or some other communication tool that can state what all the domain language is in different parts of your bounded context then you have a communication standard you can reference for new hires, naming things in the future and understanding what user means in the context of sales. + +Taking our notes from our interview section we can extract our domain entities, domain events, process and new bounded contexts. We are not at a point were we are writing code yet but we can start to organize our domain further on a domain context map, grouping our entities, events and processes in their proper contexts. + +![](https://www.oreilly.com/library/view/domain-driven-design-distilled/9780134434964/graphics/04fig01.jpg) + +Lets augment our previous context map from our stakeholder mapping exercise. Since we have spoken with warranty we identified some outside stakeholder we had not considered prior. The warehouse which houses our replacement parts is a group we will need to work with, the implementation for this group is an unknown at this time, could be an api could be an email workflow, which is what exists today. This is not part of our core domain and thus belongs in its own context. Similarly is the shipping agent, this will live outside our core domain as well. It is likely some other part of the organization, sales, also needs an shipping integration so it will serve us well to look at this as it's own sub-domain. + +We can also fill in some information about the bike entities in our core domain and warranty processes inside our warranty sub-domain, warranty could potentially be the core domain from the teams perspective but is not from the business' perspective. Inside the core domain we can add the new bike and bike shop information we have collected: + +- Core Domain entities + - Bike, + - size: xl + - category: Mountain Bike + - Product name: Vision + - Serial number + - Bike Shop: + - Name: Harrie's + - Shipping address? + - Email address + - Employees + +We can begin to fill in some process information in the warranty subdomain: + +- A high level process: notification of issue -> assessment -> decision of action to take -> shipping arrangement + - Domain events in this process + - Warranty issue received. + - Warranty issue acknowledged by employee. + - Warranty issue assessed. + - Warranty issue resolution proposed + - Warranty issue resolution in progress + - Warranty resolution offered + - Warranty resolution accepted + - Replacement product shipment received at warehouse + - Replacement product shipped + - Replacement product delivered + - Warranty issue resolved. + + We also have a warranty subdomain entities: + + - Warranty Notifications + - Warranty Issue + - Image of the bike + - serial number + - Image of the break + - How the break occurred + - Point of contact for warranty submitter + - Break type category + - Warranty Assigned Manager + - Warranty Assigned shop + - Warranty Discussion + +Along with this we have identified two more potential subdomains, shipping and warehousing/inventory. These could be built out in a similar fashion to what we have done with warranty. + +This represents the core language, process and ideas in the warranty department as it exists today. I will also often add a list of tools available at this point so I have it for future brainstorming sessions. This may not be a part of what Domain Driven Design offers, but I prefer to look holistically at an environment as the problem space in order to better serve the problem. + +- Handheld UPC Scanners, running android +- Cellphones +- Laptops with internet connection +- External Warehouse + +There are clearly interconnections between our sub-domains we will explore mapping those out further in a future section. + +# Conclusion + +We have now collected a strong representation of the domain from the warranty managers perspective. Collecting ideas about how they communicate, work and their environment. This information allows us to think about the warranty environment in a much more informed way then we did prior to the exercise and gives us communication tools that can ease communication friction with stakeholders and also in the code itself. + +We also have a much better long term view of how the code itself may grow and change since we understand the working condition of the warranty lifecycle. This will help us make informed decisions as we build our solution that will keep us from setting up traps based on lack of foresight. + +Finally we improved our relationships with key internal stakeholders. This social capital can help us champion our project and improves collaboration which can only improve our project. We have developed a toolset which helps us collaborate in an effective way instead of just complaining about things that are broken. + +In the next chapter we will take these things we learned in this chapter and use some design thinkings methods to reflect on the knowledge we have gained. diff --git a/workshop presentation/design thinking for developers.key b/workshop presentation/design thinking for developers.key index 90c8248..bcd8f6e 100755 Binary files a/workshop presentation/design thinking for developers.key and b/workshop presentation/design thinking for developers.key differ