Conference Program

Read the Participant feedback

• Session feedback
• Conference feedback

Pictures from the conference

• Harald Walker's pictures
• Lasse Koskela's pictures

Blog entries

• Federico Gobbo blogs about Scrumming the software process, People vs Process and Agile Requirements
• Dave Nicolette has written a summary of the conference and explains the Nine boxes
• The Solution Selling blog comments on Dave's article about the nine boxes
• Yves Hanoulle reflects after XP Days Benelux
• Bernard Notarianni has a report on the conference and on the Pomodoro technique
• Markus Hjort writes about the XP Day tour
• Pascal Van Cauwenberghe writes about the first day and the second day of the conference
• Matteo Vaccari is  back from the XP Days

• Emmanuel Gaillot
• Pascal Van Cauwenberghe
• Willem van de Ende
• Marc Evers
• Steve Freeman
• Lasse Koskela
• Yves Hanoulle
• Rod Coffin
• Nat Pryce
• Dave Nicolette
• Matteo Vaccari
• Laurent Bossavit
• Bernard Notarianni
• Markus Hjort

Find more blog posts about XP Day on Technorati.

15-16 November 2007

Mechelen, Belgium

• 24/11/2007 -  Your feedback about the conference is available here. More reports and pictures are available.
  
• 24/11/2007 - Links to many of the books exhibited at the conference can be found on the Systems Thinking booklist
• 21/11/2007 - Your feedback about the sessions is available here. Thank you for helping us to improve our sessions and the conference. More session materials have been added to the program page.
• 17/11/2007 -  Blog reports and pictures are published on the reports & pictures page. Contact info if you have written a report or published pictures.
• 17/11/2007 - The conference is over. Session handouts and presentations are being added to the program page
• 20/10/2007 - Early registration is over. You can still register until mid November. Don't wait too long: 2/3 of the places have already been booked.
• 25/09/2007 - The program has been published. Register now to qualify for early registration discount (and to be sure you can get in before the conference is sold out).
• 02/07/2007 - The Call for session proposals has closed. We received 41 proposals. The proposal authors are now working on improving their proposals.
• 14/05/2007 - Call for Sessions published

Sponsors:

Contact us to sponsor the XP Days at info

Payment by Bank Transfer

Agile Systems vzw,
St Pancratiuslaan 49,
1933 Sterrebeek, Belgium

Bank (Belgium): Dexia Sterrebeek, Mechelsesteenweg 223, 1933 Sterrebeek, Belgium

• Belgium: DEXIA 068-2436543-27
• EU zone: IBAN BE48-0682-4365-4327 BIC GKCCBEBB

• Postbank 940532
• EU zone: IBAN NL49-PSTB-0000-9405-32 BIC PSTBNL21

This is the fastest and cheapest method of payment.

Contact accounts for further inquiries or if you have any problem registering or paying. ]]> pascal 21 November 2007 22:19 GMT http://www.xpday.net/scripts/view/Xpday2007/Registration.rbl http://www.xpday.net/scripts/view/Xpday2007/Registration.rbl pascal 21 November 2007 21:58 GMT http://www.xpday.net/Xpday2007/session/CommittingToDateNotes.html http://www.xpday.net/Xpday2007/session/CommittingToDateNotes.html Committing to a date in a product release environment

Session Notes

After our presentation and simulation, which we hope you all found interesting, we ended the session with an interesting Fish-bowl discussion.

Here is list of the issues we tackled and a summary of the ideas that came out of the discussion.

The list is too long to make decent estimates : it takes quite some time to make an estimate and there are too many items. How can this be improved?

• Limit the list, prioritize it and add some requirements later
• The person asking too many requirements should feel the "pain"
• Estimate the value of the requirements to aid the prioritization
• Let an accountant estimate the value of the requirements
• Limit the time used for estimating
• Make the cost of estimating visible, use a Kanban board to give visibility on how much is already being estimated
• Plan in the estimation work
• The product owner should filter the list based on the value of the requirements

If you decide to divide a cornerstone in parts : how is this best done? Horizontally of vertically?

• It depends on the project
• Horizontal
  • + easy to distribute , split up the work in parallel
  • - you need a clean design before starting
  • - takes longer to test end-2-end
• Vertical
  • + there is always one part extra working

• Do a combination of both Horizontal and Vertical
• Have one team doing the integration while other teams focus on their area of expertise
• In the session Multidimensional Planning, all secrets around this subject were reveiled
• An interesting book around this issue : Scrum in the enterprise (Schwaber)

