Niclas Nilsson is our moderator for the Seminar Day! 

A few software people have been Agile long before Agile was cool, and one can find most of the roots of Agile development in Ward Cunningham's company in the late 1980s, in Borland in the early 1990s, and in many other small organizations of the same era. Agile started appearing as a discipline in the early 1990s, reflecting a grass-roots cultural change that swept the industry. That change was crystallized in the Dr. Dobb's article on Borland's QPW development, in the emerging day-to-day practices of programmers using object techniques, and ultimately in organizational patterns and in more formalized methods such as Crystal Clear, SCRUM, and later XP. In this keynote I'll describe one man's journey through this history, the aspirations I noted in the hearts and minds of those who shaped Agile development along the way, and my reflections on the degree that Agile development today lives up to those cool aspirations. 

Agile methods are now becoming mainstream, with even the big consultancies advertising "agile" in some form or another. Behaviour-driven development (BDD) is an evolution of established agile practices such as test-driven development, domain-driven design, acceptance test-driven planning and regular face-to-face communication.

This session introduces the principles behind BDD by one of its leading practitioners, and describes how it leads to high quality, business-focused software delivery.

There is a lot of talk about aspect orientation, and how to use aspects and what they are good for. But few have actually used aspects on a large scale and in a system that has existed for some time. This talk will present why we chose to use AOP as the foundation of our product, and how that has influenced our possibilities to develop new functionality. I will also discuss the effects that this has on a development team, and what you need to think about.

Right now you might be feeling that everybody is so agile it hurts, that they have been using the agile practices for decades and that agile is the solution to every problem. Don't get me wrong, I do like the agile practices. I have tried to apply them to the best of my understanding for a couple of years and I think I start to have a feeling for how to. Yet, while we may be getting better and better at applying the agile practices, let's just assume for a moment that the agile practices are a commodity and we can take them as granted. Then what? There are technologies, practices, and concepts that are not typically considered as being the agile practices and are not yet widespread. But even if they aren't part of the dogma, they are highly useful. It might be both interesting and important to have a look at these and get started with them if you haven't already done so. In this session we will start with a quick look at problems that the agile practices don't focus on, and then discuss possible solutions. 

In the twentyfirst century, almost all programming is program transformation, the transformation of version N of a program to version N+1, usually for N much larger than 1. When we realize this, it will change the way we manage projects, it will change our programming environments, and it will change our programming practices.