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 ...
So in short - they too need to scale their agile initative.
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 ...
This post is work in progress - I’ll finish it tomorrow.
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.
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 ...
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 ...
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 ...
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?”
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 ...
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.
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 ...
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:Read on ...
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 alongRead on ...
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 ...
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 ...
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 ...
At </salt>, a boot camp that I’ve been part of setting up, I get to try all kind of different things that I haven’t done before. Mostly around configuring, management and supporting the students computers and our code.
Just last week we had the need for a simple way to do a copy of our GitHub repositories. I did some research and found a simple way that I’ve put together in a script. I wanted to share it here.Read on ...
When I introduce agile I do that through a nice little quandrat originally from the This is Lean book by Pär Åhlström and Niclas Modig, and visualized by Håkan Forss. I’ve wrote about it here. This post will only focus on the top left triangle - where we focus on maximizing resource utilization.
But I’ve noticed that personal stories sticks better and I have used a story about my dentist to show an example of a setting that focuses heavily on the resource utilization.
I lately was called back to a checkup at the dentist and did some further research. It was a fascinating peek into a world where many people was working hard, smart and diligent to achieve an outcome that was not any good for me as an end customer (aka the wrong thing, in my book).
I wanted to share this story with you, as I think it teaches us a lot about where focus on resource utilization can lead us… everyone working very hard to do the wrong thing.Read on ...
Quite often I get to introduce people to using a “work visualization board” (often referred to as a kanban board), these days. When I do I’m struck with the common misconceptions that follow many tools - especially tools that I have been nudged (or forced) to use..
I wanted to share a few of the things that find myself repeating to new users of kanban boards.Read on ...
Hey Marcus, can you just add a License file to each of our repositories?
All of them?
Yeah, all 42…
This was a task given to me about 50 minutes ago. I’m done now.
Obviously I spent all that time writing a script to do this. And I wanted to share this with you guys and my future self.
Obviously I learned a lot as well.Read on ...
I got another email from a former client that I wanted to answer here on the blog. In fact, in this instance, I also got the same question during a Lean Coffee discussion at a current client too.
Without stating the whole email the questions were a little bit like this:
With kanban - isn’t there a risk that you lock in and cement the different parts of the board?
Also, are we not risking to focus too much on the efficiency of the individual steps in the workflow?
Since the board clearly shows bottlenecks in some areas we risk putting in an effort to solve that and then just move the workload to another place in the workflow.
and then in the lean coffee
I don’t like those columns - it looks like a waterfall. I just want DOING to show that we are working together.
Well.. thanks for your questions. My answer is Yes, Yes, Yes and Ok. … but also No, No, No and Why.
Let me explain.Read on ...
The last couple of weeks I have talked a lot about prioritization at my current client. In many conversations, I’ve felt the need to go back the foundation of things that I build my coaching and consulting on. For example, I might question how we prioritized as we done, and then I notice that people become defensive - thinking that I am questioning them rather than the way. This has led me to reflect, formulate and then re-iterate three basic assumptions that are increasingly important to me:
Let me describe a little bit more what I mean.Read on ...
At my current client, we are trying to make a change to focus more on flow than on resource utilization. This is harder than it sounds because much of the current ways of working, structures, roles and rewards are built to support another mindset.
One of the things that lately have popped up for me are the words we are using to describe the roles we have in different parts of the organisation. This heavily prevailing in the IT-industry and maybe agile actually has helped to cement a few of these (an excellent keynote by Michael Feathers put me onto that idea).
This also ties into a great quote from David L. Marquet and his excellent Turn the Ship around book
There’s no they on Santa Fee!
Let me try to explain.Read on ...
I got a question the other day from Enea Zuliani and Michele Degrassi. It was particularly heartwarming to read as they just read Kanban In Action and now have started to use. Kanban. In action.
They now had a question and I asked if I could share that question and my answer here on the blog. They kindly obliged.
Here’s the question (I’ve edited it a bit):
Dear Markus, let me get back to you with a question. If an agent has to choose between different kanbans (cards) which one to work on, and all the kanbans have the same characteristics (dimensions, etc.) and he can actually decide to work on every one of them, is there any “rule” you might suggest in order to pick a kanban - everything else being equal?Read on ...