I have probably introduce around 80-100 teams to the use of some sort of board to visualize their work. One of the things that I often … ah, always say and also have to repeat is this: Nobody has told us to create a board. We do this for us. This is great because that it means that we can change it how WE see fit Many teams that I visit are worried about creating a “good” board or even the correct board. Many times the initial feeling is looking for help from a manager on how it should work and look. I have never been told to create a board for a team. I’ve many time suggested that teams should have a board to make their work visible, apparent and easy to act on. This means that we are creating this board for us. Not for anyone else. So...

New year - new blog series. I was thinking about writing down some of the things that I find myself repeating often. These post will be short, and possible link to places where I’ve already said this already. I will collect these post under the label Things I say often I don’t have a list made up already, so I’ll write things when they pop into my head. Here’s first things I that sprung to mind. This is your board - change it Why? Improving means changing NO! This is how you tear off a post-it I don’t care about efficiency until we know our goal I run on feedback Leadership - not management I hope you will enjoy this series. I know I will benefit from writing some of these down.

When a year has passed I often try to think back and find the one most important thing I learned. This year that was a bit tricky since I’ve learned so amazingly much. So good - and some bad. The single piece of advice I got that stood out was about presenting. And it came from one of my oldest friends, one that I call my brother: Kalle. Kalle is a pretty young guy but he’s very thoughtful and … yes I’ll say it: wise. Another thing that stands out with him is the fact that he’s just become a Salvation Army Officer, a pastor if you want. The advice I got from him was just before I was about to deliver my first ever “message”, or short sermon. I had asked him for all kinds of things about this but the final thing he left me with was: The...

This will not be an ordinary post. Just a write up of something horrible that happened to us during Christmas. It ends well, but was a horrible time in our lives. During the Christmas our family experienced the worst scare and troubled time yet. In Indonesia but also in our lives. It all looks like it will play out alright but many people have asked me to share the story, so i will do that here. If I find the strange I’ll write a follow up post with some lean-learnings that this could teach us, but not now. The accident We were going for carolling on the Christmas eve. This is an old tradition from the band I grew up in and something that we have done in my family to. Today it failed: not only was people not at home, but also… When we got to the Commissioners house,...

I’m a coach for teams and organizations. At many of my clients I don’t do anything… Or I’m not typing code maybe is a way of formulating it since I’m very much involved in what goes on (and I also want other companies to hire me). But really I’ve had a hard time to come to grips with what I’m really doing. Many days is just listening (really just that) or maybe make sure that two people talk. Other days it might be sitting down with someone and think. Or redraw a board that we decided to do but everyone found to boring. I’ve also done training, or suggested other trainers to come by or even suggested that we’d just try something new, like mob programming. But I’m quite often not very busy and when you look back in what is produced it’s hard to see my foot print (very...

I’ve been re-reading The Goal. For the fourth time. And I still got that buzz from it. It’s such a great book - I recommend it to anyone interested in business and becoming more effective. The Goal is the best business book I ever read. Re-reading it now, 4th time. Pivotal learnings, great story. Read it now! @GoldrattBooks— Marcus Hammarberg (@marcusoftnet) December 16, 2014 The book of course got me thinking waaay to big thoughts for my small head and I went all gaga over it and tried to convince people around me that we need to rethink why we are here etc. This time however I dared to question the book too. I love it. So much that I think it will take me question it a little bit. Because there’s one thing in the book that I have a little problem with. And I cannot wrap my head...

Now, if there ever was a book that filled a need this is it! I cannot count the number of teams and companies that have struggled to get user stories right - this book is packed with practical, solid, experienced based advices on how to improve how you use user stories to your advantage. Throughout the short book the authors share their vast experience and again and again shows us that user stories is less about the tool and more about the thinking and approach to software development that follows with it. I like the structure of each idea that gives a background, a rational and some practical advice on how to get started. Add to this the funny, informative and beautiful graphics that accompanies each idea and you end up with just an awesome book. The book is organized in 5 parts that connects nicely into the natural software...

I’m waiting at a train station to go back after doing 2 presentations on kanban. It’s super hot, I’m tired and it’s 2 hours to wait before my train, with AC, comes. Perfect time to write a blog post in other words. (I’m also happy, proud and healthy again after my flu - came out a bit pessimistic there for awhile). One of the things that’s always included in my presentation is a slide that asks for feedback. “I love feedback” is my presenter notes and then I ask the people in the room to give me some. I have experimented with a few ways to get proper and honest feedback and I wanted to share my latests experiment. Doing now What I’ve done up to now is to ask for two different metrics. ROTI (which in Indonesian means bread… I’ll come back to that). Return On Time Invested. Did...

I’ve been very much into Specification by example in my software development consulting. One of the key learnings for me there is to try to make things concrete earlier. Using specification by example we do this by, for each of the features we’re building, sketching down some concrete examples on how that would work. For example; let’s say that we are building a on-line store and the business rule says Shipping is free for order with 3 items. That’s pretty easy, right? We all have a good opinion on how that rule should be… but is it the same opinion? What I’ve found immensely useful here is to write down some really simple examples. Just to make sure that we understand it the same way. For this business our examples might look like this: Number of items in order Shipping free? 2 No 3 Yes 4 Eeeeh? Yes… or? See…...

When Joakim and I wrote the book we had a chapter on measurement in it, chapter 11 - “Using metrics to guide improvements”. It was intended to show a few ways that metrics can be used in a flow-based process that uses kanban for improvements. When we wrote it I happened to show it to Torbjörn Gyllebring since he’s very sincere in his criticism. His first words: You can't write a word about measurements if you haven't read "How to measure anything" When you have not read that book and writing a lot of words on measurements… hearing that has a bit of a “DOH!”-effect on you and your writing. But Joakim had and that made me feel a little better. I was largely satisfied with the chapter too. But now I have read it and I wanted to share some of the main points that I’ve picked up from...