The last couple of weeks I have been re-discovering an old diagram (eerm … sketch really). You can find it scribbled on close to every whiteboard in our office now. Because it opened a lot of interesting discussions on flow, flow efficiency and optimizations for value delivery. I wanted to share this with you here, in a few iterations and also share some of the discussion that it triggered. First of all, this came up as we had a process that was taking a long time. Too long. It involved a few people from different departments that needed to do their work before handing it over to the next department. And then there was a user acceptance testing phase in the end that of course took a long time. The backlog of work is growing much faster than these people are completing work. High stakes, stakeholders, and customers getting angrier...

I often give out a lot of books tips in lectures and workshops, so instead of me typing and find links everywhere, I thought I’d put together a list of them here. There are only 10, so if one is added another one needs to leave. That said - they are in no particular order. For each, I’ve given a short little review and comment on why I like the book. Toyota Kata - this book by Mike Rother is very interesting and useful. It describes how Toyota, inventors of Toyota Production System (that later became Lean) and the Toyota Way thinks. Because many organizations have tried to copy Toyota and failed - this book goes beyond the how and looks to the thinking, philosophy that makes the continuous improvement work. Amazingly the book manages to do this in a very practical way and gives the reader many tools to...

“Wow - this release was awesome. So fast, almost no manual testing and only one bug found in testing,” Sarah exclaimed in joy. “Yeah, but there was that one bug. It should be zero, huh?”, Marcus responded grumpily from his corner, without looking up from the screen. “Also - there are still manual testing going on. It should be all automated,” John chimed in, unimpressed. “Fast and fast … still our build runs in 8 minutes. That is a long time. Way too long if you ask me!” Alex sighed as she pointed to the build log on the screen. Sarah went back to her desk. Her enthusiasm was gone. I think we often miss the improvements we made by not looking back and appreciate the journey we made. If we only talk about what is still not great we lose track of how far we have come. This is...

Just finished “The Art of Coaching”, by Jenny Bird and Sara Gornall, that taught me a great deal so I thought I’d write down some thoughts and comments. I honestly don’t remember putting this book into my basket and was quite surprised when it arrived among some other books in my package. Hence I read the book with very open mind and curiosity. Confession time: I have no formal training as a coach, and still that is the most common name my roles have. But, as a friend of mine once said when my lack of formal training worried me: Have you clients ever complained about your lack of formal training? A great coaching question that moved me ahead in my thinking. I’m leading with this story because this book is packed with stories like this. The reason the book is called “The art of coaching” is that it is...

Got a question in an email the other day, asking some advice. Nowadays when that happens I ask permission to publish the answer here to not waste keystrokes into the email-bin. The question was from my friend Jonas, that works in a start-up that is growing rapidly. He kindly granted me permission to answer here. He was asking this (my translation): We are on the brink of a substantial expansion and I was wondering if I could pick your brain on experiences and best practices for how to organize a team of developers. We’re thinking about a team of 4-6 people that has responsibility for a specific part of the product. What roles and responsibilities should be in, or out, of the team? And in a follow-up mail: In particular, the product owner role and what that role does and doesn’t do. I like the PO very local and present,...

I’m talking less and less about agile and even lean, these days. Instead, the poison I’m selling now is flow. In all honesty, it might be better to put it like this: Opening peoples eyes for the benefits focus on flowing work smoother and faster, alleviates discussions about lean and agile later. Flow is an eye-opener and shifts your perspective. Things that previously was paramount (ensuring people are not idle, for example) becomes irrelevant or uninteresting. New ways, practices, and innovation quickly spur. But also new problems occur. One of the most common ones is the fact that flow is severely hurt by tasks that have many dependencies. I think I talk to teams about 4-6 times a week about this. In this post, I will offer a few thoughts on how to handle this type of situations. You say ‘problem’ - I say ‘unrealized improvement’ First of all -...

As a consultant, you get to see many, different organizations and look deeply into what makes them tick. This is a great benefit of my job, but at the same time quite hard to find from time to time. The reason for that is that most organizations have very lofty and worthy values but what is lived out is something else. But I’ve found… who am I kidding … stolen a way that make values more tangible and important in our everyday life. It’s a simple trick that you can start using tomorrow. Regarding these lofty values I mentioned in the intro, you know what I’m talking about, right? The values are words and statements that basically no-one would disagree with: Fun! Have you heard anyone say; No - I'm not fun. I don't want to be part of that Professional! - BAH! That's a fad. It will pass Open...

I had another opportunity to learn a thing or two about Google Sheets and it’s internal functions. Again. On a similar topic as last time. This time around I had to summarise the data from 4 different sheets and then let the user filter the data dynamically. To do this, I had to look up a lot of things, learn a little bit about the QUERY-function and then jump through some hoops. I write this down here so that I don’t have to learn this again. You can read it if you want to. I’ve created a sheet with some example data, similar but not the same as the data we had. This was also, as last time, a survey about the state of our office that we needed to summarise for a meeting. We had asked for input and asked people to classify the data in 4 areas; “Urgent”,...

I was asked to join a team for a backlog grooming session. We went into the room and opened the backlog in JIRA. It was exactly 99 items long. Not too shabby, but still… 99!? Ninety-nine items of work we hadn’t done. Yet. This of course triggered this jolly team to start singing and we soon where humming along: 99 tickets of work in the #backlog99 tickets of workTake one down, pass it around, throw it out because it is not required anymore, even Done but we didn’t update JIRA or we might not understand what it says98 tickets of work left in the backlog15 minutes spent #agile— Marcus Hammarberg (@marcusoftnet) January 23, 2018 In this post, I wanted to share how we cut the backlog in half in 45 minutes. And then share some thoughts on backlogs that I have running in my head. Complete half of the backlog...

As a consultant and coach, I find it very fascinating to see how the same topic has a tendency to arise in many different place and conversations I’m in. All of sudden everyone needs to chat about flow, or estimation or what-have-you. I like telling stories, as a mean to teach and explain abstract concepts. Often when I’ve told a story once it has a way to surface back into conversations in the near future. I partly blame it on my limited imagination, but when it fits the conversation it’s interesting to notice how you tell the same thing several times a day. The last couple of days people have been asking me about slack, and I’ve related a story about the pastor that married me and Elin. He was excellent in manage his own time and respected a good slack! Slack, in this context, is the time you get...