Wednesday March 11

Reception area — Registration
Dragefjellet — Welcome from the organizers
Dragefjellet
Teatergaten
Sydneshaugen
Downstairs — Coffee break
Dragefjellet
Teatergaten
Sydneshaugen
Restaurant — Lunch
Galgebakken
Sydneshaugen
Strangehagen
Teatergaten
Muséplass
Dragefjellet
Tårnplass
Downstairs — Coffee break
Galgebakken
Sydneshaugen
Strangehagen
Teatergaten
Muséplass
Dragefjellet
Tårnplass
Galleri Nygaten (map) — Conference dinner

Thursday March 12

Reception area — Registration
Galgebakken
Strangehagen
Continuous Deployment: The Ultimate Culmination of Software Craftsmanship
Viktor Farcic

Continuous Deployment is the natural evolution of continuous integration and delivery. It is the ultimate culmination of software craftsmanship. Our skills need to be on such a high level that we have a confidence to continuously and automatically deploy our software to production.

We usually start with continuous integration with software being built and tests executed on every commit. As we get better with the process we proceed towards continuous delivery with process and, especially tests, so well done that we have the confidence that any version of the software that passed all validations can be deployed to production. We can release the software any time we want with a click of a button. Continuous deployment is accomplished when we get rid of that button and deploy every "green" build to production.

We'll try to explore the goals of the final stage of continuous deployment, the deployment itself. We'll assume that static analysis is being performed, unit, functional and stress tests are being run, test code coverage is high enough and that we have the confidence that our software is performing as expected after every commit.

The goals of deployment process that we should aim for are:

* Run often
* Be automatic
* Be fast
* Provide zero-downtime
* Provide ability to rollback

**Deploy Often**

We'll try to explore why it is important to deploy often. What are the pros and cons deploying on every commit instead once a month or few times a year? What are the prerequisites for successful deployment?

**Automate everything**

Why automation? What are the pros and cons of provisioning tools like Chef and Puppet? What are containers (e.g. Docker) and how do they help? Do we need provisioning tools if we adopt containers?

**Be fast**

Speed is the key. Can we deploy often if the process is not fast? What is the relation between fast deployments and time-to-market? What is the acceptable deployment duration?

**Zero-downtime**

We cannot deploy often without zero-downtime. If there is any downtime during deployment, it will be multiplied with the number of deploys we do. We'll go through one blue-green deployment as one possible way to accomplish zero-downtime.

**Ability to rollback**

Unexpected happens sooner or later and the ability to rollback is a must. How can we accomplish automated, fast and reliable rollback? What are the major obstacles?

Deployment Strategies
=====================

We'll explore different strategies to deploy software. This session will in no way provide an exhaustive list of ways to deploy applications but will try to discuss few common ways that are in use today.

**Mutable monster server**

We are used to build and deploy big mutable applications. That's how we did it during most of the short history of software industry. What are pros and cons of "mutable monster server"? Can we deploy it often with zero-downtime and easily rollback? Is automation of such a server the way to go? Can it be fast? Are there any alternatives?

**Immutable servers**

What are immutable servers? How can we deploy them? What is blue-green deployment in the context of immutable servers? What are the benefits?

**Immutable microservices**

What are microservices? Why do they fit perfectly into the concept of immutable servers?

Live Example
============

Once we are all familiar with Continuous Deployment and different strategies that can be employed, we'll got through one example of deploying fast, often, automatically, with zero-downtime and the ability to rollback. We'll use Ansible, Docker, nginx, Jenkins, Vagrant and few other tools to release and deploy an application. We'll test that application both before and after the deployment and we'll explore different ways to design architecture of those applications so that the result is best suited for Continuous Deployment. All examples will be run live.

Summary
=======

Continuous deployment sounds to many as too risky or even impossible. Whether it's risky depends on the architecture of software we're building. As a general rule, splitting application into smaller independent elements helps a lot. Microservices is the way to go if possible. Risks aside, in many cases there is no business reason or willingness to adopt continuous delivery. Still, software can be continuously deployed to test servers thus becoming continuous delivery. No matter whether we are doing continuous deployment, delivery, integration or none of those, having automatic and fast deployment with zero downtime and the ability to rollback provides great benefits. If for no other reason, because it frees us to do more productive and beneficial tasks. We should design and code our software and let machines do the rest for us.

