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.Read on ...
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.Read on ...
“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 in particular common among developers I’ve noticed, and even more so in teams that have been under a lot of pressure since they never got around to
fixing that thing that we got promised to do 4 months ago….
I wanted to share just a thought about this that has proven helpful for some of those teams that I had the opportunity to talk to.Read on ...
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.Read on ...
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, but many people seem to have the PO outside the team as an ordering function. For me, the PO is the one that maximizes the customer value, prioritize the backlog but also helps the team to reach their full potential.
Well… that was a very thoughtful and great question. Thank you for asking me. I’ll try to match the question with an answer at the same level.Read on ...
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.Read on ...
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.
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.
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.Read on ...
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 #backlog— Marcus Hammarberg (@marcusoftnet) January 23, 2018
99 tickets of work
Take 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 says
98 tickets of work left in the backlog
15 minutes spent #agile
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.Read on ...
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!Read on ...
When I started my blog, almost 12 years ago, I often wrote posts of things that I would need to look up again. Sure enough, I sometimes stumble into my own posts when searching for solutions to problems I have.
This post is one of those posts. I was asked to conduct a survey throughout our department and needed to do some slicing and dicing of the stats. I used Google Forms to collect the data and then did the analysis in Google Sheets.
It all came out pretty nice and allowed people throughout the department to drill down into the data in a quick and simple way.Read on ...
The other day a co-worker (Anders - awesome guy!) pointed me to a change management tool/methodology called Viral Change. I read about it and got quite hooked I have to say, but I’m not yet ready to make a report on how it works or it’s merited.
However, in one of the documents I read they made a little remark that I found very interesting as it brushes on many of the problems that I often have when trying to “do” agile or change into agile.
This post is about that but I have to give a little backstory and my current understanding of Viral Change.Read on ...
I’ve just read a classic. Mark my words - we will mention, refer to and hear a lot about Mark Schwartz great book “A seat at the table”.
It’s an amazing book - you have to read it.Read on ...
Writing a book (psst - there’s another one on its way) has changed many things for me and opens so many doors in my career. But my favorite thing is when I get to talk to people that have read my book, learned something and is applying kanban in their everyday life. Sometimes I get some really insightful and interesting questions.
Massimiliano Spolverini, for example, presented me with one of those questions just the other days:
I have been reading your book the second time and I have found it brill. Though, there is a doubt playing on my mind which I cannot sort out.
The 2nd rule of thumb to find a WIP limit (page 111) explains that when the WIP is set too high, then the team can see some work items not being worked by anybody, which no one is responsible for.
On the other side, at the bottom of page 117, when the “Drop down and give me 20” approach is presented, it is said that “…if too many work items are idle, you can go back up to the level you had before”. In other words, it says that if one sees idle work items, he’d better move back to higher WIP. Isn’t this last statement in contradiction with the 2nd rule of thumb?
Massimiliano kindly let me answer the question on this blog and in this post I wanted to share some of my thinking about this situation. I don’t claim to hold a one-and-only-answer but rather wanted to explain and expand a bit further.Read on ...
When I do workshops on kanban/lean I
often always include a game, since I think that adds to the experience of the principles I try to teach. One of my favourite is the Number Counting game that I, one very boring day did an animation of in PowerPoint. You can flip through it here:
This game very clearly illustrates the benefits of limiting work in process as the lead time for all the projects goes way down, as well as the lead time for each individual project. While quality often improves.
However, every time I’ve done this exercise I have to resist the urge to throw in a couple of curve balls and changes. I resist it because I think it would be quite hard work and stressful. Now I’ve tested them on myself and I wanted to share the outcomes with you.Read on ...
I had the opportunity to test my teaching skills to the max, as I got the question if I could come to my son Alberts class, to teach “some programming”. I have taught TDD to kids before, see this long video for the result. But those kids were 3-4 years old.
Adding to the challenge was that this was my own sons class and I felt that I had to make him proud as well as fight a bit for being heard.
I took on the challenge and it went well, but I thought I’d share some of my preparation and experiences. A few people have asked me privately and I realize that this is a request that many of us in the IT business might get. If you read this you can avoid my problems at least.Read on ...
The good people at Kanbanize invited me to write a guest post on their blog. I accepted and wrote a post on tracking and learning from Queue Length, a topic I picked up from Donald Reinertsen excellent book Principles of Product Development Flow.
Go over there and read the post - I’m happy how it turned out.
The rest of this post will be very meta… because it will be about how I can write the post on short queue length fast, by having short queue length.Read on ...
I agreed to do something a little bit scary, a couple of weeks back. And then it got even more interesting as new information unfolded.
My task was to facilitate a retrospective with 5-6 managers across our organization. That was a bit scary - but then I realized that they all were going to be remote. I had never done a remote retrospective before so that made it more interesting.
I didn’t do anything particularly revolutionary, but I was happy with the outcome and the format. You might find this useful too - so I thought I’d share it here.Read on ...
I’ve worked in a few places that have had hack weeks or hack days; a simple little thing where the whole company stops for a while and get to spend some time making something that you’re really passionate about.
This was first made famous by Google and their Google Time that have produced amazing products like Google Earth and Gmail. (That linked article, by the way, is showing my point of this post with painful clarity)
At every place that has had this kind of opportunities and practices I’ve also seen people skipping those days, because:
That’s dangerous. Those silly habits are what is building your culture. Without that (where hack week is just an example) you are not you anymore.Read on ...
Every other day I meet people and organisation that says something along the line of
We’re doing agile for some of our work, but other needs waterfall.
I’m getting increasingly annoyed with that statement. Waterfall (phases with big batches of work) is always wrong. You should get out of that thinking as fast as possible.
Any agile person reading this will not believe it. But believe it. Waterfall is very much alive and being hailed in
most many organisations today, in my experience. Especially on the business side of things.