Viral Change and some thoughts about tools
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 ...Review of A seat at the table
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 ...Limiting WIP and some rules of thumb
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 ...Lean/flow simulation experiments
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 ...TDD for 9 year olds - an experiment in teaching my sons class
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 ...A post on the post on queue length
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 ...My first all-remote retrospective
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 ...Don't skip hack days - that silly habit is what you are
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:
- We are too busy
- Well, that’s cute - but this real work needs to happen now.
- Not this week, but next.
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 ...No - waterfall is not sometimes correct. It is always wrong
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.
Report writing - using impact maps, Stephen Covey and increments
I had one of the more intense writing sessions in my life the other day - getting about 17 pages and 6000 words out in 2,5 hours. But that’s not as important, although fun, compared to the quality and how we did it.
I’d been coaching and teaching at a company for 4 days straight, meeting ca 200 people from 12-15 teams to talk about their opportunities and challenges to apply agile and lean thinking within their current context and organization.
The obvious question on the last day was:
Could you just summarise your thoughts for us? Write some ideas for improvements and next step and stuff.
So we did. And I heard that the report was well received (hence I presume the quality was adequate), but in this post, I wanted to talk a little bit how we worked to get this down, and why that helped us (me) to write a better report/message.
Read on ...The kanban blessing
This week have been a long list of firsts for me, as I have been in China (1st time) and done a full week of training and coaching at a remote client (1st) and also been away from my family for a pro-longed week (sadly not first but seldom).
I have also signed a lot of books (1st) and I started to come up with some small sentences of wishing good luck and success for the people I signed the book for. Putting them all together they became a nice blessing for people using kanban and lean thinking in their work life. Ah, well others too, of course but they would discover the value of my wishes through some pain.
Read on ...When we used user story mapping to plan our move
User story mapping is a very powerful tool by Jeff Patton and I have used it many times in IT context. With a user story map you list the steps of a user journey in your system on top and then list out the details of each of these steps below (see the picture below because this explaination doesn’t really give the tool justice).
This is awesome but one of the things that I always gets hanged up on when doing this is the incremental part of fleshing out the details.
I wanted to share one situaton when we created an user story map for a very non-IT situation and I learned a bit on what incremental means.
Read on ...Two stories I often tell on WIP as a process improvement tool
Work in process (WIP) limits is a powerful, lightweight tool to not only improve your process flow but also to find further improvements in your process. I consider it widly underused but hugely impactful.
Often when WIP limits are introduced we miss the point of them being the driver for further process improvement, but rather focus on what our WIP limit should be, or how we are going visualize it on our board. So I often share a story on how that can work.
I realize that I’m turing into an old man… I have, for many years now, being telling and retelling the same story so many times that people around me don’t stop me anymore.
At the same time I sometimes forget some of those stories. So I thought I’d better write them down before I lose it altogher.
Read on ...My obsession with teams
I love working in teams, when I get the chance. There are a few teams that I’ve been in that still lives vividly in my mind. The way you feel togetherness and trust in teams are awesome.
But lately a thought has slipped into my mind; are teams always the best grouping of people to complete a task? What if I’m in more than one team? What kind of team feeling will that give me and the others in the team? What is a number one team?
And; just writing this post feels like blasphemy after 12+ years of promoting teams as the optimal way to work together.
Just to be clear - I still think it’s awesome, but maybe not always best for the situation at hand. </storm of angry comments from agile people avoided>
What I learned coaching a car dealership on stage
A year ago I had the great pleasure of speaking at the inaugural Agile Islands. Åland (as it’s written in Swedish) is a small group of islands between Sweden and Finland. It’s kind of independent but a part of Finland. They speak Swedish with the most beautiful accent you can imagine.
The reason there’s an agile conference in a society of about 29000 people (two stop lights on the entire island) is that they want to make the whole society aware and using agile practices. Sharing and cooperating around agile methods is one of the ways that they actually can compete and be attractive. It’s a very inspiring and lofty goal
Now I got invited back. The last year was a kick-off for agile practices (even some articles in the news there) and it left people wondering;
This all sounds awesome - but how do I get started
Agile Islands now asked me if I would be willing to help a company get started with agile. Zebrabil - a car dealership of 7 people. On stage in front of others. In 3 hours.
That sounded super scary and challenging, so I naturally accepted. I learned a lot by doing this and I wanted to share a few things.
Read on ...Teams are immutable structures
Sometimes in my consultancy the soft “people ware” thinking can borrow ideas from the harder “software” concepts. I want to relate such an idea that I cannot get out of my head:
Teams are immutable structures
I found this very useful to describe some of the unique traits of a team, that is often hard to grasp; such as estimates cannot be compared between teams or that changing teams around to opitmize resources utilization is sub-optimization in more ways than one.
But first, there’s a strange word in there. Two, actually!
Read on ...Deploy and release
Today I got a call from a friend that works in a big organisation. A bank with very old fashion and rigid processes for how software is handled and released.
Needless to say my friend ran into a wall of pain and trouble as he tries to introduce agile values of small things moving quickly though the value chain. Specifically the client was reluctant to release until everything is completely done - otherwise there's no value at all.
An old trick came to mind as I tried to help him with his conundrum:
Read on ...There’s a difference between deploy and release
Values to guide us
I think I’m not a fan of best practices. For me, best practices are limiting us to be only as good as the practice. Admittedly, that can be pretty good - but I’m looking to become better than I ever thought possible.
Also, as I’m a guy that make my living trying to teach people (often) practices, I have to make another disclaimer; best practices can be inspirations for us to build upon. However, I often see companies and teams instead of focusing on implementing the practice.
Nowadays, what I’m looking for is the principle that led to that practice. And even better; what are the values that pushed us to those principles.
In this post, I wanted to mention a couple of good examples of when values can move teams, organizations, and complete communities forward to a place that no one would have imagined or reached should we had followed some best practices.
Read on ...Counting words
I got the bash-programming bug. Lately I’ve been almost making up excuses to dive into another script. For example; the book I’m writing now is closing into an end. So I thought to myself; wonder how many words there are in there.
And the little programmer inside me just shouted out:
That’s a script!
In this post I will try to explain how the script that counts all the words in a bunch of word documents.
Read on ...From push to pull - the essence of kanban
I have been working with a team now for close to 6 months. It’s the same old story; team has a lot of very important things to do from 4-5 different stakeholders around the company, team try to keep up, stakeholders around them get upset with the slow progress on the “features”, team struggles under a lot of tech debt that team postponed earlier to get faster progress on the “features”.
If you’ve been in any larger IT organisation the last 20 years, you know this story. Your basic “hard-working, well-intending, trying to cope with the demand from the organisation”-development team.
What I’ve found fascinating with this team, except that the engineers are amazing developers, is that the whole team feels trap. I’ve asked them numerous times to cut down on work in process (WIP) or cutting items into smaller pieces. Every time I’ve got confused looks and people say things like:
But it’s already on our backlog. We cannot do anything about that.
The other day we tried to do something about this and in doing that we found a key principle from lean that was missing here. We also discovered two different aspects of planning that helped us to sort this up.
In this post, I wanted to share what I learned about these principles and ideas. And show what we did. There’s nothing earthshattering here. It’s just kanban in action and some lean thinking.
Read on ...