Space–The Final Frontier

When we bought our house, we designated one of the rooms as “ the computer room”. It was kind of small office, with a couple of book shelves. Then, with the children, we’ve added more cupboards and shelves and computers. It was no longer the computer room, it was a storage room.

“Where is X?” X is found most of the time at the storage room.

And boy, we’ve gathered a lot of Xs. Because once you have space, the decision of keeping or getting rid of something, doesn’t even come up. When it does, the answer is usually “well, maybe someone will need it someday”. And we keep it. As we keep oodles of Xs and Ys.

There’s something magical about storage room: It may be limited, but seems to have infinite volume. There’s a lot of stuff in it, but I probably won’t be able to find any of it. With all the mess, things stacked on top of each other, papers to shred and/or sort out, cables of all types that I just may need one day, I know that if I need something it’s probably easier to buy,  rather than search for it.

In knowledge work, we usually keep stuff in virtual places. And there’s no limit to those.

For years I’ve worked with different bug reporting systems. Those things have infinite space. So it’s makes sense we should document every bug properly, because some day we’ll need the documentation for resolving it.

Vulcans Never Bluff

Not all bugs are created equal. The minor ones, the ones “we’ll fix if we have the time” usually don’t get fixed. There’s a reason they are minor bugs. But we put the same effort into documenting high risk and low risk bugs.

It gets even funnier.

We document the bugs, because we want to have all the data for the programmer to fix it, right? So what happens when a major bug occurs? We quickly call someone to see the bug happening before we document it, because we don’t want them to miss it happening live. So in the important case, we’re documenting after we’ve shown the problem, and in the regular case, we document something that may not be fixed.

But the bug doesn’t just go away. Every bug in the backlog is waiting to be upgraded to “work in progress”. But in order for the bugs to be approved, they need to be triaged. And if bugs don’t get over the hump the first time, they will be re-discussed and re-reviewed, usually by more than one person, and usually more than once. What a waste.


Here’s a strange premise: What would happen if your bug systems was a limited resource? If it could contain no more than, say, 30 bugs?

Let me make it even worse: What if the total space for features and bugs in your backlogs were a total of 30?

You’d really need to make a decision, to really forget a bug or a feature idea.


As a product manager, I decided that there was too much information, ideas, bug reports and feature requests floating in different locations. So I limited the list. Some people were terrified.

“What will happen if we’ll need the information on that bug?” - If it’s a real issue it will come up again.

“But we won’t have a full picture!” - That’s a risk I’m willing to take, as long as I don’t have to re-read a bug description for the 15th time.

Today’s ability to store infinite pieces of information is in contrast to how our puny brains work. It needs small pieces of data to manage. It needs to focus, not disperse.

We don’t need more space, we need less.

Spock would agree.

PS: Now we’re looking for a new house, with rooms for the children, and an office. Oh, and maybe there’ll be a separate storage space too!

The New Agile–Decisions, Decisions

In the new knowledge economy, the winners are the ones who learn quickly. But learning means nothing, if it cannot be applied to the business. So the winners are the ones who learn, and use that knowledge, by deciding where to go, and what to do next.

If decision making is the king maker, it can also come back to haunt us. Because, high stakes can go either way.

Last time, we talked about how to pick a winning product. The picking part is about making decisions, and we’d like to make the right one every time.

Part of decision science comes from understanding how work works. You may think you know, but if you practice some kanban, and visualize the work, you know that what seems like a regular work, may not be that regular. In his book, Principles of Product Development Flow, Don Reinertsen goes deep science on the flow of work in an organization. I can testify that reading this book gave me chills. Years into agile and all that fluffy stuff that goes with it, finally a book comes along that measures work, with equations and laws, and queuing theory, and explains why things are the way they are. My inner engineer threw a party.

Among all the information in the book, comes the knowledge how to improve decision making. You probably won’t be surprised that it is based on collecting existing information. But we’re really gotten used to make decisions based on partial data, or even no data at all, at worst. While the ability to make decisions without all the pieces is a virtue in our uncertain world, many times the information that can help us make better decisions is there for the picking, and we disregard it completely.

