Categories
Engineering Hives and Silos

Not Meeting in the Middle

The person holding the P&L and sponsoring the project needs new, improved capabilities for the business to create value. A suitable IT solution and project could deliver the needs.
There is no interest in architecture, performance, documentation, choice of platform. It just needs to happen.

The team of individual contributors in delivery just want to get their code into production as fast as possible. This is particularly true for contractors and offshore delivery centres with economical rates measured on the speed of delivery.
They too have little interest in architecture, performance, documentation, platform.

Folks in the middle who are tasked to make it all sustainable – so the next project does not cost an arm and a leg, and does not take a lifetime to complete – are in an impossible position.
They do care about architecture, performance, documentation, platform, and more.

Many businesses have been practicing decades of waterfall shaped delivery. The projects are typically sized between 6 to 12 months, while parent programs can run much longer. A sizeable work upfront on requirements is rapidly followed by delivering, churning out code up to final delivery into production.
Meanwhile, governance bodies and design authorities are desperately trying to wedge themselves in between stages to provide some oversight and much needed guidance.

Now that everyone and their dog is pitching to be agile, a torrent of anti-patterns emerge from waterfalling into sprints expedited by doing away with plan, design and documentation.
Practically, entirely removing the opportunity for oversight and to work out sustainable solutions.

A worthy read on the struggles of business-IT alignment: Don’t become an Enterprise/IT Architect… by Gerben Wierda

Categories
Engineering Product Management

Measuring Outcome

What is the measure of an outcome in an organisation?
Is it a tick in the box?
Is it a business relevant metric?

Metrics are too often mistaken for a tick in the box.

Metrics are hard, measuring them is even harder.
Moving the needle on a metric that counts is an achievement.
Recognising people, teams, divisions, entire organisations for results is leadership.

A tick in the box has never delivered any real value.
A tick in a box has never transformed a business.
What kind of culture does giving credit for a ticking the box drive?

If your daily work involves ticking boxes, send a link to this article to your superiors.

Categories
Engineering Product Management

On Measuring

Measuring code quality, productivity, technical debt is difficult.

Measuring number of lines of code; speed of delivering code; completed stories, features, epics is easy.

Do not trade quality away for comfort.

Categories
Engineering Hives and Silos

Kicking the can down the road

Technical debt sneaks up on organisations and their systems. It is inevitable.
The ability of dealing with, managing, remediating it differentiates successful businesses from the rest.

Technical debt builds up over time. It could take years for it to amount to significance. If unattended, it reaches a time when the fixing costs are higher than the return from it.
The system still produces value at this point, it has not gone bankrupt. There are even workarounds to some of the issues.
However, innovation, new feature and product introduction is not sustainable anymore – nobody wants to touch a house of cards system, or pay the premium for the overhead of dealing with the mess.

The system enters the zone of – kicking the can down the road.

Occasionally, a large(ish) investment into the existing system might be justified if it generates enough value – as opposed to replacing it entirely, which would be too expensive.

In most cases, just enough fixes are applied to keep the lights on and to keep sweating the asset for the rest of its operational life.

Minimise the effect of bad debt and extend the productive lifespan of a system by

  • Looking out for the technical debt indicators
  • Putting strategies in place for managing technical debt
Categories
Engineering Product Management

Is it Serious?

Transpiling a good doctor-patient joke to techie-CEO:

  • CEO says to one of his techie “Is it serious? How long do we have until we go offline?”
  • Techie says “5”
  • CEO says “5 what? 5 days? 5 weeks? 5 months?”
  • Techie says “4…”

Categories
Engineering Product Management

You call yourself a SaaS?

You do not get to call your product a Software as a Service (SaaS) if it does not support webhooks or REST hooks in addition to a decent collection of APIs.

Your product is just web application.

Categories
Engineering Product Management

The Obsession with Blockers

So much focus is lost on asking – What are the blockers? – that the organisation forgets to enable its people to do the work.

Failing to enable those that do the work is the biggest blocker in an organisation.