bipsons ramblings

Same as it Ever Was

Fri, 05 Jun 2026 14:11:30 +0000

Over the last year or two I went from desperately avoiding the AI hype train as long as I can, through the inevitable Deep Blue, to feeling a high urgency in adapting to the new reality. Through that process I arrived at a resolution that helped me clear the dread of these changes. This process made me reflect on my personal relationship with Software Engineering, and the origins of Software Engineering itself to realize that this brand-new world is, in many ways, same as it ever was. Let me explain.

The Many Faces of Software Engineering and Computer Science

Similar to most of my peers of my generation, I distinctly remember the first time I felt the excitement of realizing the mutability of “Personal Computing”. While PCs were considered just another (alien) tool, I was in awe of this “serious toy” where you could arrange, execute, copy, modify. Unfortunately there was no one around me that could seriously mentor me into that world ¹, but this feeling of being on the edge of a vast world of possibilities remained the same through discovering new games, tools and (programming) interfaces in general.

The Fun

This feeling became more concrete when I got a Game Programming bundle that included a copy of Visual Studio C++ and a Game Programming with C++ book (which was a terrible introduction for a 15 year old that could not grasp pointers for the lack of understanding of memory addresses and machine instructions). There I was, sitting in front of my parents’ 500 MHz machine, coding a terrible text adventure in C++ using only switch instructions. But most importantly, I knew why I liked it: The things I was discovering here were glorified “building blocks” that allowed me to “create” things and solve problems - a feeling I find addictive, and assume similar to the feeling of discovering wooden building blocks as a toddler, or Lego as a child ². The main characteristics of this feeling are Curiosity, and the eagerness to explore those amazing new possibilities.

I think that this feeling is always present when we discover new tools or frameworks, new ways of modifying our environment and realizing that this allows us to create things. Unfortunately, this feeling seems to wane when the novelty wears off and is overshadowed by another feeling:

The Science

One aspect of Software Engineering that for most of us is the least present in our daily business, is the scientific aspect and background of it.

First, it’s clear that all of this is deeply rooted in science. No such thing as computers and software would exist if it wasn’t for the scientific breakthroughs behind it. And none of it would work, if all of it did not still adhere to the same rules: electrons moving through lanes and chips, switching (logical) signals, machine instructions based on logical operations, all the way up to lines of code in higher languages codifying a specific “if-then” behavior, and lately intent codified in prompts, spec-files and agent descriptions.

Second, there still seems to be a differentiating factor between good Software Engineers and less reliable ones, good environments and the “chaotic” ones: How much of the scientific method and science is applied. This not only includes basics as Complexity Analysis, but also when to apply existing algorithms (bonus points for being able to reduce to existing problems and their solutions), but also Software Design principles, patterns and best practices. Good Software Engineering still follows a rigorous process of applying proven principles and prior knowledge, verifying assumptions/hypotheses, designing good experiments, etc.

Unfortunately, as mentioned, for most of us, this part has become widely irrelevant for our daily business (or at least you can get away with neglecting it completely). This is mostly due to the environment we operate in, but also due to the last aspect:

The Mud Pit

For various reasons (I don’t regret), it took me quite some time to go beyond the surface of Software Engineering. But when I did, and before I could become comfortable with the scientific background, I quickly encountered another reality of Software Engineering: Our Master’s Program for “Software Engineering and Internet Computing” was organized widely with assignments that partially extended to the whole semester. Some of which were more loosely defined, some of which had clear objectives and clear guardrails to work in, e.g. implement specific features for a Java-EE backend, including database modeling, concurrency aspects, interfaces.

While the intention was to have us understand advanced and modern aspects of backend engineering hands-on with practical examples, the result was quite different: Most of the time was not spent understanding the theoretical aspects and applying them, but I remember it as if I spent most of the time fighting the tools I was given: Library version mismatches, sifting through StackOverflow to debug the current failure, researching which library version requires which annotation on which field to (reliably) trigger a certain behavior, maven/gradle/build/deploy configurations and weird caching phenomena.

I remember that back then a blog post was getting a lot of resonance: Its premise was that we are no Software Engineers, we are “Software Gardeners”, not engineering anything really, but planting the libraries and frameworks someone else built and trying to create a nice and usable garden for it, fighting the weeds and grime that inevitably tries to take over our gardens.

I remember vividly how I was torn on those assignments: I wanted to approach all of those methodically and like a scientist, but the number of moving parts, the immense complexity of all the used systems and the pressure of approaching deadlines would simply not allow me to invest that much time.

