|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|
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.
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.
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.
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
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.
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.
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.
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.