When to make a decisions is as important as actually making it. Too early, and we’re committed, hard to change back. Too late, and we might miss the boat. Chris Matts and Olav Massen have written a whole book on the subject, called Commitment. Chris has introduced Real Options as way to look at how to treat choices as options. Once you start doing that, you don’t go back. For example, you may look at your backlog as a set of prioritized requirements. In reality, they are all options, with a certain value (that may change in time), and expiration date (because sometimes feature A has value because feature B was not there. But after B is implemented, the value of A vanishes). The final part of Real Options – only commit when you know why – is hurtfully missing today, because we’re still making decisions based less on data, and more because of pressure, gut feeling, ego, and all kinds of voodoo.

Since I’ve already brought up backlogs, how about deciding what to do first? Even at the portfolio level, where risks are bigger? How do we prioritize work?

In our first-to-market world, there’s a cost of coming second. This is where Cost Of Delay as a prioritization scheme comes into play. And it’s not just about making money off new products. There’s a cost of maintenance projects that are needed not to lose existing customers, for example. We need to prioritize all kinds of projects that help the bottom line in some way, and putting a cost on each can help us make the right decision. Cost Of Delay is covered extensively in Don Reinertsen’s book, and it’s not just theory: Shipping company Maersk is using COD to manage their entire IT business, and if one of the biggest companies on Earth can do that, you can too probably.

What’s the opposite of using data to make decision? Estimations. I’ve written and presented about #NoEstimates, and the biggest drawback of cost estimations, is that they provide a false sense of confidence when making decisions. Instead, we’ve made the estimation process into an art form, where many people are creating numbers that everyone knows are fake, and are treated as such. As #NoEstimaters say, there are alternatives, or at least complementary ways to make better decisions, that take other parameters into account, to corroborate the truthiness of the estimates.

Making the right decisions can build or break businesses. Shouldn’t we explore better ways to do that?

Upcoming Events

Here we go again.

March madness first: I’m happy to say I’m going to cover two thirds of Europe in less than 2 weeks.

On March 16-7th I’ll be at ACE! conference (that’s Agile Central Europe for the geography pundits). I’ll be presenting “ROI is Dead!” and if I survive it, a day later a workshop called “TDD for the Rest of Us”. This is my first time at ACE!, and I’m really looking forward to it. One of the cool things this year is the track selection: There’s the Agile stuff, the Workshop track, and a new track for Lean UX, Lean Startup and Design thinking. If you’re at Krakow and want to learn about new topics in the agile world, that’s the place to be.

A week later,  March 27-28th, I’m returning to AgileEE (that’s Agile Eastern Europe) in Kiev. That’s my 3rd time at AgileEE and I’m sure it’s going to be as awesome as the last times. I’m going to present a short, focused version of “The New Agile”.

So that’s the March part. 

Then, I have something like a month and a halg to defrost, before a very busy Belgium Testing Days in May 18-21st in Brussels.

I’m going to co-facilitate with Yves Hanoulle the full day workshop “Personal Agility”. Then I’m going to do another full day workshop about “The Secrets of Effective Unit Testing”. And if that’s not enough, I’m going to do “TDD for testers – The Star Wars Experience”.

And as always, there are other unknown unknowns coming up.

So stay tuned.

Unit Test, System Test, Red Test, Green Test

We tend to categorize different types of tests according to what they cover. Unit tests cover small portions of code, usually a method or a class, while we mock the rest of their interaction. Integration tests cover several components in concert, and then mock the other boundaries. System tests and their bigger brothers, End-to-End tests cover more and more.

Those categories are semantically correct, and they are relevant in the context of “how many should we have”. As in the testing pyramid:

The testing pyramid tells us that we should have more unit tests than integration tests, and more integration tests than end-to-end tests. There are a few reasons for that:

  • We can cover more code with smaller tests. Mathematically, covering small parts of the code is of linear order, while longer workflows (that covers different options of interactions between components) becomes an exponential order.
  • Unit tests are easier to write, because they require less setup. System tests require larger set-ups that are harder to write. While we can write both, the chance is that we’ll write more unit tests than system tests.
  • Unit tests are less fragile than their larger counterparts. System and integration tests usually depend on environments and available resources, and if they disappear for some reason, the tests fail, although that is not what they are actually testing. i
  • There are many paths in the code that can’t be covered by big tests, and can be covered by unit tests. You may question why this is so (I usually do), and usually the answer is YAGNI. But because there’s code, it better be tested, and unit tests do better job at that.
  • When using Test First, TDD’s feedback cycle is much shorter than ATDD’s. TDD lends itself to producing more tests, and those come at the unit level.

