Hi, I'm Marcus
Notes on agile, lean, flow, programming, AI and the life of a consultant. Twenty years and 1280 posts in. More about me →
· 4 min read
A few years back I wrote about some of the sayings that I like so much that I have them as daily reminders, in the form of screen savers.
Yesterday I was reminded by another and I thought I’d write a blog post on it - it’s just one word, and turns out to be great career, leadership and business advice - Others!
Here’s the list of the others (pun very much intended):
· 7 min read
I have written many times about how I feel about the current obsession of output over outcome. Here’s an example of numbers that I see presented with a bit of a worried look.
+2450% lines of code, 400% increase in files touched, 240% more commits and 170% increase in number of PRs, but only 30% more releases. So bigger releases a bit more frequently is how I read that. To be honest 30% increase in number of releases is mind blowing, but in combination with the other metrics scares me.
I’ve spent a hefty portion of my career preaching the opposite. Smaller things more frequently rather than bigger things seldom. Here we see bigger things more frequently.
And there’s another thing that is not even tracked in the picture above - what happened? What was the outcome of the increased output? For example, did the increase in the number of release have to do with failure demand since our releases now also were bigger?
The agile, and lean, answer to this problem is clear; smaller batches. Let’s play with the idea.
· 4 min read
I believe in this concept, but the implementation above is risky and invites failure
This is a line, on page 2, from the 1970-ies paper that defined Waterfall model (although named like that in the paper). It is, if you continue to read on, “risky and invites failure” because things pops up that might change what we thought earlier. To my understanding the author, Dr Winston Royce spent the rest, not only the paper but career trying to explain that people misread his first diagram as something good.
· 9 min read
Digital product development is changing in foundational ways. Close to everything we used to “create” is very likely to be done by an agent going forward. Code, design, tickets, tests and what have you. The most likely first of those is code (as in code will not be written by humans - there I said it) so I’ll use it as an example.
My immediate feeling is one of almost dizziness over how much that changes and what we will actually do… well no one knows yet. But it will be very different from today and that has my head spinning.
To have something to hold on to I started to think about whether I could come up with some values or quality gauges that would always be the same to steer after, regardless of how the output is created.
Like this - let’s say that the agents write the code, design, test and all of that instead of you; how would you know that the created product is good? That the code is good? That the process is good?
Yes, I’m looking for outcomes that are good to steer towards, regardless of how the output is created. It’s that simple. And we have probably measured most of these before, but now I’m coming at it with a different pair of eyes.
I make no claim of having a definite list here, but I felt a bit calmer after doing this and have a direction to navigate towards regardless of how my ship is propelled.
· 3 min read
In this age of automation and AI I enjoy the simple physical things where I can get them. Like finding a proper kanban card to help my work flow just-in-time.
· 6 min read
I was just in a meeting where we rattled of a few basic features to build on top of a database. It sounded a bit like this:
And at this point I just realized that the other features were now redundant. Because with our database hooked up to a LLM Chat that is operating on the data using an MCP server, all those questions would be possible to answer.
Are features not our main deliverable any more?
· 6 min read
The paradigm shift that we are in is now real. I just realized how much my own world has shifted in what and how I do things at work, in less than a year. December 2025 was the first time I allowed an agent to write a feature from a prompt and felt safe that the result would be good enough to use.
I’ve been thinking about welding and punch cards - and that has helped me think more freely about where we are heading. And what my value will be in that world.
· 7 min read
Since I started to see people use AI to build digital products something has always rubbed me the wrong way. It is like we are forgetting value, outcomes or impact and just keep clapping for the output. Token-maxing is real and I often have a hard time reaching through to people with this message, just because we are so happy that we close more (and bigger) pull requests.
Let’s not forget that. Let’s bring a value-obsessed, outcome measured and impact focused way of working back. Right now we are wasting the human capacity on keeping the agents busy.
I’ve written a few posts now on flow in the age of AI and to be honest, the other posts have been a setup to this post that is like the main idea (or itch I needed to scratch). Let me bring you up to speed with a short summary of the concepts so that you don’t have to read all of the posts, and provide links back to them.
· 6 min read
I’ve written a few posts on AI and how it changes the flow of value, looking at it using my Theory of Constraints glasses.
But are we really moving up in the value chain or is it actually deskilling and we end up baby-sitting an AI robot?
You can find them here, if you want:
But I had a few more things that I wanted to get out of my system. The first is the fact that with automation, such as robots, the workers moved up in the value chain. This is happening again now, as AI is being used to do much of the writing, creation and generation.
· 9 min read
The revolution, well paradigm shift rather, we are experiencing in AI has a likening with how industrial robots made a paradigm shift in the manufacturing industry in the 80-ies. Both when it comes to how it was introduced, the fears it raised, the mistakes “we” did utilizing the power and how the winners ended up using them.
Now, I’m old but in the 1980-ies I was 10 years old and more interested in playing games on my Vic 20, soccer and riding my bike (yes, it was a simpler life). But I have read a lot about this topic since this was when Toyota started to blow the competition out of the water. Also, my all time favorite book The Goal (by Dr Eliyahu Goldratt) has the robot revolution as part of the driver of the story and the problem picture.
In this post I wanted to dive a bit deeper in the likeness of industrial robots and AI tools and see what we can learn from them. I think that my analogy holds in many areas but to keep things a bit more tangible I will keep this to digital product development in the wider sense of the word, i.e. not only coding.
I have written two posts that relates to the topic, but you don’t have to read them to make sense of this post. I hope.