marcusoft.net - sharing is learning


function share(knowledge){ return share(++knowledge) }

When was Lars happy?


One thing that I love in coaching and consulting is when things stick. My way to try to get there is to tell stories (psst - there’s a book on that) to try to emphasize or bring out certain points.

What I find very rewarding is to hear people relate these stories to each other later on, when (they thought) I was not listening.

Just the other day I walked passed two people and I heard:

Yeah, exactly. Remember: when was Lars happy?

This is one story that I’ve told many times and I wanted to share it here too. It was a powerful lesson on true value, customer focus and lead vs flow time for me.

Read on ...

3 mindset shifts for agile transformations


I have been involved in many agile so-called transformations over my, let’s face it, long career. And the more I get to do that the less I care about the word agile. Because agile is “just” a way to behave - it’s not an outcome. The outcomes are what we are after, the effects, the values. I’ve found it much more fruitful to discuss what those values are and means, than to argue whether Scrum holds up for scaling or not.

In this post I wanted to discuss three shifts in mindset and culture that I found: Important - as these shifts in thinking will or will not, hold your agile efforts back.

  • Fundamental - as in; goes beyond (below?) being agile or not.
  • Not talked about or understood in the same way
  • Start asking some tough questions and hence rapidly increase learning.

These topics are:

  • Shift focus from activities and utilization to value and flow
  • Realize that software development is not manufacturing and start managing in a suitable way
  • Monitor success for products or value streams rather than project or functional silos

My feeling is that if we discussed and changed this, half of the agile journey is already done. Also, if you are not ready to change any of these, then any agile transformation will give local improvements, at best.

Read on ...

Scraping functionally - to save my inheritance


Many years ago I wrote a little site to keep track of fun things that my (then only one) son Albert said. I called it Abbe Says and it has been granting us and our friends great joy.

At its core, it is a very simple blog/content management system that I wrote in .NET (3.5 I think) and published on the first serverless offering I heard about - AppHarbor. I didn’t even know the term back then it was more like: HEY! Give them your codez and they'll make it run on Internet My feeble brain exploded.

Anyhow - I cannot update it for various reasons and I need to move it to a more modern stack. Thinking of Svelte and to run it from some static served …

I’m getting ahead of me - first we need to get the data. This post describes how I salvaged the data from the site.

Read on ...

How we agile - principle-led & context-dependent


Agile is soon (?) to be forgotten and ditched like yesterdays clothes if you ask some agilistas that I follow. I think the reason is that we have watered down the meaning of the concept by applying the name to more and more un-agile things. Soon we will be able to become agile without letting its ideas and principles changing a thing about what we do or how we act. Because agile is just some simple, yet powerful, ideas - originally described in the Agile Manifesto.

I yesterday posted the following at twitter:

And on LinkedIn I got even cockier and added

Yes that is “scaled” (whatever that is) hashtag#agile working and helpful, without any specific framework or tool. Just guided by hashtag#principles towards ever better versions of our practices. Thinking for yourself - it’s a good train. Get on it!

Some people asked me to write a blog post about “it” as in “What you have done there”. I wanted to do that but from the perspective of the principles. Because I don’t think anyone should copy what we have done - but I’d love if more people understood the principles we built it on and used that as inspiration to make something better for them.

I’m a bit worried to write this though. Because I’m worried someone will copy these practices.

Don’t do this! It will not work (as) well for you as for us.

Do, however, see beyond our practices and to our principles and see why we did what we did. And then try to apply that principle in your world.

Read on ...

Autonomous does not mean isolated


I wanted to write a short little post on a misunderstanding and confusion that pops up once you start to create cross-functional teams;

Autonomous doesn’t mean isolated

Read on ...

Reflection on a daily retrospectives


I have created a course, a boot camp to teach people to become programmers in 12 weeks. It’s quite amazing and you should apply if you want to change career. Check out Salt - School of applied technology

Obviously, that cannot be done. But we do it anyway. And we succeed - we get rave feedback from the places where our awesome students are working.

There are a few ingredients to the successes; people being highly motivated (I can write books about that) and mob programming are two of them.