So you’re probably asking – if unit tests do such marvelous job, why do I need the other tests?

The answer, my frienda, lies in the upside-down test-trust pyramid:

Because unit tests don’t test the system as a whole, and tested system flows prove that the system works, we tend to trust them more. The longer the flow, the more trust it gains and our confidence in the tests grow.

Oh. So end-to-end tests must be the best of the batch. Why not write more than those?

We can revisit the former list, but instead, I want to talk about value.

What is the value of a test?

Automated tests (and tests in general) give us feedback. That’s their main value, but not the only one.

You see, if every test passed, the value of the end-to-end test would be the largest. It gives us more confidence that our system works, compared to unit tests that cover the same code.

But that changes if it fails.

When we have a system test failing, we don’t know what to even look for: Is the problem functional? environmental? At which point of the flow did the problem occur? However, when a unit test, covering some of the code that the same failing system test goes through, we’ve got a more focused, isolated description of the problem, which is easier to solve.

So what kind of tests should we write?

Going back to the test pyramid, more unit tests than system tests. We’d like the confidence the green system tests give us, but we’d like to solve the problems with their smaller siblings.

Remember: Green system tests give us more confidence. But the value of a red unit test is bigger than a red system test.

The New Agile–Picking A Winner

We’ve talked about scaling and methodology on how to build stuff, but hey, we want to know what to build, dammit!

Unfortunately, SAFe, scrum, XP, or Lean Startup don’t talk about what we need to build. Just how to get it out the door.

Picking a winning product seems like the holy grail. Business analysis and product management methods can help us with it.

The problem is that some of the regular methods didn’t deliver. They relied on gut feelings, or subjective interpretation of information. And they didn’t take into account how complex the market is.

A couple of methods, that have a lot in common, have surfaced in the last decade, and changed the way we think about the problem. They try to revert the way we build to a way that makes sense in our reality.

First we need to explain what doesn't make sense. Let’s say I, the product manager,  know I need a feature. The team spends 6 months building it, then shows it to me, and I say, “it’s not what I wanted” . Sounds familiar? We can say that the customer (me) never knows what he wants, but that’s getting off easy. The real problem is that the team didn’t understand what problem it was solving. If the team understood the problem, they might have come up with a different feature to solve the problem, and wouldn’t have wasted 6 precious months.

The problem starts with us not asking “what problem does the feature solve”. Even more so, we should start with the problem, and then build the feature that solves it. This is what stands behind Chris Matts’ Feature Injection. Apart from the cool name, there is real understanding of the need, and only then suggestion for a solution. It’s what stands behind Gojko Adzic’s Impact Mapping, in which we start with the impact we want to achieve, then figure out how to build it. And it’s what stand behind Liz Keogh’s Capability Red, where we want to understand the customer in order to develop a solution for their problem.

And don’t forget of Design Thinking –  actually seeing what the problems are, then coming up with a solution.

In all cases, there might be a smaller, easier and cheaper solution than the one we thought of first. Once we understand the need or the problem, we can suggest multiple solutions, than pick the one to try.

You are probably thinking at this point: This is just common sense. These are simple ideas. Why, I could have thought of that!

Well, it’s not that common. Organizations continue to develop what their product people think, they deploy the solution and then see what happens. Only, then understanding what happened in hindsight. That’s a big ass feedback cycle.

It may not be common, it may not be easy, but it is simple agile sense.

New Release of Everyday Unit Testing book!

I know, it’s been too long. I’ll try to do better next time.

In the meantime, find out about the new stuff.

And give me feedback!

Related Posts Plugin for WordPress, Blogger...
Twitter Delicious Facebook Digg Stumbleupon More