A brief presentation of the basic Transaction Analysis concepts of ego-states and games, traditional areas of application, and a warning of oversimplifying a complex theory from a 10 minutes speech.

A few attempts of simple Transaction Analysis to typical interactions between agile team members. How can Transaction Analysis help team members create more powerful teams from insights in their own personal behavior and communication style.

In this lightning talk we argue against what we see as ‘TDD fundamentalism’. We posit that practices such as “do the simplest thing that can possibly work” and “deal with one requirement at the time” are wasteful, risky and do not encourage innovative, competitive solutions. Instead we argue that adding a small up-front design phase will allow us to arrive faster at a better solution. We advocate introducing stakeholder values and product qualities as explicit parts of the design and introduce some design heuristics that we find are sensible alternatives to more fundamentalist approaches.

The talk presents challenges in orchestrating a development team with complementary skills and competencies - all of which very relevant and required for the project at hand. However, according to the team assessment instrument presented in [1], a multidisciplinary team with the seemingly perfect and required diversity in competences, is not guaranteed a high score. 1) Moe, Dingsøyr, Røyrvik, “Putting Agile Teamwork to the Test – A Preliminary Instrument for Empirically Assessing and Improving Agile Software Development”, in Abrahamsson, Marchesi & Maurer (Eds.): “XP 2009”, LNBIP 31, 2009

Companies have success with agile development because of their culture. Consciously (or unconsciously), senior developers build culture continuously when teaching their co-workers about technology, process and business goals.

What are they like, the senior developers that manage to guide their co-workers in the every day routine towards agility?

When growing a great organization you must focus on things you are already good at, rather than only trying to fix stuff that apparently is not working. Everything has a postive component as well as a negative component, if you are all about fixing the negative components without realizing how it might effect the positive components you will end up with a mediocre organization. This is a talk about the famous Godfot theory as applied to great IT organizations.

Will expand on the topic of my article from 97things every programmer should know: http://programmer.97things.oreilly.com/wiki/index.php/BeautyIsin_Simplicity. The talk will be a short discussion of what I think is beautiful code, and include some examples.

Ideas from Lean is in my opinion crucial in order to successfully introduce agility to an enterprise. Scrum and XP will work for individual projects and can scale to pretty large development organizations, but when you try to involve the entire enterprise, Lean concepts has to be part of the implementation.

I will go through the key idea from Lean that I think is crucial for enterprise agility.

With borrowed money you can do something sooner than you might otherwise. If you are willing to incur technical debt you can release a product earlier than you might otherwise.

I want to go through the experience gained from switching from a pure Scrum process to Kanban.

Changing the focus from purely focusing on sprints and sprint planning to a pull-based constrained Kanban board driven approach gave us some truly revolutionary insights into our own process. This has allowed us to further constrain work in progress and really put the focus on implementing more ideas from Lean.

Plan to spend a couple of minutes introducing the key concepts of Kanban and the rest talking about the experiences.

Adopting some agile practices, like stand-up meetings and yellow notes, is easy.

The hard part is handling requirements and estimates, especially in a distributed environment. Describing, refining, communicating and prioritizing requirements is difficult for business developers. Estimating and understanding requirements is difficult for developers.

This talk describes a flexible sharing regime, implemented in a distributed in-house development environment, which succeeded in improving requirement handling and estimation.