Room: Strangehagen
Teatergaten
“Debugging” Your Agile Team: An Experiential Clinic
Johanna Rothman

Does your team respect everyone on it? Are there times when it seems as if each person pulls in a different direction? You—and each person on the team—can assess how your team is doing, and learn to work together with collaborative practices. Once you see how to work together, you will be amazed at how fast you can accomplish work. Agile team members need to respect each other. And, sometimes people work in a way that doesn’t enhance the respect each person needs. You can create feedback loops, small-world networks, and micro-commitments that enhance respect and teamwork. In addition, you can decide on the collaborative practices that will help you make a better team.

This is a clinic for you to learn how to create a better environment for your team. We'll experience a project and then "debug" your practices and teamwork and see what might work better (or worse!). We will fail fast to learn fast. We will learn from each other and coach each other. We will see if our tips and traps work across teams or only within teams. Join this clinic to see what works for you and your team. (If you come to this workshop without a team, we will create a team from the solo people. You will learn what happens when you first create a team.)

What you will learn:

  • How to create more of an environment of teamwork
  • How to recognize when things are working and when they are not
  • How to do quick retrospectives
  • Many tactical ideas for making your practices more agile and lean
Room: Teatergaten
Muséplass
Dragefjellet
Tårnplass
Easier UI Reasoning with Unidirectional Dataflow and Immutable Data
Torgeir Thoresen and Mikael Brevik

Let us bring back the days where we could write declarative representations of how we want our UI components to work. We should be able to read our code from top to bottom and intuitively know what the output will be, just like the good old HTML. We should be able to write composable, testable and reproducible components and be free to choose what kind of dependency management we want to use, or how to structure our code.

What if we take inspiration from the functional world and create a UI where we have pure and referentially transparent components; components with no side-effects and predictable output? If we coupled this with immutable data and components with single responsibilities, can we get a blazing fast and smart way to build UIs? It turns out we can!

In this workshop we start by looking at how we can use a virtual DOM and functional cursors of immutable data to isolate components, and making them pure. Once we've grasped the general concepts, we introduce an architecture for doing unidirectional top-down rendering, with very little architectural overhead. After this workshop, you should be able to understand and use unidirectional UI components to build testable and easy-to-reason-about web applications. Technologies used will be Facebook's React and Immutable.js, and Omniscient.js. This workshop is intended for developers who have some experience with frontend development.

Room: Tårnplass
Hødden
Downstairs — Coffee break
Galgebakken
Strangehagen
Continuous Deployment: The Ultimate Culmination of Software Craftsmanship (cont.)
Viktor Farcic

Continuous Deployment is the natural evolution of continuous integration and delivery. It is the ultimate culmination of software craftsmanship. Our skills need to be on such a high level that we have a confidence to continuously and automatically deploy our software to production.

We usually start with continuous integration with software being built and tests executed on every commit. As we get better with the process we proceed towards continuous delivery with process and, especially tests, so well done that we have the confidence that any version of the software that passed all validations can be deployed to production. We can release the software any time we want with a click of a button. Continuous deployment is accomplished when we get rid of that button and deploy every "green" build to production.

We'll try to explore the goals of the final stage of continuous deployment, the deployment itself. We'll assume that static analysis is being performed, unit, functional and stress tests are being run, test code coverage is high enough and that we have the confidence that our software is performing as expected after every commit.

The goals of deployment process that we should aim for are:

* Run often
* Be automatic
* Be fast
* Provide zero-downtime
* Provide ability to rollback

**Deploy Often**

We'll try to explore why it is important to deploy often. What are the pros and cons deploying on every commit instead once a month or few times a year? What are the prerequisites for successful deployment?

**Automate everything**

Why automation? What are the pros and cons of provisioning tools like Chef and Puppet? What are containers (e.g. Docker) and how do they help? Do we need provisioning tools if we adopt containers?

