I had a colleague on one of my gigs many years ago, let’s call him Olle (since that was his name). Olle just got a blood pressure meter for Christmas. He was around 45, at the time, and in reasonably good health, according to himself. But he was one of those guys that “had everything” and someone got him this machine. Mostly for fun.
Now, as he as a gadget geek he loved this new toy and of course started to use it. And he kept records in Excel. A few weeks after he started to track his health, to his horror he saw that he was getting worse by the day he measured.
Now, at the time when he told me this, he just started to measure 3-4 times a day and the result were not promising; his blood pressure was through the roof.
He had a doctors appointment later that afternoon to get proper medication.
I think I’m becoming Olle. And it’s https://www.atlassian.com/software/jira fault. And mine own. Mostly my own.Read on ...
Scrum was my first love in agile. I still remember the revolution and excitement I felt after the Scrum Master course and when I and my colleague Öystein started our first Scrum team. It was awesome!
Later I moved on to more flow based approaches when I ended up in environments where Scrum was not a great fit with it s iterations and locked down scope.
Scrum and I was far away from a time. There are no hard feelings but we just don’t hang around much anymore.
I saw someone tweet something like;
I feel like many people talking about Scrum doesn’t really know what it’s about. Really.
Something like that. I felt that it was about me. So I decided to read the official Scrum guide and take some notes. They are summarized in this post.Read on ...
In 2013 I got invited to write blog posts for CodeBetter.com. I was quite surprised and honoured, since that’s a place where I’ve read many great posts over the year.
I hopped to the challenge though (never regretted doing that) and ended up writing 6 posts, before I lost tempo.
I’m actually proud of all those posts and wanted to preserve them here on my site also. I noticed that CodeBetter.com has slowed down and went away completely the other week without anyone noticing. So I thought it would be better to save them somewhere else.
Here’s they are:Read on ...
A couple of months ago I was very fortunate to work alongside a great team. They had a not so envious task before them, namely to introduce a new main concept into an legacy code base. You know, the code has been around for at least 5 years and now you need to add a concept that was no-one ever thought we would have in there.
They did that. In just 3-4 months and delivered with flying colours. I didn’t have much to do with that, I merely observed their work.
When they were done I proudly introduced the team to a new senior in the company and told him about their feat and how they had gone about doing it. His words: well, that’s Lean backwards then.
He was right, but I never thought about it until then. In this post I’ll describe how they worked, what the “lean” way would have looked like and what we can learn from the difference.
Let me just say that the way the team went about their worked, and the feature was a success in production. Very high quality (2 bugs reported if I’m not mistaken) and well received. In order to not put any blame on that great team I will talk about “we” in this post. Although I didn’t have much to do with their success.Read on ...
When our board is lined up as our process it’s quite often an array of columns starting to the left when the idea first comes into mind (or in a backlog column) continuing down our workflow, adding more and more value until it reaches our customers where we can learn from the usage of our new feature.
Although it could be tempting to go through the columns from left to right in our morning meeting, I would suggest that you consider doing the opposite.
My job is to help clients to use and adapt the principles of lean and agile to achieve a better flow of value. Sometimes I get questions from friends and old clients about how to do specific things. And sometimes I get questions from complete strangers.
Last Tuesday was such a day when Emily reached out via email and asked me three insightful questions.
I was happy to do that and my “fee” was that I can publish the questions and my answers here on the blog. So you’re reading my paymentRead on ...
Many daily stand up meetings follow the patterns originally from Scrum - that is we ask each individual what they did yesterday, what they are going to do today and if anything is blocking them.
This is a nice sentiment but misalign our focus.
Because making sure that people are busy is not important… at least not compared to making work flow.
There’s an easy way to change our focus, at least in our morning meetings.
When kanban first came into common use and practice it was often posed as an alternative to Scrum. Well, as Torbjörn Gyllebring told us many years ago, kanban is not your process. Kanban is a process improvement tool and works on whatever process you apply it to. It’s one of the powers of the tool and the reason I like kanban so much.
However, for many early adopters of kanban, removing the cermonies of Scrum sometimes went overboard and we removed everything that constrained us and made us make tradeoffs. Kanban - love it! No planning, no sprints, no constraints - it’s just our board and work flows as fast as it flows… Nice!
Well - it’s not really a kanban board if you don’t have a work in process limit. Let me explain a bit further.
One of the things that always catches my attention when I walk past a board is the colours of the stickies. Why? Because colours requests our attention and can help us in understanding more about a thing. Red is naturally a warning (in western culture at least), green feels ok, etc.
This is why I get troubled when I hear that the reason that we have chosen the colours of the stickies on our board is “because we took the ones that was closest to us”.
That is sad and I share a few thoughts on how to improve on that state of mind - it’s easy.
This comment is closely related to the comment about columns. In this post I’m more specifically want to talk about the “Done”-column. The last column on most boards. I’m on a crusade to rename Done all over the world.
Let’s do it! Done-column - you’re going down!Read on ...
Ok, got a few encouraging comments on the first post so I’ll continue this series. If for nothing else it’s keeping to my orignal blog-idea to write things down to clear it up for me and not forget about it.
This time I wanted to talk about the column themselves, or maybe I dare to talk about the process they reflect. Our process for work!Read on ...
It’s very interesting to see how a practice goes from a nice idea to best practice and over to tradition. In my community, the software industry, things move very fast so I’ve seen many examples of this; simple things like formatting of code, background colors of editor all the way to architectural patterns - all of these become default usages and tradition, and sometime “the way it’s done”. Sometimes people calls it cargo cult which refers to that I often do things without really reflecting over why.
When it comes to my field of practice; lean and agile there’s bountyful examples of cargo culting, but in this series of post I wanted to examine a few very practical things that I often notices on how agile team uses their boards.
It will be a little hit-list of my pet issues commonly found on agile/kanban-boards I’ve seen.Read on ...
Scope creep is a common phenomenon in software development where the size and workload increases beyond what we first envisioned. In many cases this is so small that it happens without anyone really noticing but sometimes it can degenerate and slow down progress considerably. Sometimes even stopping a progress or team completely.
Scope creep comes from many sources, sometimes from the outside, but I think that the most common one are ourselves:
That value should probably be a configuration property…
What if someone decides to change database server…
This is of course good questions to ask and could be value, but I think there’s more value in getting a feature in front of users and learn about their behavior and how the feature is doing. After that we can harden it, make it more flexible or otherwise improve it.
Drifting away from my main topic… So now you’ve experienced scope creep too and how easy it is to fall into. See what I did there ^^
On a more serious note - this post is really about how I’ve seen scope creep being visualised and managed by a few teams on their board.Read on ...
The other day I heard someone distinguish between a few roles that I take on from time to other. I’ve never made the different between those roles clear to myself and as a consequence I end up doing them all at the same time, in my consulting.
This can sometimes be confusing for me, and my clients but makes me also ineffective in the role I’m trying - or is expected to play. I actually wrote about this in a post a few years ago - without really knowing what kind of problem I was addressing.
In this post I wanted to share a few thoughts on these different roles and hopefullyRead on ...
Sometimes I get the opportunity to try things that I never done before, or didn’t think that I would dare. Do those things if you get the chance. Always do them! I never regretted taking one of those opportunities, after they are over.
In this case I got the opportunity to talk with a bunch of school kids (14-16 year olds) about Lean, experimenting and how to iterate ever faster by improving your process. It was quite the experience and I wanted to share some highlights of the time I had together with them.Read on ...
For the record I still think it’s a great event and every time we have run it we have come out the other end in a more aligned, enlightened and excited state than when we went in. And for the record I still think it’s just a phase in our process improvement that we should move away from, in a suitable pace.
I’ve been running 3 or 4 big room planning sessions now and I’m starting to see pattern of what bites us the most and what is the foundation of being successful in these session.
In this post I wanted to share the top 3-4 (there might be few slipping in there) things that I’ve found paramount in order to have a great planning session worth the time and effort.Read on ...
I’m very proud of my church (or corps as we say in the Salvation Army - the Vasa Corps of Stockholm. The moment I came there I felt right at home and I’m more than happy to, voluntary, spend a lot of my leisure time in the different groups of the church.
About a month ago I heard someone, that is new to our congregation, say something that summarised a lot of the spirit in the church:
Here people are saying kind things about each other
That did not only make me feel very proud and happy, but also signals a culture that holds true for many of the great place I’ve been working in or associated with.Read on ...
A daily stand-up is a really common and very good practice among many agile teams.
It was popularized by Scrum but is very useful in almost any setting.
Over the last 4-5 years I’ve seen how many of the initial practices and recommendation have change a bit. For me the primary factor for these changes has been the focus on flow.
In this post I wanted to share a few of the things I’ve seen changed and also a reason as to why. There’s a sentence in this post that (almost) got me fired … so this will be valuable for us all, so that we don’t end up in that situation again.Read on ...
The other week I saw the most amazing transformation of a person I’ve seen in a few years. The number one spot is taken by Ibu Elsye.
As many of the other times I’ve seen changes like these I realize that the transformation, as well as the state before and after, are solely (not largely, but solely) created by the system we create for people.
I’ll elaborate on that as soon as I’ve described the change that I saw.Read on ...
We had a process improvement discussion the other day in one team I’m working with now and we realized that we were actually would slow down our process a bit now, but in the long run gain flow.
I asked the team to design their work to help us flow better, but it would of course, initially increase, the workload. Basically we would increase work in process, which of course felt strange for everyone, not at least me… since I was the one recommended.
In this post I wanted to explain why this can sometimes be a good idea and hopefully give you some ideas as to when this can be a useful option.Read on ...