Further, all the moving parts would make the system seemingly… non deterministic. As illogical as this sounds, changing one line of configuration or code would lead to completely unwanted results:

Enabling one feature of a library would break another.
Updating single libraries would lead to endless trial-and-error to find a working set of libraries.
Debugging one feature would lead down endless rabbit holes about why this feature is outdated, what it actually does under the hood and which feature replacing this feature was never finished.

This has somewhat remained the reality unfortunately, and I guess it depends on your area, product and peers/environment³ how much this applies to you.

And Now…?

A few years back I would have written something about us needing to fight this complexity, tame all those systems and remove the indirection they have caused. The origins of programming are with creating punch-hole-cards to encode a repeatable set of instructions. While we moved through abstractions so we don’t need to think of every single machine operation to achieve a higher goal, we at the same time developed huge, heterogeneous systems, which often include more library code than we are aware of, often various places to configure it (even with different file formats: YAML, JSON, .ini, …). These systems demand a lot of specific knowledge⁴ and mental load to sometimes even adapt tiny parts.

We usually know what we want to achieve, but the systems we created force us to wrestle them to bend to our intent.

And AI is the reason why I think the solution now (maybe not forever though) looks different to what I anticipated. We don’t need to tame this complexity systematically with new computing paradigms – because we (somewhat inadvertently) found a solution.

Programming has changed. We can avoid the mud pit. We can state our intent, the feature we want to implement, the issue we want to resolve and (most of the time) we can let our agentic tool solve the problem for us. We cannot (yet) remove ourselves completely from the process (and I don’t think yet we ever should), but our agents will (happily?) go through the various layers of redirection for us and “implement” our intent. While it feels like losing control, I would argue that we somewhat lost control a long time ago in some regards. Most Software Engineers would not be able to explain what a specific feature they use actually does, which instructions are called, how it works under the hood. Some of us didn’t even bother to understand where (on which machine) those instructions are being executed.

As frightening as it seems, agentic coding is maybe not the solution some of us wanted, but it might be the solution we deserve⁵. We built tech stacks that are absurdly complex and fragmented, which until now required us to spend energy and time on tackling and memorizing the stack itself and its intricacies. We had to build an AI to talk to it for us.

AI might be the first abstraction layer we introduced that reduces a significant amount of the complexity we created in the first place.

What’s Next

The thing is, nobody knows what will happen in the end⁶, but we know what is changing right now and how it will change our environment:

Agentic coding (or whatever replaces it) allows us to avoid the “terrible” parts of our daily business. All the hours going through the various layers and mind-bends, grooming boilerplate, researching the right incantation to coerce those systems to fulfill our (mundane) wishes can now mostly be avoided.

That also means that there is little value in paying “Software Gardeners” for this kind of work. Those that were content with maintaining those complex systems will probably need to change. But those that initially wanted to focus on the “real” problems of Software and the systems it created now will use AI as another tool in their toolchain and in return have more time to do what they intended to do in the first place.

But (fortunately?) this is also what AI cannot solve for us (at least not now): Taking care of the science behind Software Engineering, applying a scientific approach, isolating the issue, formulating the hypothesis, designing the experiment, setting the priorities, etc.

Most commenters summarize this as: AI won’t be telling you what you need to do.

Of course there are other problems that this new world causes for us and all of this is not only still young, it is also changing very rapidly. We will need to see how all of this works out for us in detail – but there is no way of avoiding it, so you can as well just stop worrying and love your agentic workflow.

I was limited to the things I learned in a 10 minute quick intro from the IT-guy that visited the plant my parents worked at every now and then, a floppy with Grand Prix Circuit and a mining game I can’t remember, and whatever I could find out myself about Win 3.11, the file explorer and the DOS prompt, which wasn’t too much. ↩
Thinking of it, I think this feeling goes well beyond Software. I feel the same when I discover a new woodworking technique or tool and am eager to apply it. ↩
I’m not saying I expect peers to solve this for someone, but IMHO the more your environment is aware and not only helps in taming the dragon but also does not create more dragons, the more you can focus on real problems. ↩
Some call this domain specific knowledge, but I tend to disagree: it is not specific to the domain. You can remain in the same domain but someone throws a new logging-framework at you, and here you are, learning the conventions of this framework. ↩
While the system we created can be tackled by our agentic tools, the complexity also is costly for those systems. Simpler frameworks will use less tokens, thus cheaper to maintain/extend. ↩
Thinking of it, I find both scenarios, from either The Matrix and from Terminator unrealistic, but that is for another time. ↩

So Agile Frameworks Won't Save You

