ScrumZen - Leverage Scrum, Deliver Results

Is This Your Best Code?

by Utpal Vaishnav on January 25, 2014

This is the wrong question.

The right question is, “What knowledge, skill, tool, framework or support will enable you to write better code than what you’ve written?”

So what do you mean by better code and why should you care?

Better Code does not always mean well structured, well documented, reusable code. Many a time, Better Code simply means, the code that does what is expected and does it well for most of its consumers.

In past 14 years, I’ve worked with many passionate, crazy and talented software engineers who are fanatical about producing their best code.  Some software engineers, with experiences of different kinds, get it sooner or later what better code means. Many don’t and continue working hard towards producing their best code.

They take great pain in making their code better at the cost of:

=Eval("put whatever highest cost you can pay as a developer").

Willingness to take pain is good but better is to be willing to take right kind of pain.

You write quality code not because you feel “cool” about it, you write quality code because you believe in the indirect value that it will bring in end-users life.

Much rewarding is to take great pain to understand your users world. Even if you are an innovator and you’re going to change the way users behave, take great pain in understanding and communicating how your code will help make that happen.

I have observed many Scrum team members complain that because of iterative way, they cannot produce their BEST code.

It is okay. You’re not in the team to produce “your” best code, you’re in the team to produce the code that will add value to its consumer’s life, even if it is not your best code.

When business leaders ask such question whether this is your best code, Scrum team members get confused. You don’t need to.

Your job is to produce good code, and enable your team to ship fast and ship often, gather feedback and make the whole ecosystem better in the next iteration. I’m not asking to create bad code. It has to be good enough. Shipping fast does not imply shipping crap.

Presuming that you can get better at whatever activity you pick, choose to get better at what you should be get better at. Now that’s a smart choice, not all software engineers make that!

Software Engineers who make such choices are often part of a high performing Scrum team. Perhaps that’s why it is not so easy to locate high performing Scrum teams. A problem worth solving.


Scrum Teams and The “F” Word

December 8, 2013

What’s the “F” word in Scrum? Not [F]un. Not [F]ire. Not [F]ailure. What is it? Most scrum teams deal with software engineers so they are concerned more about engineering challenges than anything else in all what they do. In Daily Scrums. In Review Meetings. In Retrospectives. Often, they don’t pay active attention to important “F” […]

1 comment Read more →

3 Tips for Product Owners to Survive the Chicken Test

December 5, 2013

As a Product Owner, why should you even think about the Chicken Test? For a simple reason: You are accountable for ensuring that the product you’re working on achieves its goals. The chicken and pig metaphor suggests that the difference between ham and eggs is this: the hen is involved, but the pig is committed. […]

0 comments Read more →

The Problem With Preparing User Stories In Advance

September 17, 2013

is that it lacks the “ownership” part. Some Product Owners invest a lot of time creating user stories and provide them to the team in the sprint planning meeting. It is an opportunity lost to explore team’s point of views and knowledge. Stories created through such activities often serve as meaningless piece of document in […]

1 comment Read more →

How Every ScrumMaster Should Deal With Attention Issues?

August 6, 2013

Ever been part of a team where team members didn’t pay attention to what was being communicated? Yes, in Scrum teams also that happens. Especially in the Daily Stand-ups. Team members don’t always pay attention to what other team member is saying. Most people get this habit from their daily lives. They go to doctor […]

0 comments Read more →

Should a talk on Agile engage its target audience?

May 7, 2013

“Of course it should,” would be the your answer if you know little bit about Agile concepts. But in practice, often they do not! I was watching a YouTube Video from an “Agile expert” who is a Global Head of Delivery with a Leading Based Software Development Company. My expectation was: I will get new […]

0 comments Read more →

Don’t Code for Perfection

April 18, 2013

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 […]

1 comment Read more →