But in this post, I wanted to write about something that I think stood out for me after observing 3 classes in a row now. And it’s something that you can do and get a lot out of too.

Read on ...

The consequences of prioritizing


Been talking a lot about the consequences of prioritizing today at my client. And about psycological safety

This excellent story that Staffan introduced me too, came to mind. (I’ll summarize it below - this is just an intro, to get you to read on)

And I came to think about how the consequences of prioritizing one thing over others, often end up becoming blame for the team. When it really should be praise…

Read on ...

KanbanStats - an average improvement


Reading books is awesome - because it changes how you see and think about the world. I’m an avid reader and a non-recovering learn-o-holic.

I read a great book the other week - When Will It Be Done by Dan Vacanti and it changed how I saw the world a bit. I wrote a whole array of blog posts on process metrics and now Mr Vacanti threw some of it on its head.

Not that much when you think about it, but enough for me to want to correct myself with this new knowledge.

It all has to do with averages…

Read on ...

The Kondo software quality index


Before I start I want to give credit where credit is due:

One of the things that I love most about being a consultant is all the amazing people I get to meet at my different client; brilliant, fun and experienced-oozing people that I don’t see or meet online or at conferences. They are out there. Scott Hanselman calls them Dark Matter Developers.

This blog is sparked from one of them; Yngve! Thanks!

At this client (where Yngve works as an infrastructure architect) we were struggling to measure software quality. The teams felt like they never got the time to take care of technical issues that have been lying around forever, that they were forced to tack on “yet another new feature” and that we had no good way to communicate this.

We needed a quick way to measure and track this - such as our non-technical coworkers understood what we meant.

We came up with the Marie Kondo-index for software quality.

Read on ...

Scaling agile - up or out


Friend: So in short - they too need to scale their agile initative.

Marcus: Oh - cool! Up or out?

Scaling agile has to be the term that I’ve seen most discussions, posts, comments and conversations about the last couple of years.

And Google seems to agree - it at is peak or going there right now.

But very seldom I’ve heard an explanation to what kind of scaling that is meant: do you want to scale up or scale out? My guess is that many times people talking about scaling agile mean scaling UP but worse I think that most times we have not decided. That is not really wise because it’s two very different problems to solve.

In this post, I wanted to reason a bit about those tradeoffs.

Read on ...

Principles and practices, guilds and cross-functional teams


I have been involved in many organisational changes that turn the organisation sideways. From functional departments to cross-functional teams, from projects and completing activities to continuous delivery and focus on reaching effects.

Just about always this creates some initial confusion around where decisions get made and how the old ways fit into the new. Quite often worry about chaos break out.

For example;

Who is in charge of the overarching architecture, now that each team is deciding everything by themselves?

I realize that I’ve done a bad job describing how this is going to work. The other week I found myself describing this with a pretty simple model that I wanted to share.

Read on ...

Tags, markers and behaviour it drives on the board


I just had a conversation with a client that I keep coming back to. It has to do with how we are using electronic systems that manager our work, for example JIRA and TFS.

I needed something to refer back to and I hope that you can get something out of me writing this down.

Read on ...

The things I (we) worry about in vain


Although I often preach about embracing uncertainty and sometimes get comments about always being calm… despite that; I worry. As do we all.

But sometimes, in rare moments of clarity, I have the opportunity to stop and reflect over the what I am worried about. It just about always brings me to the realization that I worry in vain.

Let me share three things in particular, that I have worried about lately. That gave me nothing but more worry.

Read on ...

KanbanStats VI: Queue length


UPDATE I have learned new stuff. There are a better ways. Find the update here

It’s time to wrap this series up. I have one final thing that I want to visualize: queue length. How much stuff is waiting and how long will that take us to complete? And maybe even, “if I add something in the queue now, how long before it’s done?”

  1. Lead time
  2. Lead time with filters
  3. Throughput
  4. Where time is spent
  5. Single numbers - averages, median and max of lead time

As always my sheet is found here and you can make a copy of it and use it. Please let me know how it’s working out for you and if you end up doing something cooler than me.

Let’s do it - queue length!