How can we make clear that prioritization would be more beneficial if done early rather than later?

• "Waste" Not prioritizing early sometimes results in waste : work is started on some requirements but they did not make it into the release 
• Make a "Fuck up" chart showing all the waste
• Make the cost of estimating explicit
• Work on releases in sequence instead of overlapping
• Do not start on requirements before the priorities are decided. If you do start this will hide the problem

What about small releases?

• Customers are not eager to take in new releases because it gives them extra risk and validation work when taking in the new release
• The Service point of view (few big releases) and Development point of view (many small releases) are often opposite of each other
• Having small releases reduces the need to maintain bugfixes over different releases (the one in the field, the upcoming release, ...)
• Make upgrades easier to make small releases possible
• Go even further: pushed automatic upgrades
• Long periods of time (e.g. 1 year) between each release makes it difficult to decide on the content of the release. Each client will want to have all its requirements in the upcoming release. Otherwise they might have to wait too long.

Organizers: Matteo Vaccari, Federico Gobbo

Objectives:

To learn about the Pomodoro timeboxing technique

Contents:

The Pomodoro Technique is a time-management technique that can be used by individuals, or teams. It is valuable in helping people to focus, to handle interruptions, to track time spent doing tasks, and to sort out where the difference between "ideal engineering time" and "calendar time" comes from.

We work in small, tightly focused time boxes of 25 minutes, followed by a 5 minutes pause.  Each of these time boxes is called a "pomodoro", (Italian for "tomato") because we use a tomato-shaped kitchen timer to mark the time.  Whenever we start working we turn off email, instant messaging, phone and we load the timer to 25 minutes.  Then we just work, and do nothing else.  When the timer rings, we push the keyboard away, get up, breathe, and perhaps reflect on the work we just did.  Was it effective?  We mark a tick on the story card, or personal journal, and rest for a few minutes.  At the beginning of the day we plan how we'll use our pomodori.  At the end of the day we record all the pomodori spent on each activity.  Right now, my timer reads 12 min., so I still have time to keep editing my session proposal :)

Topics we'll cover:

• why is it useful?  why does it work?
• how to apply to individual work
• how to protect your pomodoro
• applying the pomodoro in teams
• planning and tracking in pomodori

The technique was invented by Francesco Cirillo, and is widely applied among Italian XPers. Many people apply it even outside software development. There is a paper where the technique is explained.

Process & Timetable:

Matteo and Federico will illustrate the use of the technique via dialogue and pantomime.  We'll show how the technique is used, and play a few sketches such as, "how you deal with someone who keeps interrupting your pomodori."

1 pomodoro (25min): motivation, how to use it individually.

5 min. pause

1 pomodoro (25min): how to use it in teams: tracking and estimating in pomodori.

Intended Audience:

any -- the technique is easy to learn and widely applicable

Benefits of participating:

To learn a very useful technique. Once you're pomodoro-infected you'll start using it all the time.

The conference is organized in Elewijt Center near Mechelen, Belgium. Mechelen is located between Brussels and Antwerp.

Travel

By car:

the conference center is near the highway between Brussels and Antwerp. See the map

Traffic alert: expect traffic jams on the E19 around Mechelen (coming from Antwerp/The Netherlands) and the Ring around Brussels (other directions).

By train:

• Mechelen can be reached easily from most Belgian railway stations.
• Mechelen is a stop on the international line Amsterdam, Rotterdam, Antwerp, Brussels.
• Travelers from the UK, France and Germany can take the Eurostar/Thalys to Brussels Midi and take a train to Mechelen (25-30 min from Brussels)
• You can take a bus or taxi from the train station to the conference center or carpool with other conference participants. Bus 280 "Mechelen-Vilvoorde" stops right in front of the Elewijt Center, a blocky building (see the pictures below and the plan of the center).

By plane:

Brussels airport can be reached from most international airports. A taxi will bring you to the conference center in +/- 25 minutes.

Ryanair flies into 'Brussels South' (actually Charleroi). You can take the bus shuttle to 'Brussels Midi' train station (+/- 1 hour) then take a train to Mechelen (25-30 minutes).

Car pooling

If you're looking for or can provide a ride from/to the conference center, add your name to the Carpooling page.

Staying in Mechelen

Presence of software in products is rising rapidly. Software engineering today increasingly goes hand in hand with other engineering disciplines (e.g. hardware, mechanics). Product development is more and more a multidisciplinary endeavor.

