In Italy we aren't just able to cook nicely but we also take a look at how we develop software to try to improve. :) The Italian Agile Day is one of the most important conferences in the field, and it has just been held in Milan. Here's an account of what I have been exposed to during the event, whose talks can be considered at the advanced level.
Claudio Perrone: Le 3 Rivoluzioni (The 3 Revolutions)
Agile was the first revolution: Claudio presents it counterposed to waterfall as an empirical approach to software development, where Inspect&Adapt and the reality of distributed decision-making surpasses the imposition of a process over our people.
Lean is the second revolution (and buzzword) of the last years, with the diffusion of the Toyota Way in our field. Lean has many points in common with the Agile movement, but it takes a more systemic approach to problems, not being afraid of introducing change outside the development team, in the rest of the organization. While process feedback in Scrum is contained in retrospectives, it is really continuous (every day, every houts) in the Lean ideal.
Lean Startup is the third revolution: the extension of empiricism and the scientific method to every phase of product development. The collection of data and hypothesis formulation are not relegated to improving our story-point estimates; they are executed to every feature of the product to check if it really works as intended and brings in more value (or money) than its absence.
It's really complex to summarize the Agile, Lean and Lean Startup movements in a single hour; but Claudio made a nice job of storytelling and creating curiosity inside the minds of many colleagues that now would like to know more about them.
Pierluigi Pugliese: Lo Scrum Master come sviluppatore di teams (The Scrum Master as developer of teams)
In this two-hour workshop, I learned about the three sides of the Scrum Master role (and in general of our work): the social, structure and knowledge side. To be complete, we should face the issue by working on all sides, but it's natural for us to select one of them as preferred. For example, I'm more inclined to resolve a new bug with an excess of knowledge (explaining in every bit how a language or a model work) while I could also intervene on the process by introducing a regular QA phase (structure) or pair-program with another team member to improve our understanding of the system and avoid further bugs (social).
Jacopo Romei: In cerca del cigno giusto (Looking for the right swan)
Jacopo performs an example of A3 thinking in the search of a scalable and extremistan business model for his company, Ideato; this search has resulted in a new kind of Agile contract, which is not really a contract in legal terms but a partnership renewed each week (with the kind of continuous feedback that this imples).
I am not keen on business advice right now as I am busy with technological and management issues, but this is another point telling me to learn to use A3 as problem solving tools. What I understand best is that if you solve a problem with an A3, you have found a repeatable and standard way to approach a problem, and to share its resolution with colleagues instead of presenting just a solution.
My take away: read Taleb (which I did) and learn at least a bit about A3, which everyone is talking about.
Ilias Bartolini: Training and Coaching Agile Minds
Ilias has been a coach in two Thoughtworks Universities, a 6-week Thoughtworks internal event for the benefit of new hires (if you don't know Thoughtworks, go look it up).
This talk is well-intentioned and useful, but can be misunderstood as tree-hugging advice: the kind of advice that makes you a better husband or friend instead of a better software developer. However, it's nice to be reminded of the soft skills that we geeks need to work on from time to time. :) It would take a bit more context to be able to suggest concrete practices to adopt in this field.
My take away: in give-a-man-a-fish style, training is giving away the solution to a problem, while coaching is helping a person to become capable of solving it on his own.