09:00 – 09:40 Registration & Welcome Coffee
09:40 – 10:00 Opening words
10:00 – 11:00 Mattias Skarin: Using continuous improvement on an existing product
11:00 – 11:45 Thomas Sundberg: Behavior Driven Development
11:45 – 12:00 Coffee break
12:00 – 12:30 Andrei Savu: Continuous Deployment Pipeline
12:30 – 13:00 Cornel Fatulescu: Growing IT Products over Building Them
13:00 – 14:00 Lunch Break
14:00 – 16:00 Open Space
16:00 – 16:30 Carmen Munteanu: Give your retrospective a chance
16:30 – 17:15 Thomas Mödl: A Rational Romance: Scrum and Evolutionary Business Analysis
17:15 – 17:30 Coffee Break
17:30 – 18:15 Alex Bolboaca: Feedback — The Lost Art of Agile
18:15 – 18:35 Lightning Talks
18:35 – 18:45 Closing Words
18:45 – 19:45 Happy Hour Networking Mini Party


Mattias Skarin
Using continuous improvement on an existing product

Continuous improvement in a manufactoring environment is far simpler than in the complex product development scenario. Set a standard, improve from it. Product development works in a space with more uncertainty making cause and effect much more dim.

But don’t give up! Let me tell the story of how we used visualisation, reflection, interfaces and management involvement to tie together improvement initiatives across functions to improve cycle time and market share on an existing product.


Thomas Sundberg
Behavior Driven Development

Elisabeth Hendricksson has stated that “Specs is an abbreviation for speculations”. She is right, specs are often speculations. How can this be avoided?
Execution of code doesn’t leave any room for speculations. If the specs can be executed, they aren’t speculations anymore.

Specifications can be expressed in many different ways. One popular form is as Word documents. Word documents are hard to execute, they need to be interpreted and the writers intent may be lost in the translation.

It would be nice to remove the risk of misinterpretation and the risk of losing the authors intent during the translation. This can only be done if no interpretation takes place and no translation is done. The solution is obviously to create specifications that can be executed.

If we want to execute a specification, do we not have to write a program to do so? If the customers could write the program, then they wouldn’t need us do it for them and the initial problem would not even exist. The answer is no, they don’t have to write a program. They only need to express themselves so the expression can be used in an execution later.

I will show you a way to express what you want, in a formal way, so that it can be used as the basis for an execution. The customer only need to be able to express what they want in a few sentences in their natural language of choice. This description will be translated into something that is actually executable.

Given a system setup in a particular way
When something is executed
Then the result is expected to be a new state of the system

This formal way of expressing yourself can be translated and used as the basis for an execution of the system under test.

This presentation will give you more details about the why, an example of how (executed live of course) and finally some potential drawbacks.

You may not know all details about BDD and Executable Specifications after this session, but you will know that it can be done and how it can be done.


Andrei Savu
Continuous Deployment Pipeline

Continuous deployment is a process that allows companies to release software in minutes instead of days or weeks. All new code that is written for an application is immediately deployed in production by using an automated pipeline. This technique can dramatically increase the amount of feedback you collect and give you the ability to adapt to unexpected events.

This process requires a great deal of discipline and can enhance software quality, by applying a rigorous set of standards to every change to prevent regressions, outages, or harm to key business metrics. During my presentation I will go through the main elements that make this possible, I will review some existing tools that you can use and tell you a few stories about small and large companies that implement continuous deployment.


Cornel Fatulescu
Growing IT Products over Building Them

During this presentation, Cornel will explain how “gardening over architecting” principle affects the way we increment work in agile development.


All conference participants
Open Space

During the Open Space sessions, all participants will be able to propose topics they would like to discuss. Also, they will be able to attend one or more sessions they find useful.

The sessions are informal parallel ‘gatherings’ governed by the Law of Two Feet: If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else.


Carmen Munteanu
Give your retrospective a chance

The Retrospective is a powerful tool to help teams getting better with time. Even if everybody agrees on this, the reality seams to be slightly different. In my talk I’ll share with you my experience on facilitating retrospectives over the last 18 months: what worked, what didn’t and especially what I missed.


Thomas Mödl
A Rational Romance: Scrum and Evolutionary Business Analysis

Agile practices and business analysis are often perceived to be at odds with each other. This talk aims to clarify why this discord need not exist and proposes that business analysts and agile champions work toward deriving benefit from using both, and exploit synergies that have the potential to dramatically improve the software engineering process.

Particularly in large projects, where software systems are produced incrementally by several teams, one can observe risks regarding the quality of the results and the successful adaption of Scrum in equal measure. Evolutionary business analysis with user stories can provide a decisive contribution here, by adequately supporting agile project management in initializing the Scrum product backlogs and by generating the backlog entries.


Alex Bolboaca
Feedback — The Lost Art of Agile

Agile and Lean practitioners all agree: getting feedback early and often is the key to agility. But by feedback we often understand user feedback on a delivered version of the application.

In this talk I will argue that there are more levels of feedback and that any agile team should pay close attention to all of them. I will also discuss tools and techniques that you can use to minimize the various feedback cycles and to increase their quality.

At the end of the talk, you will understand how various agile practices work together to improve feedback cycles, with the purpose of increasing quality and productivity. You will also leave with a few ideas for how to improve your team by adopting one or more new techniques.