Nowadays project managers more and more frequently choose agile methodologies while conducting sophisticated projects. It is mainly because it increases effectiveness of the team and customer satisfaction. Unfortunately as in other methodologies problems with human resources occurs quite frequently. Most of the problems are connected with (lack of!) communication.
What can be done to avoid at least some of them? How to improve communication with customer and communication between team members? Fortunately there are many possibilities. One of them is simulation game.

It is not a silver bullet... but it can really help in a difficult situation. The game enables people to look at the world through somebody else's eyes, feel as totally different person, try a completely different solution - in a safe conditions. During the game the players have to accomplish totally crazy project in an agile way. Side effects of the game - players may: die of laughter, start to like each other, want to play more often ;)

Badly written tests are a nightmare of many agile projects. Hard to understand and maintain test suite sometimes act as a brake on introducing changes. In this talk I will discuss basic techniques of refactoring test code. During live coding session I will simplify non-readable tests in few simple test. I will show, among other things, various ways of creating test data, expressing assertions and avoiding duplication in tests.
Speaker Bio: Piotr Jagielski is a developer who uses test-driven development technique in his daily work. He currently creates applications for airline industry at Sabre Holdings in Krakow. He also gives trainings on topics related to unit testing.

Being agile is not a piece of cake. Being agile when you're the 'remote site' is even harder. The presentation will cover our (Pragmatists) experiences in a project where we acted as a nearshore team: what issues we had, how we coped with problems we faced, how was the cooperation developing.

Paweł is a software architect and a consultant of enterprise software. Since 1999 he has been working in the design, development, and auditing of projects in a multitude of fields like banking, insurance, telecommunication, and media. He is an agile coach and a strong believer in the value of quality in software. Paweł is an owner of Pragmatists, a Warsaw-based company focused on creating high quality software using agile methods.

What if an Agile Coach could have a way to determine the right question to ask to intervene on an individual or a team? How valuable would this be for a such a coach?The Solution Focused methodology is widely used in psychotherapy and also in coaching. It is based on designing a solution and working out the steps needed to achieve it. This is a very elegant approach because it shifts the discussion from the emotionally-filled problem state to where the result is: the solution state. This technique can be successfully used when coaching Agile teams, for example during planning and retrospectives, but also as a reflection mechanism and coaching technique for Scrum Masters, Product Owners and the whole development team as well.

Pierluigi Pugliese started hacking code so long ago that he cannot remember exactly when anymore. He worked many years in the mobile telecommunication business, both as programmer and as a team leader, providing software for several mobile phones of known brands.

Currently he works as a consultant for software organisations and coach for individuals and teams, focusing on software development and software processes, helping them implementing sound and agile solutions.
Pierluigi is based in Munich, Germany, and operates through his company Connexxo.

In this fast-moving and varied presentation, Gwyn and Laurie will condense over a year's worth of retrospectives into one hour of shiny new practices that have been stress-tested in small web development teams.

We'll talk about the Wall of Wire, the Sword of Integration, and how to play Speed Poker with commitment and without cards. This is an experience session, so each new tool will be supported by a description of the problem that caused us to develop it, and the results of putting it into practice.

Other areas we'll cover:
* How to use a sword of integration to fix build collisions (unimportant) and weld a group of programmers into a high-performing team (important)
* How to recognise a Stealthholder before they destroy your project
* How to enhance planning poker to get more accurate estimates, faster
* How to use heat-seeking actions to make sure that meetings actually achieve something
* How to survive if you're scrum-mastering several small projects at once
* How to use lego to introduce Agile to customers