Read on ...

Trying out test commit or revert


I stumbled over a new concept the other day. As it was conceived by Kent Beck, that inspired and thought me a lot in the past, I got interesting.

[UPDATED]

I read Kents blog post a bit too fast and missed that this idea was actually proposed by Oddmund Strømmer. Very sorry that I missed that in my writeup, Oddmund. Thanks for correcting me, Raquel.

And after some even more research the origins seems to be traced back to a group of people that took a workshop with Kent Beck. Not only Oddmund Strømme but also Lars Barlindhaug and Ole Tjensvoll Johannessen. Those Norwegians… always a few steps ahead of me.

[BACK TO THE OLD TEXT]

When I read his blog post I got to this quote:

I hated the idea so I had to try it.

I felt the same actually and now I’ve tried it. I was so provoked by it so I had to try it.

The idea is pretty simple:

The full command then is test && commit || revert. If the tests fail, then the code goes back to the state where the tests last passed.

In this blog post, I have documented my complete workflow in getting this up and running and trying it out on a simple kata. The post became pretty long but is hopefully easy to follow.

Read on ...

KanbanStats V: Single numbers


UPDATE I have learned new stuff. There are a better ways. Find the update here

This post is all about just aggregating and averaging out to a single number… and then I can’t control myself but start to lay that number out over the individual weeks too.

That, and we will use the Gauge-chart for the first time in my life.

This is the fifth post in my series on some simple kanban board statistics. We have been talking about:

  1. Lead time
  2. Lead time with filters
  3. Throughput
  4. Where time is spent
Read on ...

KanbanStats IV: Where is time spent?


This is the fourth post in my series on some simple kanban board statistics. We have been talking about:

And this time it’s time to see if we can visualise a bit where time is spent. For this first post, we will make some basic classifications of active and not active or not “on the board” and “on the board”.

In the coming posts I want to expand on this and see if we can make a distinction between other states on the board as well, but for that, we need to expand the data in “Raw data”, because that data only contains completed items right now.

Ok - let’s get going. As for all these post I am in this Google Sheet - make a copy if you want to play along

Read on ...

KanbanStats III: throughput


UPDATE I have learned new stuff. There are a better ways. Find the update here

Lead time is awesome to track and try to improve. In fact, it’s something that will guide you to a lot of improvements and should be front-and-centre of your process metrics.

But that says very little about how much that gets done per time unit. Doing one thing in a day, fast and with quality, and then nothing for the rest of the month means that no other things get done.

Let’s start to track another metric; throughput or

the amount of material or items passing through a system or process.

With the data, we have this is pretty easy to get hold of.

Read on ...

KanbanStats II: filter the process chart


UPDATE I have learned new stuff. There are a better ways. Find the update here

This is the second post in my series where I show how you can get make powerful visualizations of process data. As before, my goal here is that you can dump your process data into one tab of my sheet and then the dashboard will make all the other calculations.

In the first post, I talked at some length about other goals of this tool and some of the principles I built these ideas on.

Speaking of those principles; in this post, I will violate one of them a bit, by adding a filter capability to the lead time chart, so that we can see just a part of the data.

Read on ...

KanbanStats: Simplify process stats - get started


UPDATE I have learned new stuff. There are a better ways. Find the update here

I have been coaching agile teams for about 15 years now. One thing that I often help teams that I coach is to tap their process of some valuable data. It turns out that many of the tools that we are using have a lot of data in them that we seldom look at and even more seldom act on.

Most of these tools (like JIRA or Team Foundation server) obviously have ways of looking that this data too, but I’ve found that it’s either really hard to understand the visualizations or that the reports that you can produce simply don’t cut along the right axis.

I’ve now grown tired of recreating these simple reports for every client and wanted to share my, very simple, stats here. This way I can reuse it for future clients and also maintain it in one place. The goal is simplicity – so I’ve put it on Google Sheets to be shareable. For the integration, between the dashboard and the different source systems, the goal is that you should be able to just paste in some data, in a certain simple format, in one tab (conveniently called “Raw data”) and then the dashboard will do all the other calculations.

Read on ...