Why I take the view that putting tasks into an icebox is a dangerous business - in summer as during winter. And what can be done about it.
What is an icebox?
A couple of years ago I overheard some developers, I had the chance to work with at that time, talking about an icebox. It was summer and it was hot and I was like: “Yay, ice cream. Yummy!” The look they gave me made me feel like a little boy again. A stupid little boy. So let us talk about some theory first and then see how that correlates with reality. Now, what is an icebox? (Besides the one where you can find ice cream and cold drinks.)
When starting with Kanban or an agile methodology like Scrum, things are mostly and hopefully new and exciting. Requirements are cut into user stories and tasks. And those tasks are now starting to wander across that new and shiny whiteboard. From the To Do column / row / pipeline / step / whatever-fancy-name-your-scrum-coach-gave-it, to Work in Progress and finally to Done. After a while, most teams figure out, that some sort of testing state makes sense. Fewer teams then realize that the journey of a task won't stop after it is done and add a column named Released. So good, so far.
Sorry for starting with movie references. Again. I promise this was the last for this article. So we have our Kanban board and our tasks. And everything runs great. But then old habits begin to sneak into our new agile world. Customer value sometimes tends to come in disguise. Priorities are not always that easy to decide. And so requirements start to add up. And at some point, somebody had the <zynism>great</zynism> idea to add a place on that whiteboard where all those tasks could find a new temporary home: the icebox.
So, a long story short: an icebox is a list of requests and issues that nobody is going to work on. Low priority tasks, minor bugs. Things, that are requested every now and then but that represent a low value. So, in theory, it is a kind of a parking space for tasks.
There is always that reality
And in theory, this sounds like a good idea. But here comes reality kicking in theory's door. Because let us be honest: in real life that home is not temporary but forever. It is not a parking space, it is a cemetery. Task Sematary. (Remember, when I promised to stop with movie references? Well... sorry!) Those tasks never ever get done. Why? In my experience there are two reasons for that:
So after a while, we have requirements that don't represent that importance anymore they once had. And some years ago it was common for tasks to grow old. Think of all that councils and task groups and management layers such a requirement had to go through. Still has to go through in many companies. Those companies that actually don't feel the pressure to change that hard. And in that case, it is not exactly good, but also not bad to take some time. But in fast moving environments (and these days we see a lot of environments changing) it is deadly. So let me formulate it differently: after a while, we have requirements that don't represent that value anymore that they once had.
An icebox inside an icebox
I guess we all agree that we don't want to have these requirements around our board. But for me, there is a situation that is kind of the same: user stories or tasks inside a backlog. Well, not the same. Even worse. At least an icebox is a sign. Inside a product backlog, those "parked" tasks just add to obscurity. It reduces the maintainability and - more even worse - the transparency of that backlog. (Well, maybe sometimes that is intended. And if it is intended, then an icebox should not be our number one priority.) So we should scan a backlog we have to work with for exactly that user stories. And it does not matter if our role is project manager, or Scrum Master, or Product Owner, or whatever here. Because that user stories represent an icebox inside an icebox. And double pain usually is not a good thing.
How to handle these requirements
I guess it depends a lot on the environment and the team and the culture how such "parked" tasks are handled. A thing that I have made positive experiences with are mold points. Every morning you place a dot sticker on every requirement on your board that has not been pulled during that sprint. You can also mark them with a felt pen. As those points will grow (like mold), you will reach a point (pun intended) where you won't be able to figure out what this task originally was about. And in that very moment, you can remove it from the board.
If you are using a digital equivalent of a Kanban or Scrum board, those mold points obviously won't work. Here you need to make those scruffy tasks transparent. And I know, this is hard work. And it is not easy to be that annoying person who is crashing every daily meeting with "Any news on that requirement?". But in my eyes, it is worth the pain. Because a clean backlog or board will push the effectiveness of a team.
The best for last
So for me, there are two ways to deal with a requirement: either it generates enough (customer) value to have a high enough priority to be done: do it. Else: throw it away.
And here is the only good thing about such an icebox: the "parked" requirements have already been identified and clustered. So you can grab the whole thing and throw it away. Time for an ice cream.
Kanban, Kaizen, Kaikaku, Gemba, Muda, Heijunka, Jidoka, Genchi Gembutsu. Why are so many recent project management buzzwords of Southeast Asian origin? A trend? Of course, yes. But there is more to it than just that.
It used to be that way before. In the 1980s. The older ones can (hopefully) remember. Those who feel old, like me, have experienced the aftereffects of it during their early years. And the millennials among us may know one or the other story. In those years Japanese culture was a huge trend. Why? Japanese producers suddenly were far superior to the western ones in terms of throughput, time-to-market and just-in-time. So much so that at some point even Michael Crichton wrote a book about it. Rising Sun, 1992. (And no, it's not really good.)
And what do throughput, time-to-market, and just-in-time have to do with philosophy?
Let us talk about the mother of all this success. And the mother was two fathers: Eiji Toyoda and Taiichi Ohno. The two have devised and developed the Toyota Production System. Lean Manufacturing has grown from this, which brings us to Kanban via Lean Management. And this Toyota Production System is not a framework, as PMBOK is, for example, but a so-called socio-technical system. So much more than just a guide. After all, the main work of Ohno has the subtitle Beyond Large-Scale Production.
By the way, if any of you get their hands on "Toyota Production System: Beyond Large-Scale Production": be sure to read it! In contrast to Rising Sun, it is really good in my eyes.
Let us take a closer look at a few of those buzzwords
Behind the Toyota Production System, we can find a pretty simple philosophy and mindset. The most famous aspect of it is certainly Muda: the pointless activity, the waste. It is important to avoid it. And as so often: yes, of course, it is. Logically. Unfortunately, it is happening far too rare.
This means that I constantly observe my processes, my entire system and adapt if necessary. And not just me, but all members of an organization, all employees of a company. So this includes flexibility into the system at all levels and - above all - in all places.
And how about "western" culture?
Here it is always the one big hero who saves the day (or the project). Even from the beginning of Western culture: Homer.
And in the 1970s and 1980s, the corporate world looked exactly like this. For most of the time, everything went its usual course of events. Every few years, change was necessary. A big step. And most of the time this one step was a single achievement of legendary project managers. And in those times that was more than enough. Today the world looks different (I know, you all know this). Because some organizations have come to the conclusion that the ones who change fast and more consistently have a competitive advantage. And the tools that have been added to our tool case since the 1990s (keyword digitization) also support this faster and more constant change.
Back to the East
In Far Eastern cultures, things are seen differently. There is this famous study by Richard E. Nisbett and Takahiko Masuda, in which they showed Japanese and Americans short sequences of an underwater film and asked them what they had seen. The Americans described primarily larger, foreground objects, while the Japanese had mostly the big picture in view.
By the way, you can find the article by Richard E. Nisbett on those studies mentioned above here: https://www.pnas.org/content/100/19/11163 - Copyright 2003 National Academy of Sciences.
And I do not want to philosophize about what that says, but I am driving at a very simple fact here: seen from the perspective of project management, in a world where things are changing ever faster and more profoundly - that is, in our world today - such an approach is a huge competitive advantage.
And what now?
Does that mean Far Eastern philosophies and approaches are better suited to project management than our Western ones? No. Yes. Yes and no. (Jein, as we say in Austria - a frankenword of Ja and Nein.) What does "better" mean from a project management perspective? A better framework is a more successful framework. And in our case, philosophies, attitudes, thinking is nothing more than frameworks. My two cents. And in our times when things are changing constantly and, most importantly, fast, frameworks that have that change inside their DNA and so can use that change for leveraging, are certainly the right thing for project management. Or what do you think?
Pictures from Giammarco Boscaro on Unsplash resp. The National Academy of Sciences / Richard E. Nisbett.
Looking over the rim of our project tea cup.
Lately, one is hearing more and more often about Flight Levels. Especially in combination with Kanban. But what is meant by that? And more importantly, how can I use these flight levels for myself? And where do they come from? The latter question is the easiest to answer, so I start with that. There is a gentleman by the name of Klaus Leopold. He is a crazy good (Lean Kanban-)coach. (And no, I do not get any money from him for that statement, but honor to whom credit is due.) And he wrote a book called "Kanban in Practice". And there he formulated the idea of Flight Levels.
And what are these Flight Levels now?
The Flight Levels are the levels on which an organization is working and thinking. And yes, there are thousands and thousands of them. But for the sake of simplicity we are distinguishing three:
And I can hear you, project managers, all shouting, "We've had that for a long time! Project, Program, Portfolio." And at first, I felt the same way. But the Flight Levels are about more than just change. (And yet I think there are a lot of parallels between project-program-portfolio and the three Flight Levels, no question.)
For me, the Flight Levels are meant differently, wider in some parts. Or more precisely in others. I know that contradicts itself. So let us take a closer look at the three.
Just under the clouds - Portfolio Management
Of course, the top Flight Level can also be called portfolio management. But there is also a lot of strategy inside, which I do not necessarily have with Portfolio Management. (OKR - Objectives and Key Results would be the right and hip buzzword here, but I bite it back.)
Klaus Leopold is using the term Strategic Portfolio Management and to me that is actually a pretty good description of what is happening at this level. Here we can find the levels on which strategies are developed and broken down into initiatives (the next upcoming buzzword). So management work, then. In which direction are we evolving? Where are our priorities right now? In which areas do I put my resources?
By the way, all these questions, topics, initiatives are in good hands when we are using a Kanban board. Talking about "visualization of my work". Sure, that seems funny at first glance. Writing the big mammoths on task sheets and move them across a whiteboard. But especially here visualization is actually an incredibly powerful tool.
About busy bees
The first ("lowest") Flight Level can certainly be seen parallel to the term "project". And I deliberately put the word "lowest" in quotation marks, because at this level the actual implementation takes place. But I can not think of a more appropriate word. After all, we are talking about altitudes here.
So projects, but also in a broader context. The headline here, we can not forget that, is Kanban. More run than change, if you like.
Klaus Leopold has a wonderful analogy that I would not want to withhold from you. If every team is responsible for one line of the keyboard and I want them to write a letter, there is nothing in it for me, if a team can press the "S" key really quickly. I need an efficient and effective interaction of the teams. Of course. Unfortunately, this is working far too rarely.
The Golden Mean
The strategy and the daily business (Flight Levels one and three) are pretty well received by most of the organizations I know. We have that under control. Only in between, something is missing pretty often. The level that translates the strategies into tasks. The big, abstract chunks divided into small, concrete work instructions. ("The mediator between the head and the hands must be the heart!", to quote Metropolis). Small companies often find this easier to achieve because a single role can often fill this level. However, this also greatly increases the risk. And at least beyond a certain size of the organization, I have to institutionalize this level.
We know that quite well from project management. There we have our PMO and the program managers who slip into the clothes of this mediator between brain and hands. And that works quite well in most cases. But outside the project world, we can often find a void here. Since the unifying bracket is missing. The second Flight Level precisely. The coordination and interaction between the teams and above all the coordination of the teams to ensure that the right things are being worked on at the right time. And what is often overlooked here: that also means to make sure that new initiatives are not constantly sloshing from top to bottom, but that the first Flight Level can finish work. Here we are talking about Customer Value. And that should be our noble goal.
How can I use this for myself?
In my eyes, Flight Levels are a good analogy, alone because of their name. Altitudes. This pretty well reflects how and where individual organizational units are currently moving. And they come from Kanban county, but for me, the basic idea of the Flight Levels is universally applicable. Or, like Kanban, I can combine them well with other philosophies, methodologies, ideas, approaches. Neither, as PMBOK as big picture and Scrum as a daily business tool exclude themselves (on the contrary, that works really well!), nor do Flight Levels and - again - Scrum. Here we are facing the same situation as everywhere else: some things you just have to try.
Of unpleasant surprises
Imagine yourself managing a project where not a single problem arises during progress. No issues, no uncovered risks, nothing. A nice idea, right? And now reality. Each and every one of us encounters problems and obstacles throughout every single project. Even with the best and most granulated Risk / Impact Probability Chart, we won't have all the risks on the radar. And even if we capture and reduce risks before the project's executing phase starts, over time all kinds of hurdles will be popping up.
Of course, you can handle it in a way that seems very prevalent to me. Just ignore the issues and hope that they will disappear. Funnily (or actually tragically) they never do that by themselves.
Let us have a look at Scrum
Old project stagers have to smile when Scrum Masters are proudly showing their impediment backlogs. Because, even if the average Scrum Coach is trying to tell us that collecting problems that are slowing down the team is an invention of Scrum, such lists have been there since project management exists: Issue Management is the magic word here. Such emerging problems have to be
And most importantly, they have to be managed. As always and everywhere in project management: it needs someone to take care for. Someone who is collecting and maintaining these issues. But which format is the right one for such an issue list?
Let's take a closer look at the Impediment Backlog format. Because we can find several takeaways there. But first things first, what is that? An Impediment Backlog is a document (analog or digital) in which a Scrum Master captures all the stones that are in the way of the team and that have to be cleared away. These are usually collected during the Daily - the brief meeting during mornings where everyone tells what was done yesterday, what's going to happen today, and what's stopping them from being productive (or even more productive).
Many small stones are cleared away easier than a big one
And here we can notice something. Such a Scrum Master does not (only) project work, but also a lot of operational work. Daily business. Of course inside a project environment. And, of course, the border is indistinct and depends a lot on people, phases and, above all, needs. But such an Impediment Backlog is mostly consisting of "small" problems. Issues at the daily business level. We won't find many huge - and huge means insoluble in that form - chunks there. In other words, in such an Impediment Backlog we have many issues that we can get rid of very quickly and easily. Many small stones are cleared away easier than a big one.
Prioritization is half the battle...
Another big advantage of such an Impediment Backlog is that it is not just a list, but a backlog - that is, a prioritized list. The most important - in our case the most serious - problem is always to be found at the top. This helps me to help my team. The issue that bothers them the most is the one I am going to tackle first.
..and clarified responsibilities are the second half
And such an Impediment Backlog is also a very elegant and easy solution for responsibilities: the Scrum Master is responsible for all the impediments that are on the backlog. No RACI matrix, no pushing around and no denying. There is one person and that one takes care. This does not mean we can not delegate topics that are on the list. But the responsibility should lie with the project management.
That may seem out of place at first glance. Why should we, as project managers, carry the can for other people? But we are talking about issues here. These are either risks that have become alive or even problems that have arisen unexpectedly. In my opinion, we are facing a roof that is on fire in that case. And the solving of such issues should be a particular concern for project leaders. But you all see it that way, right? And so it is only fair that we have the responsibility for resolving the impediments in our own backlog. My two cents.
Where there is light, there is also shadow
That sounds almost too good to be true. And in my experience, Impediment Backlogs also have some weaknesses. Or to be more precise, their handling has. I often see well-behaved Scrum Masters who are writing down all of the topics their team tells them about. In fine writing, with a box to tick it off. And then they grab all of their colorful marker pens and start drawing circles around and lines between those list items. In my opinion, impediments (or issues in our case) are tackled the moment we hear about them. They are far too important not to start immediately. Only when I have to wait for something - that is, a dependency - the issue becomes part of the backlog.
"Open your eyes, open your ears, Helmi is here"
Back in my childhood days (a long time ago) there was a television series in Austria called Helmi, which had the purpose to teach us careless children the responsible use of the traffic regulations. And in the show's title song, it said, "Open your eyes, open your ears, Helmi is here." And we should all take that to heart. Even if my team is holding a Standup Meeting where they are talking about any stones in their way every single day. Who says that they really are thinking of every single one? And who tells me that an issue does not show up two minutes after the meeting ends? So we should always keep at least one ear on the team.
And an important notice (a point that is discreetly concealed in the Scrum Guide). We should not ignore the distinction between issues and risks just because one is using an Impediment Backlog. Even if the two words are used quite synonymously. But a risk has no business on an issue list or in an Impediment Backlog! For risks we have our good old Risk Management, all with plan, identify, analyze, execute, and so on. Only when a risk becomes alive it becomes an issue.
Maybe we project managers should include the term Impediment Backlog in our vocabulary. Such a prioritized listing of all issues that are blocking our team - and thus jeopardizing our entire project - and that we can (gradually) work off is a valuable tool for our daily project work. Because even without such a list it is already complicated enough.
Four points, that make the difference between a good and a really good presentation. (And no, that's not me in the picture.)
We project workers spend a lot of time communicating. According to the PMBOK Guide between 75 and 90 percent. Half of this time we spend with (hopefully) active listening. The other half we are presenting, lecturing, and telling different people different things. In short, we are transporting information. And in my opinion, it is incredibly important not to transport just some thing, but the right thing. I know, right now I am sounding like a motivational poster. Na no na ned, as we say in Austria - of course. Of course, we do not communicate just something somehow. Nevertheless, I can see exactly that pretty often. But what is the essence of a good presentation?
..the nitty-gritty is less the way of presenting, but rather the content of the presentation. And yet, I am regularly seeing people standing on a stage and rattling off their NLP-Hocus Pocus. Cheap trick, so to speak. What is the talk about? Who cares. It is all right as long as the audience is mesmerized by all those sleight-of-hand tricks. Only, the audience does care. They want to hear some content.
Junior Woodchucks camp
It does not matter if someone is one of those people who are moving in with a stack of moderation cards, or - like me, I admit it - to those who prefer to conduct their presentations on the fly. In any case, there is one particular secret behind a good presentation: an incredibly intensive preparation. I'm not talking about the presentation itself, but about the topic. How can I tell others about a topic, if I am not having a good grasp of it? Not at all, in my eyes. It is necessary to know more than my listeners. Otherwise, such a lecture is a waste of time for all involved.
Walk like a duck, quack like a duck
The next duck-heading, I'm sorry, I can not help it. But it just fits too well. Let us switch the meaning of this witticism: if I wade like a duck, I will quack like one. That means, you should, and you have to pay attention to a proper posture in your presentations and moderation. Why. Two reasons:
"Here's looking at you, kid!"
Finally, our headlines are leaving Duckburg. My last point is a realization. When you are standing in front of a group of people and give a lecture, there are many faces. So virtually a 1 to n relationship. But turn the situation around. If you are one of those people in that group, technically it is still a 1 to n relationship, but for you, it feels like a 1 to 1 relationship at that moment.
Regarding that there are so few points that make the difference between a good and a bad presentation, I've already written way too much. So here is my crisp summary:
And I know, those points alone do not make a good presentation. But for me, they are the basis for one. Because without these four points, it will definitely be a not-so-good presentation. And unfortunately, there are far too many of those. But that is another topic.