Writing the automation is the easy part, growing adoption is hard!
Let's think through the "Why Automating" and discover models, tools and practices that can help focusing on the right thing, targeting the right problem, for the right person, working in an optimized way for your context!

As technologist it may be easy for us to understand the benefit of a technical solution. It is often harder to know how the solution we're developing will be received, and how to optimize the impact, manage its delivery process, and communicate around it.

In this session, we will discover what **models** can help you understanding what matters to your organisation, and how you can identify what to focus on for maximizing **the value** you create.
We will start by identifying how your organisation creates value, and see where your team comes to play in the **Value Chain**. With this information we'll highlight your **direct customers** and how to think about the **product(s) or service(s)** you are building.
We will then see how building **personas** for your users can help the communication to be more precise, and help **managing priorities and focus**.
With this context in mind, we can now decompose the **user journey** and isolate the features to deliver in priority.
As soon as you start developing, you want to get **feedback as early as possible** to avoid going in the wrong direction: let's create the **feedback loop** between your customers and your team.
If your work is about streamlining systems with automation, we can use the **Value Stream map** to identify **the constraint** or where the best improvements to the **cycle time** can be achieved, or where you can make conscious **tactical choice** without undermining your **strategy**.

Now that you know what to work on, we can discuss how to manage that work. Let's start by defining [**4 types of work**](https://www.e4developer.com/2018/03/24/the-phoenix-project-a-key-to-understanding-devops/), and how to [**Making Work Visible**](https://itrevolution.com/making-work-visible-by-dominica-degrandis/) to better communicate and identify problems.
Let's see one way of organising our work in fixed-length **iterations**, to **balance focus and agility**.
We're making sure we deliver what we plan, use a **WIP limit** to leave room for **unplanned work**, while accounting for it to identify issues such as a lack of quality.

Any changes you're bringing will meet resistance, so let's learn from the model of **diffusion of innovation** to optimize our approach. Let's also be wary of the [**Automation Fear Spiral**](https://www.thoughtworks.com/insights/blog/infrastructure-code-automation-fear-spiral) to avoid the risks of returning to old ways over time.
Finally, don't rush: **slow is smooth, smooth is fast**. We need to get the [**delivery system**](https://itrevolution.com/the-three-ways-principles-underpinning-devops/) in place first, before we ramp up its speed and capacity.

This is not a "technical" session. It focuses on the tools and practices that help automation experts and managers to better align the work to the business needs, and organising their teams.