The “Pay to Learn” phase of projects

We should try to avoid waste. (Really?)

Nobody wants to create something just so it can be thrown away. (Really?)

Since “all universal quantifiers are always wrong”, those statements are probably not the whole story.

Even in lean eliminating waste is not as high a priority as one might think

In new product development – and re-implementing things in a different environment is new product development as well – a lot of effort goes into determining what the product actually is. And how to best build it.

Therefore some efforts are not waste at all, even if their results never go into production. In manufacturing and construction this is obvious for things like molds or scaffolding, but the same is true in knowledge-work as well.

Sometimes it makes a lot of sense to build something that will be thrown away, just to learn the right way to do it. Or at least a good way to do it.

Let’s have a look at Twitter for example. Twitter initially was build in Ruby (Ruby on rails to be exact). After a while it was rebuilt using different tools and techniques. So “obviously” the original implementation had to be “thrown away” at that time.
Does that mean that they shouldn‘t have started with Ruby? On the contrary – they ran with it for a couple of years. And they learned what they wanted to do with it.

But there are other things that you might not need in the later stages of product development – like dummy implementations of surrounding systems, paper mock-ups of user interaction, simulated server-roundtrips and a gazzilion more – but all of those help you learn.

And this "pay-to-learn" phase (with the willingness to throw away stuff that no longer is needed) is what often differentiates a really good product from a mediocre one.

till next time
  Michael Mahlberg

Saving the product - will you row or bail?

I recently wrote about the widespread phenomenon of the evergrowing pseudo-committed backlog. In which case a backlog really becomes a backlog in the original meaning of the word: Unfinished stuff.

But having such a huge “accumulation of tasks unperformed” (as the Merriam-Webster online dictionary defines ‘backlog’) also often leads to another problem. Housekeeping gets postponed until later. Way later.

What’s the big problem?

Look at it this way - you’re sitting in an eight (the 8 person rowing boat with nine people in it) and your boat is taking on water. Slowly but constantly.
Actually the rate at which the boat is taking on water will lead to the sinking of the vessel about 500 feet before the finish-line. In the world of projects that would be the moment your product becomes unmaintainable.

What are the options?

There are some options to deal with the situation. Let’s look at a couple of them.

1. You could just all stop rowing, start bailing and wait for a SAR-Team to pick you up.
2. Part your team could continue rowing, while the rest starts bailing.
3. You could designate one “bail person” and still try to reach the finish-line with the rest of you still rowing at maximum power
4. ... [lots of other options]

Replace rowing with “creating new features” and bailing by “doing maintenance” and you have a pretty good analogy to the situation we sometimes find ourselves in with the zombie-backlog.

To decide what to do, you might also want to add some more ‘real-life’ rowing challenges. For example the boat might stay afloat long enough to reach the finish-line if only one person is rowing and the rest is bailing, but that person would not last the whole distance. So a rotating system has to be put into place. (see any applicability to your product's situation yet?)

Or take a thunderstorm (and the competition) coming up behind you. Depending on whether the rowers are also able swimmers you might put more people on the oars and risk the boat going under just behind the finish line to still win the race. If none of them are swimmers reaching the shore becomes more important.
Or you might invest more people at the bailing buckets and therefore not be able to outrun the competition, wich will cost you the race, but still get the boat out of the water before the thunderstorm which might otherwise cost you the season. (Depending on your funding and the availability of new boats)

The non-option

There is just one thing that you can’t reasonably do – keep on rowing like there’s no tomorrow. Because if you do, then –someday soon– there won’t be a tomorrow for the product.

Next time you look at the product and the backlog you might want to consider what to tackle – the oars or the bailers.

till next time
  Michael Mahlberg

What's in the Potentially Shippable Product Increment (PSPI)?

There are many references to the frequent release of running software in the agile universe – of which the agile manifesto certainly gets cited the most.

One term has become very prominent - the “potentially shippable product increment” from the agile sub-universe of scrum. [In this case from LeSS - the Large Scale Scrum Framework. ’Of course’ the scrum guide itself does not use this term. The scrum guide calls it “Increments of potentially shippable functionality”]

But since the notion of the potentially shippable product increments captures so much of the practices of good agile software craftsmanship I really fell for the term and use it more often than the official term from the scrum guide.

And it is a very handy way of illustrating what is behind the ideas of Integration, Shippable, Iteratively, Product(ion quality), w

Integrated

“All [created artifacts] have to be integrated” – the stuff really has to work together (as I outlined in more detail in what exactly is continuous integration).

Shippable

Something you could give the customer to play with on their own. An installer-file, an executable, a .ear-file with deployment description, a docker image etc. Something they could really “take away” with them.

Iteratively

We know we are going to change things - let’s build them in such a way, that it is (and stays) easy to do that. Even though we deliver increments of the product we do so iteratively – we do not try to paint a picture like the Mona Lisa from the top left to bottom right. We do it with sketches and refinements and edits until we are finally satisfied with the result.

Production quality

Production quality is perhaps the hardest one to explain without painting lots of pictures. One of the best explanations I've come across is that it "also has to work when the customer can use it without the developer being around" – which implies many little things.

Those things could include:

• a user friendly way to interact with test-data if there is something like that necessary for the relevant increment
• no buttons that don’t do anything
• no spinning wheels that are not connected to any of the inner workings
• etc.

Of course this is a bad definition, because it (almost) only defines a negative-list. It only says what production quality is not. I’m still working on a positive-list, and hope to release that soon.
One thing for that positive-list that springs to mind immediately is the requirement that the code adheres to the SOLID principles – so that it only has to be changed if a future requirement has an impact on the implemented capabilities – not because something has been left over “to be fixed when we work on this in the next iteration.”

How do you define your “Increments of potentially shippable functionality?”

till next time
  Michael Mahlberg