Sat, 25 Apr 2026 21:35:03 +0000

Since we must concede that agile frameworks won’t save you, that raises the question: What to use instead? What is an agile organization, and how do you become one?

What is an Agile Organization

I’ve recently started reading Atomic Habits (I can only recommend it) and the first chapters are enlightening: We are habit machines, our habits shape our identity, and our identity shapes our habits.

It is a very strong feedback loop and one we can use to acquire new habits: We need to decide who we want to be, and make sure to act accordingly. This will make us who we want to be (eventually), and make those habits stick.

On the other side, trying to change habits by doing something once (not smoking, starting a new sport, etc) and hoping it just sticks this time, does not tap into this motivational aspect that is associated with identity (being a non-smoker, being an active person).

There is plenty more in those chapters that you should probably read if you haven’t, but this got me thinking: This is true for groups just as much, and also for organizations. Organizations that hope to become agile by putting an agile framework on top of the existing structures/behaviors/identity are the same as a person hoping that this time the morning run will stick.

What this organization needs is very similar to a person wanting change: Decide who you want to be, and then act accordingly time and time again – in with the good habits and out with the bad. And never stop reflecting on your habits and your (intended) identity.

I think it would thus be fair to conclude: An agile organization is one that behaves like one. As simple as that: An organization that shows day-by-day more agile habits than not.

Agile Habits

But what are agile habits? Sprints, plannings and retrospectives, doing estimations. Those are ceremonies, not habits. It’s like going to the gym every week with your friends, but sipping smoothies together instead of working out. Forcing everyone to attend a retrospective meeting for 2h is a ceremony – a team member raising: “I would like to talk about this motion we are always going through and how it is helping us deliver value (faster).” – that is a habit.

Framework/Process	Habit
Holding dailies	Syncing daily to create a shared plan
Estimating story points	Discussing on how a story could be cut to become smaller an more predictable
Every team must have a responsible Scrum Master	Everyone in the team feels responsible (for the delivery of value)

Thankfully the authors of the agile manifesto gave us 12 principles to go by. They stand exactly at this line between habit and identity, which allows us to determine if a habit fits the ideals of agile or not.

Discussing bugs using the ticket comment system? Breaks “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

The Bugtracker: Who hasn’t been summoned to one of those infamous bugtickets, with the sole comment: “Can you have a look?” Only to realize that you and your colleagues spent around 3 hours in total understanding the context of that issue, dissecting the comment history, guessing the priority of the issue, assuming what has already been checked, collecting questions, posting a carefully drafted response to the ticket, to be answered again a few hours later. Cue a week-long back-and-forth between customer - service department - expert group. Then somebody has the audacity to pick up a phone and have a call and everything gets so much clearer very fast. And you realize it was never urgent after all.

And another thing becomes obvious: An organization (that is/was not agile) can only become agile, if it is embracing the principles of agile in the first place. All actions and behaviors in the organization must be made with the question: “Is this action in agreement to what we intend to be? Is this something an agile organization would do?”

This not only requires the present leadership to support the agile transformation (on paper), they need to be role-models, showing agile behavior every day and being ahead of all their teams and reports and they need to make clear which behavior they expect from their reports and peers (and which habits they would like to go away).

Leadership builds the scaffolding of an organization. And this scaffolding must support the new ways, must enforce the new identity.

The Consequences for Agile Frameworks

This basically means that agile frameworks are doomed. An “agile organization” certainly does not need a framework or its keyroles, which leaves them as “blueprints” for organizations wanting to become agile. So: doomed.

For one, forcing agile processes on top of an existing organization will not lead to an identity change, and the bad habits of the actual identity will creep back in.

But isn’t the framework intended to explain the principles by ensuring practices? Yes, of course it is. But will the present leadership take part in the practices? Attend the ceremonies? Even be aware of the cadence? Or are they sitting in their office, none the wiser and repeating: “We’re agile now, things should be better now!” Followed up with a more silent: “But can someone explain to me, what the agile part of our organization is actually doing and how that is supposed to work?”

Ask yourself: How many times would the leadership put all-hands meetings or reporting requests in times that are completely screwing with the cadence of the “agile organization”? Pick out individuals from the team to put them on super-important strategic side-quests (without even informing the team)? Would they bring issues to the teams, or solutions?

That many individuals and groups fail to differentiate between behavior that “breaks” agile and when a (new) habit is welcome, is a natural consequence: Not knowing what agile behavior is, they cannot know when they are showing or (re)-introducing a bad habit, and ask in all seriousness: “Well, doesn’t agile mean we are allowed to change things? Just do it?”.

