Thoughts on minimum viable products and riskiest assumption tests.
Always these misunderstandings
Some of you surely know this drawing by Henrik Kniberg on the subject of minimum viable products. (By the way, Henrik is a software developer for the best-selling video game of all time - Minecraft. Just to make sure we are collecting enough useless knowledge here too.) And in itself, and in theory this MVP is not such a bad idea. But as so often, when our beloved scrum-agility-buzzword-coaches are involved, it is turning into one big misunderstanding at the end. And as so often, there is an alternative that is actually more suitable to produce iterative and incremental products: riskiest assumption tests, short RAT. Those who mainly care about sounding competent should incorporate the term "RAT" as often as possible into their sentences in the near future before it is becoming the next big buzzword and can otherwise stop reading now. All others are going to learn more in the next paragraphs. You are still all aboard? Very nice!
Minimum Viable Product
Before we talk about beautiful shiny new things, we should ensure that we are all on the same level. What is an MVP? I don't want to be a smartass (pardon my French!) here, but I have seen teams dashing against exactly this question because no one has thought about the literal meaning of the phrase. The MVP is the "minimal survivable product". The idea behind it is quickly explained. The phrase was coined in 2001 by Frank Robinson, who, inspired by the bursting dot-com bubble shortly before and based on the Sharp Ratio - simplified, a return-on-risk analysis - has thought about how to give his customers a product which has just enough features to be viable. So maximum profit with minimum risk.
And what is the suboptimal part of such an MVP now?
The idea per se is, as I said, not bad - quite the contrary! But even its inventor says about the concept of the MVP:
"Too large or too small a product are big problems. The MVP is the difficult-to-determine sweet spot between them. Teams flounder tactically in trying to determine the MVP." - Frank Robinson
So as so often the implementation is the problem. The misconception that the MVP is the minimal variant of a product. Quite simply dashed off. And not enough, I often see organizations slipping into the Product Death Cycle attempting to work after the idea of an MVP.
And even if the implementation should work. Even if the mindset is recognized and lived as such, the MVP often does not really work. Because such a minimum viable product is poor in features by definition. This is not a big problem for new products. But in 99,999...% of cases we are in areas where there is competition. And in the long run, the product with the most sensible features and the highest quality prevails. And not the MVP.
The road to Riskiest Assumption Tests
Especially software developers have quickly come to the conclusion that the MVP is indeed a great concept, but just has its weaknesses. So they tried to develop the idea of an MVP further. Entrance Minimum Viable Experiment. The MVE takes an MVP to evaluate a product idea. True to the premise, "Nobody expects an experiment to be a complete success." That sounds complicated at first sight, and at second sight one notices that the MVE is nothing but the good old banana principle.
I see RATs.
So, Riskiest Assumption Tests. RATs. I do not know if Rik Higham invented the concept, but he was the first I heard speaking about it. Rik is asking a simple question:
"What's the smallest experiment you can do to test your biggest assumption?"
When you are building a new product, you have to start with a whole bunch of assumptions. We project workers even have our own tool for that, the Assumptions Log. The big disadvantage of such assumptions is that you just do not know anything about it. Of course. So you take the assumption that carries the greatest risk for you and test it. Without much effort, just as easy as possible. Test early instead of Fail early so to speak. (That should be printed on t-shirts, I know.)
That is, I build a product that just tests my assumption. Quick, easy, and inexpensive. Need an example? Google Glass. Such smart glasses are an incredibly complicated and, above all, complex thing. Not just the technology, but also the whole surrounding environment. Legal, cultural, social. What do you think, how long did it take to get the first Google Glass prototype ready? I tell you: one day. 1 day. (By the way, Tom Chi is the courageous product developer in this case.) And yes, we are very close to rapid prototyping here and we should take rapid prototyping as a role model more often I think. If you have an idea, but you are not sure if it is going to work, just quickly tweak something together and test your assumptions.
Is MVP a bad approach now?
No. At least not if it is interpreted and lived correctly - as a mindset in product development. And, if you choose a strategic approach. I think a variant like this might be a good idea:
When I do this and listen to my customers, I will have created my MVP in one of the first sprints. You notice, this is not a thing that you have done quickly in one refinement. This is hard (product development-)work.
And here riskiest assumption tests are a good alternative if I want to quickly and efficiently test my assumptions. Just dare it more often.
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.
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.
What agility has to do with (much) efficiency and (often not so much) customer value, and why cookies are not always the right choice.
“Come to the dark side. We have cookies.”
First things first: I am seeing today's topic through the eyes of project management. And through that lens agility is a great idea. But what exactly is the great thing about it? Why do many people and organizations embrace "agility"? Because it is different. Another approach to getting things done. A different approach than the way many organizations are using. Because let us be honest. Even today, there is still an incredible number of companies whose leadership firmly believes that C2 - Command, and Control - is the best way to have a productive and thriving business. And if you are part of such an encrusted, sedated structure, an agile approach sounds great. Of course, it does. Daring though, but very tempting. Faster decisions, faster work-done, less time-to-market. Different.
I hate to be the naysayer again. But what is the dark side of an agile approach? And let us just ignore the arguments that I am hearing from a certain type of software developer over and over again ("Agility is bad because I've done well without agility for 20 years. That was a great time! We didn't bother about those customers and we spent every night fixing bugs.") - so, quotes, arguments, quotes. But I am sure you all have heard this a couple of times.
Not every company is manufacturing software
Agile methods have an insanely strong focus on software development. Yes, it is getting better. But whether if it is ASD, Scrum, DSDM, or - God forbid! - SAFe. In their origins, some of these methods were developed by programmers and most definitely had programmers in mind. And even the agile manifesto is still officially called Manifesto for Agile Software Development. And where do we see agile methods introduced in companies? In my observation, in the overwhelming majority of cases, it is the IT department or more specifically software development.
But what happens, when the IT is working and thinking agile, but the remaining 95% of my value chain is not? Chaos at the interfaces. And yes, Kanban can help a lot. But - and now I have to be careful - in my eyes (and the eyes of many others), Kanban is not part of the agile world. It is more Lean Management. Similar matter altogether, but another. Matter altogether. And yes, your magic-agility-coach told you otherwise, I know.
Kaizen and a steady improvement in small steps are fine and dandy. But every now and then it just takes a bit of Kaikaku. The big time. And I won't be able to achieve that if I am spending my time thinking in User Stories. Because that is contagious. And even if the strategy on the top level is good - the best strategy won't help me if the visions get shredded beyond recognition on their way to the implementation level. But that is what I am observing in many organizations that switch to agility: a rigid set of rules is replaced by another rigid set of rules. And then all are writing small User Stories and eventually everyone is thinking small. Good as gold. However, I will not experience any movement.
Standstill through prioritization
Agile methods live from constant prioritization. But, if only the currently most important things are implemented - who will take care of the right things? Those who may not be the most important at the current situation and time (and in my little world), but on a larger, more global scale. They fall by the wayside. And that is how I slow down my organization enormously in the long term. And at some point, I arrive back from where I started: Standstill. Standstill through prioritization.
Efficiency is not always the same as customer value
Agility creates teams that are maximally efficient. This pleases management and controlling. Agility thus also creates teams that have completely lost sight of the customer value. And that is also my main criticism of the way agile methods are often interpreted and lived.
But why is the customer value neglected? One word: velocity. At some point, teams only have this number in their heads. The average Story Points done per Sprint. The team's pace. And everything is subordinated to this team's pace. People will not rely on their own gut feeling. How much work I can accomplish as a team in the next few weeks. No, people are calculating. Because the Scrum Guide says so. (And here we are again with rigid systems.) So everyone is drawing down the line on their burn-down chart. How many Story Points have they done today? Rather than talking about what value has been generated for the customer. Instead of talking about how they have supported and advanced their own organization today. And many Scrum Masters participate in this madness, without even questioning it once. Because the Scrum Guide says so. (And yes, I'm just cynical and unfair now, I'm sorry!)
So what does that all mean?
What can I do better when talking about the above points? How can I avoid the negative and reinforce the positive?
The most important thing first. If I want to change my organization, I should consider whether agile project management methods are generally the right ones for the change part (ie the projects). If I am not better off looking from project to project - where am I on the complexity matrix? - and then deciding which approach to choose. Predictive, incremental, iterative, whatever.
All in all, agility is certainly a good thing - as long as I am using it for the right problems. And it's not outdated (even if agile project management methods are much older than the trend would have us believe). But maybe there is no one-size-fits-all when it comes to project management. And so maybe it is time for something new again. This time, not something different, but something better.
Agility and why some organizations fail. A train of thought.