Development actions and decisions taken within one discipline have profound impact on other disciplines. This impact is often not easy to anticipate and understand. Using agile methods to create quick feedback mechanism and transparency seems like good tools to apply in multidisciplinary engineering environments.

However introducing an agile development method that originates from the software community (e.g. Scrum) into a hybrid engineering environment is apparently not so easy to do (due to differences between disciplines, cultures, development tasks…).

The aim of the session is to explore to what extent can agile be applied in a multidisciplinary engineering environment. Other objectives are:

• Identify success stories where agility was successfully applied in such heterogeneous environment
• Identify key success factors for applying agility in these environments
• Identify relevant and existing state of the art techniques, method and tools
• Identify follow up actions needed to address these problems (e.g. initiate research, create faq, setup community…)

The session process & timetable

• 35’ Presentation of the problem (identified challenges)
• 50’ Workshops organized in groups (mix of problem owners and experts) in which the most relevant challenges will be analyzed and ideas collected in a presentable way
• 35’ Presentation of the results by different groups

Session Format

workshop, interactive presentation, case study

Intended Audience

e.g. apprentice, journeyman, master We are looking for two sorts of attendants:

• Problem owners: people who want to or are trying to apply agile in an environment that is not pure software development
• Experts: people who think they can contribute in creating solutions for identified problems

Benefits of participating

• Gain insights in difficulties of applying agile in multidisciplinary (or non-software) environments
• Get an overview of existing state of the art
• Chance to discuss your problems with the European experts in agile development
• Become a part of creating solutions for the issues many companies face nowadays
• Chance to become a part of follow up initiatives

Duration

120 minutes

Materials needed

e.g. flip charts, beamer

• Flip charts + markers
• Beamer
• Several round tables (can be formed during the session)

Organizer bio

This session is initiated by Sirris in collaboration with Triphase and Barco Avionics:

• Sirris is the collective centre of the Belgian technology industry. We advise and support companies on the implementation of technological innovations, enabling them to strengthen their competitive position over the long-term. In the software engineering group of Sirris we use Scrum in a non-conventional way: to organize our diverse and often multi-disciplinary activities internally, and also in some of our collective research projects.

• Triphase is a Belgian company that provides solutions for the fast realization of complex, high-performance power electronics applications, such as motor drives, power grid control, induction heating, lighting and many more. Triphase sells programmable and user-friendly systems for rapid prototyping of new power electronics applications, ensuring these prototypes can instantly be turned into products. Triphase uses Scrum to get a grip on the planning of the different projects, but the extensive research and prototyping in new developments, and their multi-disciplinary nature are posing challenges in full adoption of Scrum.

• Barco Avionics is a division of Barco specialized in the development and production of cockpit displays. Due to the extensive regulations and safety aspects that characterize the Avionics world, the introduction of Agile techniques poses specific challenges. Barco will highlight its experiences in the introduction of SCRUM in its software development team and difficulties encountered in introducing SCRUM in the broader realm of hardware and mechanical engineering.

Vladimir Blagojevic
Hans Keppens
Stijn Rameloo
Wim Codenie
Tom Tourwe

• Short introduction to EMC and Centera, including the quality challenges we face for a tier-1 product
• History: where does Centera testing come from and where does it stand today
• Requirements for testing a complex distributed storage system being developed by multiple teams in multiple locations
• The Centera approach to meet the testing requirements
• Testing at the right level: unit testing, component testing, system testing
• Lessons learnt and challenges we still face

Prepare to be surprised!

This track provides a space for agile practitioners to share experiences, challenges, new ideas, experiments, anything that comes up during other sessions in self-organizing groups. We apply the Open Space principles to foster just-in-timeliness of topics and allow the workshop to take its direction from the participants themselves.

We apply The Law of Two Feet - if you're neither contributing nor getting value where you are, use your two feet and go somewhere where you can.

From the law flow the four principles:

• Whoever comes is the right people

• Whatever happens is the only thing that could have

• Whenever it starts is the right time

• When it's over, it's over

See http://www.agileopen.net/on-open-space for background information about Open Space.

In the past he was active in a large telecommunications company where he performed various activities ranging from systems integration, systems testing (mainly protocol compliance and large scale performance and stability tests), standardization, product architecture, and translating market requirements into technical product requirements.

Homepage: http://jawn.net

He’s been active as an expert on integration and conversion issues between the ibm iseries – aka as/400 – and the Microsoft .net framework.

He is a certified scrummaster and uses TDD, xp and scrum practices in his projects.