A couple of years back, while I was involved in a group that eventually created the ScALeD principles, we were of course discussing the benefits of the different scaling approaches out there. One of the participants – I think it was Andreas Schliep – mentioned to me that the release train concept in the scaling approach that Mike Beedle always referred to as S_Fe was pretty clever. Since I spent some amount of time on trains in the past twelve years, I tend to disagree. Let’s see how I perceive the release train metaphor based on my experiences in the German train infrastructure.
I recall when I read the #noestimates book, there was a concept that felt strange to me – and it still does. Without spoiling too much, at one point the concept of running, tested feature (RTF) is introduced. Let’s explore my thoughts together.
Sometimes while reading along song lyrics, I get some silly inspiration. One of these days, recently I listened to Let there by Rock by AC/DC and got the following idea for an Agile version of the lyrics.
This week I had a conversation with several coaches at a client on something I consider pretty basic Agile knowledge, actually. To collect my thoughts together, I think it would be good practice to write all of them down for the time being. The topic at hand deals with test automation and enabling release-at-will through a zero-bug policy and how to get there. I think it’s going to be a brief blog entry, but fear my thoughts might run away there. So, stay with me.
Sometimes while reading along song lyrics, I get some silly inspiration. One of these days, I crossed Hymn from Edguy, and found some Agile adaptation to its lyrics.
The other day, someone on the Crafters’ slack posted a video where someone argued about software craft vs. engineering and asked for opinions from the community. Let’s elaborate on my reaction to watching that video.
Stick around long enough in the consulting business, and you might notice something I will coin the Arxta-Moment in this blog entry. I’m pretty sure, I’m not the first one to notice this, yet, I’m unaware of someone giving it a name. Let’s explore some history, and look for some advice from Jerry.
Over the years, I have seen many companies struggling with paying off technical debt and legacy code. Heck, I produced legacy code within a 45-minute session at a code retreat on my own, so consider me guilty as charged as well. Over the years, I have seen a pretty tiny fraction of companies actually managing their technical debt. So, here are a few stories that I oftentimes share from these companies and how they tackled technical debt and legacy code – with no claim for this to be a complete list of things that might work. Please add any additional advice you want to share in the comments.
A few years back, I ran a public course in Düsseldorf, Germany. While looking through my options for one of the evenings, I noticed a public Coding Dojo run by the Softwarkskammer group there and decided to have some coding fun in the evening. During the dojo, I had an experience with one of the attendees that I keep on sharing every now and then.
I think I wrote up on this a while ago. Since I keep on referring to that experience, I thought maybe a reflection on what I think happened a few years later, might be helpful.
A couple of times, I found a particular pattern of interaction from a team with some other group (or team) useful. I would not recommend it all the time, but there appear to be appropriate use cases every now and then. Since I didn’t cross similar thoughts in the Team Topologies book, I thought it useful to write up as inspiration for others. Let me introduce the ambassador to a team.