**Be fast**

Speed is the key. Can we deploy often if the process is not fast? What is the relation between fast deployments and time-to-market? What is the acceptable deployment duration?

**Zero-downtime**

We cannot deploy often without zero-downtime. If there is any downtime during deployment, it will be multiplied with the number of deploys we do. We'll go through one blue-green deployment as one possible way to accomplish zero-downtime.

**Ability to rollback**

Unexpected happens sooner or later and the ability to rollback is a must. How can we accomplish automated, fast and reliable rollback? What are the major obstacles?

Deployment Strategies
=====================

We'll explore different strategies to deploy software. This session will in no way provide an exhaustive list of ways to deploy applications but will try to discuss few common ways that are in use today.

**Mutable monster server**

We are used to build and deploy big mutable applications. That's how we did it during most of the short history of software industry. What are pros and cons of "mutable monster server"? Can we deploy it often with zero-downtime and easily rollback? Is automation of such a server the way to go? Can it be fast? Are there any alternatives?

**Immutable servers**

What are immutable servers? How can we deploy them? What is blue-green deployment in the context of immutable servers? What are the benefits?

**Immutable microservices**

What are microservices? Why do they fit perfectly into the concept of immutable servers?

Live Example
============

Once we are all familiar with Continuous Deployment and different strategies that can be employed, we'll got through one example of deploying fast, often, automatically, with zero-downtime and the ability to rollback. We'll use Ansible, Docker, nginx, Jenkins, Vagrant and few other tools to release and deploy an application. We'll test that application both before and after the deployment and we'll explore different ways to design architecture of those applications so that the result is best suited for Continuous Deployment. All examples will be run live.

Summary
=======

Continuous deployment sounds to many as too risky or even impossible. Whether it's risky depends on the architecture of software we're building. As a general rule, splitting application into smaller independent elements helps a lot. Microservices is the way to go if possible. Risks aside, in many cases there is no business reason or willingness to adopt continuous delivery. Still, software can be continuously deployed to test servers thus becoming continuous delivery. No matter whether we are doing continuous deployment, delivery, integration or none of those, having automatic and fast deployment with zero downtime and the ability to rollback provides great benefits. If for no other reason, because it frees us to do more productive and beneficial tasks. We should design and code our software and let machines do the rest for us.

Room: Strangehagen
Teatergaten
“Debugging” Your Agile Team: An Experiential Clinic (cont.)
Johanna Rothman

Does your team respect everyone on it? Are there times when it seems as if each person pulls in a different direction? You—and each person on the team—can assess how your team is doing, and learn to work together with collaborative practices. Once you see how to work together, you will be amazed at how fast you can accomplish work. Agile team members need to respect each other. And, sometimes people work in a way that doesn’t enhance the respect each person needs. You can create feedback loops, small-world networks, and micro-commitments that enhance respect and teamwork. In addition, you can decide on the collaborative practices that will help you make a better team.

This is a clinic for you to learn how to create a better environment for your team. We'll experience a project and then "debug" your practices and teamwork and see what might work better (or worse!). We will fail fast to learn fast. We will learn from each other and coach each other. We will see if our tips and traps work across teams or only within teams. Join this clinic to see what works for you and your team. (If you come to this workshop without a team, we will create a team from the solo people. You will learn what happens when you first create a team.)

What you will learn:

  • How to create more of an environment of teamwork
  • How to recognize when things are working and when they are not
  • How to do quick retrospectives
  • Many tactical ideas for making your practices more agile and lean
Room: Teatergaten
Muséplass
Dragefjellet
Tårnplass
Easier UI Reasoning with Unidirectional Dataflow and Immutable Data (cont.)
Torgeir Thoresen and Mikael Brevik

Let us bring back the days where we could write declarative representations of how we want our UI components to work. We should be able to read our code from top to bottom and intuitively know what the output will be, just like the good old HTML. We should be able to write composable, testable and reproducible components and be free to choose what kind of dependency management we want to use, or how to structure our code.

