In this article you’ll learn about agile retrospectives, the basic principles of Non-Violent Communication (NVC), and how applying those principles to a retrospective can improve the retrospective.
If you’re already familiar with agile retrospectives, you can skip the sections explaining it.
What is an agile retrospective? An agile retrospective is a meeting format, commonly used in software development, but also suitable for teams outside of software development. Its main purpose is the continuous improvement (Kaizen) of processes, collaboration and work itself.
My notes from some of the sessions I attended.
I attended the SoCraTes Day Berlin and came back inspired and full of ideas I want to share with the world.
Lean Coffee We discussed estimations (Complexity vs time, who needs them, when are they helping) and I learned about the method of “Magic estimation”. Someone mentioned “Scripts to rule them all”, an attempt to establish a common set of scripts in each project that do certain project tasks like bootstrapping, resetting, updating, running the CI validation, etc.
I attended SoCraTes 2017 in Soltau. SoCraTes is an “Unconference”, where the participants set their own agenda and come up with topics for their sessions. Sessions can be presentations, workshops and open discussions.
Here are the notes from some of the sessions I attended:
Programming Exercise: Banishing State The example of this exercise was taken from a real-life project: A book indexing service that takes keyword/page number pairs as input and outputs either the page number, a range of page numbers or nothing, depending on previous inputs.
I attended the SwanseaCon 2016, a conference about Agile Development & Software Craftsmanship. I enjoyed most of the talks and took some notes for the most interesting stuff:
My two favorite talks Immutable architecture “Your servers are not your pets” - don’t give them names, don’t tend to them with complex state-based configuration management software like Puppet and Chef, don’t get emotionally attached. Just build the environment you need using simple tools like Ansible, deploy the code to it, put it behind your load balancer and throw the old one away.