# Design sessions

When I was fully in Dev Teams it is a practice we used to define the implementations of our features. It consists in brainstorming and aligning at the beginning of each feature implementation.

### How to ?

![](/files/-MKddILFfduwRcdXHt2Y)

Once a team member wants to open a new Product Backlog Item, User Story or feature implementation, we do an instant meeting in front of a whiteboard and a computer.

![](/files/-MKde1yWx98qImgQS36F)

* We start by agreeing on its definition
* Be sure we are all aligned on what needs to be done

![](/files/-MKdeJsEAYXH3ms3hq4-)

We use the whiteboard to align ourselves on the different flows to implement

![](/files/-MKdecZMOV4Ghq97bwmR)

* We open the source code or create a new one and start designing the contracts :
  * From our external layers (APIs for example) to our Domain model
  * POCOs / POJOs
  * DTOs / Commands
* We don't implement anything except of the contracts
  * We throw exceptions `throw new NotImplementedException()`
* BUT we agree on the naming / parameters
  * We put TODOs in the code to be clear what is expected to implement
  * Later on I have learned that this TODO approach to implementation had a name : [Puzzle Driven Development](https://www.yegor256.com/2010/03/04/pdd.html)

![](/files/-MKdeoCO34bmGwnKFhDm)

The whole team or part of it can now work on the implementation by knowing exactly what to do.

### Pros

* Instant alignment feedback on what needs to be done
* Increased knowledge sharing
  * Quick up-skilling for new-joiners
* Better solution when designed collaboratively
  * "Alone we go faster together we go further"
* Save a lot of times
  * Avoid feedback loops (in code reviews for example) when no team alignment
* Reinforce the collective ownership feeling inside the team
* Help to shape a real team spirit as well
  * Everyone is involved at the beginning of everything

### Infography

![](/files/-MKdaqQcCCDQQ4fZ2xC8)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yoan-thirion.gitbook.io/knowledge-base/software-craftsmanship/practices/design-sessions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.