Last week I attended SoCraTes UK 2015, the UK edition of the International Software Craftsmanship and Testing Gathering. This blog post gives a short introduction to the conference, and holds a readable version of my notes from various sessions.
What is SoCraTes
SoCraTes is an unconference for open-minded software people interested in professionalism, improving their skills and elevating the software industry as a whole. It started several years back with SoCraTes in Germany, and now includes editions in several countries, the most recent addition being SoCraTes Belgium. All these events share the same style: they are community focused, non-profit (you only pay for the meals and accommodation), self-organizing, at a beautiful venue and fun. Check out the relevant websites for more info.
What the days looked like
The conference started on Thursday evening with introductions, lightning talks and informal sessions. Unfortunately I arrived quite late and thus missed that part.
After breakfast on Friday, people made proposals for topics to talk about or discuss, a process repeated on the next day. After the many sessions of each day, lightning talks where held, followed by a retrospective. In this retrospective one attendee briefly summarized for each session what it was about or outlined what they found particularly interesting. After dinner some people continued with informal sessions amongst themselves, while others played board games, went hiking or simply had a beer.
This was my first software event on which I did the Run Up and Down a Hill kata. Unfortunately I did not record any metrics, though I can say it was completed successfully.
Some things also happened on Sunday morning, though I missed those due to leaving early.
Notes from sessions I attended
I ended up taking less notes than I’d have liked due to being very tired through most of the conference.
The values behind XP
The values behind XP are communication, simplicity, feedback, courage and respect. There was some discussion on “why agile failed”, ie why people are using the rules while forgetting about the values. The main point made being that it’s a lot easier to change a process than to change the values of people, and that often people say they support values without actually acting as such. We then tried identifying the values behind several of the XP practices, using a voting process over which we iterated several times 🙂
After the session a survey was created to vote on which values are most related to which practices.
An introduction to nonviolent communication. The basic idea being that there are a set of universal human needs that when violated result in negative feelings and often result in associated aggressive behaviour. As the session host noted, while this might seem obvious when phrased like that, a lot of people in the software industry tend to dismiss emotions as this annoying thing that should stop bothering them, while to be successful at nonviolent communication, one needs to recognize the needs and emotions of others and of oneself.
One should be careful to not include judgement about people we are talking to.
The goal of NVC is connecting with people, not persuasion, which in itself can be a form of violence.
Steps to go through: make objective observation without judgement, identify feelings, identify needs causing those feelings, make a request for action free of demand.
During this session the host presented a pile of useful tools that one can use for deliberate practice. I did not make notes since the slides where supposedly online somewhere. Not found them so far though and will edit this later if I do find them.
One book on this topic that I can recommend is Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.
Starting a new project
This session was about impact mapping can be used for planning at the start of a new project. The map starts with the goal (why), then explodes into the actors (who) and finally into the what. This impact map was created interactively during discussions with the business people. Since the resulting list of features was quite big, grouping was needed. Turns out that such grouping is useful for determining the bounded contexts of the system, and for giving those subsections names that make a lot of sense to the business.
Spreading Agile to other parts of an organization
This was a small group discussion in which we explained past failures in making other (non-software) parts of an organization more agile and thoughts on how to go about it better. I did not take any notes here, as none of what was said struck me as being specific to making other parts of an organization more agile. Instead the problems and solutions all seemed to apply to spading agile within development departments as well. Some of the points made where:
- Start with building trust. If you go in not trusting the other people, then expecting them to trust you to know how they should do their job better is a bit much to ask.
- Do not imply they are doing a bad job or need your help. Instead ask if they can help you by making some change in their process
- Lots of politics are involved. Often it is easy to get the big boss on board, with the most resistance coming from middle management
This session I attended by accident, apparently having gone to the wrong room. I stayed as the topic was quite interesting: designing code for developers. The session host presented the 5 rules of usable software outlined in this blog post:
- It is written for developers to read
- It is easy to find where to modify the code
- Any modification has a minimal ripple-effect
- It is easy AND fast to validate that we did the right thing
- We don’t have to do similar modifications in several places
These might remind you of the 4 rules of simple design. What is nice about the above list is that it focuses on intent and value, rather than on technical mechanisms.
There was also discussion about finding the sweet spot of trade-off between flexibility and simplicity which reminded me of the last few paragraphs in this article on YAGNI.
While I did not make notes for these, many of them link their slides or related articles on the lightning talks wiki page.
Links and stuff
Want to know more about Software Craftsmanship or join the action? There are many meetup groups, consider attending one of the awesome SoCraTes conferences, and check out these two highly recommended books: The Clean Coder: A Code of Conduct for Professional Programmers & The Software Craftsman: Professionalism, Pragmatism, Pride. Oh and, check out my podcast on the topic.