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.
Humane assessment is a versatile and generic method. That is both a strength and a weakness. The strength is that it can be applied in many situations. The weakness is that it is perceived to be too distant from concrete scenarios that development teams face.
To bridge the perception gap, I have started to look since a couple of years for classes of problems that are concrete enough to be directly applicable. The first one is that of steering agile architecture for which I designed a 2-day course.
The concept of architecture started to regain traction recently. For example, two new industrial conferences were launched recently on the subject [1] [2]. That’s a good thing.
However, there are still quite some open questions as to how architecture fits within agile development. Of course, the main focus still tends to be placed on how to create architecture, and less about how to deal with the existing one. Humane assessment fills the latter space quite well. Specifically, the daily assessment process helps teams to make architecture concerns explicit and keep track of what goes on in the system. That is why the course is not about good or bad architecture. It’s about knowing the real architecture of your software system, and choosing to how to steer based on that reality.
If you are interested in working with me, please drop me an email.
Here is a teaser video.
On July 16, I will give a talk at Agile Breakfast Luzern on Steering agile architecture. Here is the abstract:
"Emerge your architecture" goes the agile mantra. That’s great. Developers get empowered and fluffy papers make room for real code structure. But, how do you ensure the cohesiveness of the result?Testing, pair programming and code reviewing are the proposed means to approach this problem. However, testing is only concerned with the functional side of a system, and thus, it is not able to capture structural contracts. Pair programming and reviewing work well in the small, but they do not scale when you need to handle the millions of details entailed in modern systems.
The architecture of the system is important and it deserves special attention because it is too easy for it to go wrong in the long run. In this talk we sketch a method of approaching this challenge on a daily basis by:
- making architectural concerns explicit,
- crafting automated checkers,
- agreeing on findings, and
- distilling corrective actions.
Why daily? Because architectural integrity is about the most important long term technical asset you have.
This process requires a new kind of infrastructure and associated skills that enable you to craft checkers fast and cheaply. However, this is a technical detail. The critical benefit comes from making architectural decisions explicit, and from the daily actions of cleaning the state of the system.
This talk is targeted to both engineers and managers. We cover the basics of the process, and we accompany the conceptual descriptions with real life examples.
The talk I gave at NDC Oslo 2015 on Don’t demo facts. Demo stories! is now available online.
The slides for my talk on Don’t demo facts. Demo stories! are now available on slideshare.net.