What if we take inspiration from the functional world and create a UI where we have pure and referentially transparent components; components with no side-effects and predictable output? If we coupled this with immutable data and components with single responsibilities, can we get a blazing fast and smart way to build UIs? It turns out we can!

In this workshop we start by looking at how we can use a virtual DOM and functional cursors of immutable data to isolate components, and making them pure. Once we've grasped the general concepts, we introduce an architecture for doing unidirectional top-down rendering, with very little architectural overhead. After this workshop, you should be able to understand and use unidirectional UI components to build testable and easy-to-reason-about web applications. Technologies used will be Facebook's React and Immutable.js, and Omniscient.js. This workshop is intended for developers who have some experience with frontend development.

Room: Tårnplass
Hødden
Restaurant — Lunch
Dragefjellet — Introduction to open spaces
Dragefjellet and more — Open spaces 1
Dragefjellet and more — Open spaces 2
Lysverket — Fishbowl / Community Night

Friday March 13

Reception area — Registration
Galgebakken
Strangehagen
Teatergaten
Temenos - Discover What You Want
Olaf Lewitz

“Once we dare to say what we want and give ourselves the freedom to choose, our chances to get it increase immensely.” – Olaf Lewitz

Temenos – trust-building and connection for the people section of your Agile toolbox

Temenos gives us a chance to:

  • understand better where each of us is coming from
  • grant ourselves time to discover what we really want
  • make choices that are relevant in the moment
  • be more inspired and capable
  • clearly see patterns and options we could not see before.

This workshop is for all people who depend on trustful relationships in their team or with their clients. For managers, team members, coaches, scrum masters, product owners and everyone who wants to gain clarity on what they want.

Temenos is a space to experience and learn more effective ways to build stronger relationships in our lives. It invites us to be more open, to learn more quickly and to listen to others with more attention. Temenos helps to strengthen the relationship to ourselves, as well as our empathy and appreciation for others.

The Temenos process is about each person telling their own stories in an environment where trust develops, where we learn to accept different point of views, contradictions and conflicts. It helps us to become aware of where we have a choice. Some typical subjects include: self-management, conflicts in the team, my professional role, my goals, my talents, and dealing more effectively with change. Temenos helps us find out about the essential key to a situation. We focus with the help of the feedback of the group and their stories. We get new ideas how to change a situation in a way that we can be more authentic and happy.

Room: Teatergaten
Muséplass
Dragefjellet
Tårnplass
Hødden
Downstairs — Coffee break
Galgebakken
Strangehagen
Teatergaten
Temenos - Discover What You Want (cont.)
Olaf Lewitz

“Once we dare to say what we want and give ourselves the freedom to choose, our chances to get it increase immensely.” – Olaf Lewitz

Temenos – trust-building and connection for the people section of your Agile toolbox

Temenos gives us a chance to:

  • understand better where each of us is coming from
  • grant ourselves time to discover what we really want
  • make choices that are relevant in the moment
  • be more inspired and capable
  • clearly see patterns and options we could not see before.

This workshop is for all people who depend on trustful relationships in their team or with their clients. For managers, team members, coaches, scrum masters, product owners and everyone who wants to gain clarity on what they want.

Temenos is a space to experience and learn more effective ways to build stronger relationships in our lives. It invites us to be more open, to learn more quickly and to listen to others with more attention. Temenos helps to strengthen the relationship to ourselves, as well as our empathy and appreciation for others.

The Temenos process is about each person telling their own stories in an environment where trust develops, where we learn to accept different point of views, contradictions and conflicts. It helps us to become aware of where we have a choice. Some typical subjects include: self-management, conflicts in the team, my professional role, my goals, my talents, and dealing more effectively with change. Temenos helps us find out about the essential key to a situation. We focus with the help of the feedback of the group and their stories. We get new ideas how to change a situation in a way that we can be more authentic and happy.

Room: Teatergaten
Muséplass
Dragefjellet
Tårnplass
Hødden
Restaurant — Lunch
Galgebakken
Strangehagen
Teatergaten
Muséplass
Dragefjellet
Tårnplass
Hødden
Downstairs — Coffee break
Dragefjellet — See you next year