Most of the people there were not developers - quite a difference from Java One or Devoxx. This impacted how the sessions looked like - more talking, less demo's; more social, less technical.
Key points (tracks) of the conference for me (random order):
- Pomodoro technique. I attended a session about Pomodoro, it was interesting enough for me to try at home. My milleage 'varies' so far, but I really want to make it work. There is a simple but useful timer for Mac.
- A lot of stress on TDD. Many people talked about how great it is, how it helps them write good code, how it helps the design to emerge etc. I guess I have finally been convinced to the when.../should... style of writing unit tests.
My favorite quote was "TDD (test first) is the only way to ensure your code is testable".
- Lot's of stress on individuals and interactions over processes and tools, despite visible presence of tools vendors, esp. continuous integration ones.
- I really wanted to learn about Kanban, but I rather failed to achieve that. I attended a session about Lean (and Lego bricks), it taught me a bit about Lean background in manufacturing, but not directly about using Kanban in software development.
There was another session that was intended to prove that Kanban is better then Scrum that I haven't attended, but from what I heard the presenter exaggerated Scrum faults too much just to prove the thesis.
Later I have read the article by Henrik Kniberg, it answered most of my questions.
- Agile is dead. Not literally, but many voices say that Agile already became mainstream, so it's time to bring Agile to higher level.
Everybody already uses Agile for small non-mission critical systems for which Agile was originally advocated. Now it's time to bring Agile to big, mission-critical and corporate environments, or at least this is the subject the 'thinkers' should focus on.
- Game theory in agile contracts was an eye opener. The message to me was "stop being so narrow-minded and think". During this session it was applied to formulating an agile contract equally profitable to both parties. I was too married to my ideas of how the contract should look like that I either favored one party too much or provided too little incentives to get the best contract outcome.
Of course this was just a simplified exercise, but it showed that out of the box thinking can be applied also for contracts.
The more I think about it, the more I agree with the concept that software development is not about computers and technology, it's about people.