Don’t Code for Perfection

Enter year 2000 to know that Ket was more than a competent programmer. Not just competent, super intelligent too.

He was also a kind of perfectionist.

It was initial two years of his career but because of his intelligence he was leading the team of five and working day and night on delivering a software product that had hundreds of order booked prior to its launch.

Ket simply wouldn’t allow the less than perfect code to check in into the code repository. The code had to be “perfect” and he has to be absolutely clear about it.

He would allow the code to check in only when there is no other way left. He had to handle a lot of pressure from the investors also.

Ket’s way was a surefire recipe of a slow disaster, isn’t it?

So, don’t code for perfection. Don’t be like Ket that way. Code for excellence instead.

No one will be impressed with the software app that you have not released. You even do not know if it is a minimal viable product or not.

Perfection doesn’t exist. Strive for excellence instead. Use iterative approach. Define a set of feature, prioritize them, pick a potentially releasable set and build them to the demonstrable piece of code.

People who invest in iterative learning already have what is called “The Agile Mindset.”

That’s exactly opposite to “Perfectionist Mindset” where you invest in your illusion more than anything else without even knowing whether there is a possibility of good ROI or not.

The analogy used is for a software app but same is true with a book or a blog post or a logo design.

Ship early, ship often and keep getting better. [Click to Tweet]

Scrum is possibly the most powerful tool to help you do that. Don’t wait, find out when scrum works and when it doesn’t.

Roman Pichler on Product Backlog

Reading an excellent post on Product Backlog from Roman Pichler – The Good, The Bad and The Ugly Product Backlog.

The product backlog is the roof that covers a Scrum Project.  So what’s good, bad and ugly about it?

Good – Simple list. Flexible. Supports sprint and release planning.

Bad – Needs that are hard to describe in a list-form become difficult to maintain. Often requires another tool. Also, when it becomes challenging to use a list when release planning is not feasible.

Ugly – When requirements are stated with unnecessary details, and the list is of hundreds of items, product backlog becomes ugly and hard to deal with.

The way I see it, bad and ugly part of product backlog have more to do with how it is used and less to do with product backlog itself.

Nonetheless they are important and cannot be overlooked. Similar to how a Scrum Project evolves as it progresses, implementation of product backlogs will also evolve.

That’s why Roman talks about an alternative to Product Backlog – The Product Canvas, which is a really good tool to see and use.

Progressive elaboration is the key nature of things in Scrum, isn’t it?