(Moved this page from the old wiki because of the fun outcome and positive atmosphere in the dinner.)

Agile Dinner on Tuesday, February 3rd, Helsinki, at 18.00.

Organized by: Ari Tanninen (at iki dot fi) Mobile phone +358 400 400 470

Location: Restaurant Baker's

Theme: What have you done right in your previous software project? Something that made the project successful, or worked well enough that you would like to do it again in your next project?

Forget agile, forget Scrum, forget what it says so in the book. Specifically ignore what the guy next to you is trying to tell you. This time let us discuss what you have experienced yourself!

Try to keep the items in the context of software development methods though. While showing up work is a key for success in any project it does not make for very interesting discussion.

We shall begin with a quick post-it session to see if themes emerge.

Currently registered:

1. Ari Tanninen (at iki dot fi)
2. Roberto Fasciolo (at huitale dot com)
3. Stephen Sykes (sdsykes of gmail)
4. Marko Taipale (at huitale dot com)
5. David Harvey (dharvey at metaprog dot com - http://www.teamsandtechnology.com)
6. Juan Carlos Borras (jcborras_at_gmial)
7. Markus Hjort (at ri dot fi)
8. jonas lindström (at paf dot com)
9. Fredrick Karlsson (at paf dot com)
10. Mika Viljanen (iki)
11. Taru Salmimaa (at tut dot fi)
12. Natalia Reen (at pbi-institute dot com)
13. Janne Pietiäinen (jpieti at gmail)
14. Sebastian Vuorinen (sebastian at windcuffer dot com)
15. Santeri Korri (at iki dot fi)
16. Antti Tarvainen (at iki dot fi)

The outcome

First we listed "things done right" on post-its, categorized them and started a thrilling three hour discussion. Here is the list categorized by theme. Almost looks like the table of contents of an agile software development book!

Teamwork

• User stories, open scope, team to propose options
• Arguing and fighting in team (read: constructive conflict)
• Very few developers
• Completely co-located team - good stuff
• Team sitting around the same table
• Truly cross-functional team
• Self-organizing a team with 2 developers and (an almost) PO

Working environment

• 50 square meter bullpen with 5 people with all of them doing software and it is sooooo... QUIET
• Under time pressure two programmers occupied one meeting room, split work into two pieces with a fuzzy line in between, worked together 2-3 months to write substantial software from scratch
• Information radiators (physical)
• Scrum wall
• Setting up whiteboards and an index card backlog

Direct access to business people and users

• Asking why & having access to business guys
• On-site customer
• Direct contact with customer & end user
• Customer came to the team and was angry about a feature. The team changed the implementation in three hours according to new spec. After a lengthy discussion the original spec was considered best. Then the team removed comments.
• Team got the why of the project
• Throw out complexity

Learning

• An experience of pair refactoring with a less experienced developer: looking at code - working out the right questions to ask, and ending with a much improved design.
• Agile method enabled us to teach "younger" team members during the project
• Weekly examination of top risks
• Looking into value-stream
• Having someone who has done it (agile & software) before in team (or a coach)
• "Why?" Challenge everything
• Use very simple metrics

Technology & Architecture

• Hourly integration and automated regression testing
• Writing automated tests under the radar
• Automated acceptance tests
• Frequent integration
• Basic architecture with CRC cards

Miscellaneous

• Honesty
• Delivering frequently (or pretending to at least)
• Releasing often
• Plan and think a lot, implement only what you know is needed

So in summary the recipe for success is:

Form a cross-functional team, put them in one room where they are surrounded by information radiators and whiteboards and can work in peace. Provide them direct access to business people and end users and make sure they understand the goals of the project. Maintain the big picture and provide an environment that facilitates learning and try to involve experienced developers and maybe a coach. Use metrics to measure progress. The technical environment should allow for continuous integration and automated regression testing. Consider laying down basic architecture. Be honest, deliver frequently and think a lot.

(Sounds like something I've read from a book. Hmmm... And was it David who mention something about flying monkeys...?)

- Ari