So, no framework, no processes – habits and mindset.

Consequence 1

Adding agile roles to you existing organization will not help you. Identity comes from within and is carried along by the system (or its remnants). So as long as you don’t intend to exchange the complete scaffolding of your organization, you must make this scaffolding carrying the new habits (and the motivation to become agile).

It won’t help to have agile coaches or amazing scrum masters, if there are contradicting signals (“bad” habits) coming from the existing leadership.

Consequence 2

If your organization is not truly convinced of the principles of agile software engineering, it is maybe wise to not attempt an agile transformation. And this is fine: Nobody is claiming that agile is “better” for you. (But we’re all free to state we believe in better ways of writing software.)

What to do instead?

But if agile frameworks are not helping the transformation, how should one make the agile transformation instead? I think we need to consult the Atomic Habits again: Identity and Motivation.

Step 1: Soul-searching

Does the organization truly want to become agile?

Only if the answer is an honest and clear “100%”, and if the organization understands what “being agile” means (compared to what they have been doing until then, only then should a transformation be attempted.

This question should probably be coupled with a more general “Who are we and who do we want to be?”. Being “agile” is most certainly only part of an organizations DNA (and not necessarily the most important one – most organizations don’t even bother to mention that: it’s a given).

Clearly such an exercise must be led and driven from the very top of an organization.

Step 2: Embed

The next step is to embed agile habits into the daily operations as much as possible. The goal is not to be perfect, but to show more “good” habits, and fewer “bad” habits, and seek ways to improve this ratio constantly.

From the top down, the leadership should seek to understand how their current mode of operation is either helping or hurting, showing good habits or bad habits. This is deeply tied to embedding intent based leadership into daily operations and removing aspects of the command and control mindset. Thinking this part would be “easy and fast” would be presumptuous, especially since it requires deep understanding of the agile principles and how to apply them.

In parallel, habits all over the organization must change: Since you cannot take down the existing scaffolding in a running system, take existing meetings and “infect” them with (at least) one “agile habit”. Have your responsible IC demo a new feature to the customer, instead of just having the product management showing the changelog. Or draft an implementation plan together with developers, considering how they would implement a feature, instead of presenting your plan. Let agile habits and their benefits speak for themselves and “contaminate” one meeting, one product, one department at a time.

Step 3: Reflect

Reflect on your current state: what is good, what is bad; what works, what hurts. Reiterate on who you want to be.

Then apply those learnings to draft your next small action. Your next experiment. Make reflection and experimentation, seeking better ways, the norm for all parts of the organization.

Present the results. Yes, also the fuck-ups.

This step is also a great opportunity to “live” another agile habit: Are you going to do this reflection on your own, or are you going to invite different perspectives? Different ideas for improvement opportunities?

Summary

After all, an agile transformation is and will remain an incredible feat. Assuming that you can change the identity and habits of an organization, that has been working for quite some time in non-agile ways, with a leadership that has (mostly) had limited exposure to agile principles and habits is nothing short of illusory. And no (large) agile framework will (probably) be able to change that fact.

Nevertheless, you should never say never, and it might be possible. I would argue though that if you want to avoid an agile facade, it must go over the self-enforcing feedback loop of identity and habit formation.

Why You Should Not Need a Scrum Master

Fri, 17 Apr 2026 08:36:54 +0000

There is a discussion following me basically since I started as a Scrum Master: Are Scrum Masters really needed, or are they simply expensive team secretaries? In my opinion both are true. Let’s explore why.

Agile is Dead

At some point in your journey, no matter if you’re pro or anti-Scrum, you will have encountered the “Agile is Dead” mantra. “Even the authors of the Agile Manifesto are saying this!” someone might have thrown at you as well.

You might have watched what this is all about, or perhaps not. In any case, here is the summary from Gemini (so you don’t have to take my word for it):

In his 2014 article, Dave Thomas argues that “Agile” has been corrupted into a rigid, commercialized dogma that obscures its original intent of being an adjective, not a noun. He proposes abandoning the brand to focus on authentic agility, defined as smaller, iterative, and responsive software development, rather than ceremonies. Read the full argument at pragdave.me.

Most carnival barkers that like to throw the “Agile is Dead” into discussions (some with no small amount of schadenfreude) miss these core facts:

Dave (and others) are not denouncing the Agile Manifesto, its ideas or principles.
The assumption is that agile software development has become the norm anyway.

The core message IMO is that agile frameworks and the commercialization thereof created those “fake agile” facades in non-agile organizations, which is even worse for them than being non-agile. Further, for those organizations that are agile, the frameworks are a distraction and pure overhead.

Given their own mindset and history, the authors might be slightly biased regarding the capabilities of the general software engineering world to figure agile out completely on their own. For those individuals and organizations, an agile framework promised the chance to master agility eventually, by adopting a (more or less) complete blueprint, e.g. Scrum.

Defense is Futile

Regarding the mastering of agility, I’ve long been a proponent to the idea of Shuhari. It made a lot of sense to me – to become an agile master, you shall first learn from a master. The master will make sure that you obey, and honor the wisdom of the school and the ones masters before him. As such, I’ve seen those infamous agile ceremonies not as sacred, but as vessels to convey the principles of agility. A clear and simple structure to follow, so “apprentices of agile” might understand the purpose of writing software in an agile way.

I used to say to colleagues: “That stuff is easy! How can we claim to have it all figured out, if we can’t even implement such a simple structure?”

I saw a lot of teams and organizational units struggling hard with agile frameworks, because they clearly bent too many rules before even understanding what the ceremonies were trying to teach. “If they could only stick to the framework, they would eventually see” I was convinced.

I think what Dave and his colleagues were trying to say, and something I am starting to believe:

No agile framework can teach organizations agility. Period.

In my experience the resistance to shift to an agile mindset is too big for an organization – which is after all, a living organism. It starts with leadership; despite all the best intentions, they fall back on old habits to resolve issues. Worse, these organizations tend to have or create ineffective Scrum Masters, who lack the ability to show agile leadership, by e.g. enlisting disillusioned developers from their own ranks.

When this organism encounters friction, it will take shortcuts to bypass the framework – and not knowing better: its principles. And anyone whispering “First, you must obey the rules…” is doomed to fail against a culture way bigger than they are (cf. Team Geek). Ultimately, the framework (and its proponents) will be blamed for the failures caused by the shortcuts that broke it in the first place.

Why You Might Still Need a Scrum Master

In my experience, those that question the benefits of Scrum Masters (and other “framework roles”) the loudest, fall into one or more of the following categories:

They had bad experiences with the framework or how it was lived (agile facade, bad leadership, shortcuts, vacant roles, etc.).
They would in fact benefit from the structure, but they just feel the pain and blame the framework or the leaders.
They are actually agile (by mindset), and any framework will always feel restrictive.

Depending on your corner of the industry, you might have only encountered the last category, others have so far only seen the first and second category (unfortunately those two might coincide). The thing is, while both views are absolutely relatable, they are on completely opposite ends of the spectrum.

I am inclined to agree with those individuals and organizations, which already have a growth-mindset and exercise lean and agile principles, that they would not benefit from any strict framework, and most certainly not from having dedicated roles that enforce it. What they still need though, is leadership that nourishes the Kaizen mindset and reinforces this pre-existing culture.

For the first two categories, their only hope to ever experience agile is to receive coaching, mentoring and teaching by a true leader, in an organization that allows the principles to become and stay alive. I’ve encountered several senior developers (juniors typically don’t dare to do this) becoming essential saboteurs of themselves and their team, believing that the framework was out to get them and impeding them with some bureaucratic nonsense, while they were obviously breaking their commitments, messing up priorities, getting stuck in uncritical side-quests – all of them at the same time.

It is those developers that would IMO benefit the most from a framework to set guardrails for them, and reminds them of the priorities and goals of the organization and their team, from peer pressure demanding lean practices. But maybe the frameworks cannot hold this promise of built-in guardrails and implicit teaching agility via Shuhari. Maybe those organizations need (their) leadership to act as catalysts, mentors, teachers and coaches to enlighten their peers anyway, but then is a framework still needed?

The real question is though: Does the organization as a whole, the leaders and the individuals, truly want to become agile? Do they understand the principles and implications, to understand how their habits need to change for this to happen? Since this most certainly requires changes to behavior, intrinsic motivation is a prerequisite.

There is more: For an organization to successfully transition into agile, this motivation must be so strong, that the leadership will lead the way: truly adopting an agile mindset and a leadership language, The actual fallacy might be organizations believing they can “become agile” by adopting a framework, while the old leadership remains in place and not only ignorant about the framework, but also clueless about the principles and habits of being agile and how the language needs to change. Becoming agile is not a grassroots movement.

But if that motivation exists, Scrum Masters as change agents and which understand their leadership role beyond a ‘team secretary’ might be just what that organization needs to resolve systemic issues, become predictable and focus on outcome instead of ceremonies.

Now we just need to get rid of that title…