On September 2, I will hold a session at the annual Lean Agile Scrum conference on the topic of Storytelling in a technical world. This year, the conference is about "Im Team zum Erfolg", and I am happy that the organizers saw storytelling as a significant part of what makes a team work.
In this one hour session we will play with various facets of stories and with how they can change the perspective.
On September 3, I will have the pleasure to give a workshop on Storytelling in a technical world at the /ch/open Workshop Tage.
This is the first incarnation of the storytelling course in a public setting. I must admit this is quite exciting given that it is pretty much the only workshop from the Workshop Tage that will focus on non-technical aspects of software development.
On August 26, I will have the pleasure of giving a talk on Architecture as a work in progress at an event organized by the Limited WIP Society Switzerland.
One key aspect of dealing with the Work in Progress is to visualize the queues. We have come a long way with dealing with explicit requests that come from outside. But, how do we deal with technical problems that come from within?
Let’s take the architecture of the system. It’s rather important as it can make or break your system in the long run. Of course, the agile mantra tells us that we should emerge the architecture. This sounds great, but how do we make sure it goes in the right direction?
One way to approach it is to make technical tasks explicit and put them in the same queue as the functional ones. This never really works because of two reasons: (1) business can rarely prioritize the work, and (2) it does not fit development workflows.
We argue that it is necessary to approach technical concerns differently. We still need to make them explicit, and we also need a queue. Only, it’s a different queue that is managed exclusively by the team and worked while dealing with regular tasks.
In this interactive talk we show concrete examples of how this works in practice.
A couple of weeks ago I had the pleasure of chatting with Carl Franklin and Richard Campbell on a .Net Rocks! interview.
We started from Moose and then we diverged into the issue of too prevalent code reading and how humane assessment addresses this part. We eventually also touched the Pharo live programming environment and the Glamorous Toolkit.
But, the experience was unique. I found both Carl and Richard to be great listeners, and I felt they helped me bring the message out. I could have done a better job, but it was certainly an interesting experience. For example, I truly love how they introduced the interview with a discussion about the return of Cobol. It paved the way nicely and I tried my best to link to it.
All in all, it was great fun. I’d do it again.
Our technical world is governed by facts. Specifications and technical details are kings and Excel files are their palace. This overexposure to facts makes us perceive the world in quantifiable and typically linear terms. Yet, this way of looking at the world makes us forget that the goal of our job is not to fulfill technical requests as fast as possible. Our job is to produce value.
Over the past years I got to experience first hand the negative impact of Excel-driven software development, and by the looks of things, it seems I am not alone. Indeed, while arithmetic can be easy and can fit comfortably in an Excel file, the value of a software project can rarely be captured through such a model. We need to change this approach.
Even when in teams that aim to work with agility, too often the talk is kept about story points, capacity and burning charts. While there is some interestingness coming from the facts that some charts need to burn upwards while others should burn downwards, in the end the talk is dry and the customer is kept far away.
We need to reengage with our purpose. This is not just a management issue. It’s also the responsibility of developers.
The best way I can think of to bring meaning back in our technical world is through stories. Not technical user stories. Stories that move. Stories that make us care. Stories that make build beautiful solutions. That is why I designed a 1-day course on storytelling in a technical world to get us started.
You might tend to think that there is no interesting story in your system. Think again.
It takes a leap to move from points to stories. Would you like to join me in this quest? Contact me.