Is This Your Best Code?

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

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” word.

Scrum Teams and The F word

Don’t get surprised when I say that the “F” word is their “FEELINGS!”

Don’t get surprised.

Techie guys don’t tend to speak more about their feelings. Essentially, they are left brainers so they seek logic in what they do. Feelings come as a second thought to most.

But what they feel while being a part of Scrum team is important for a Scrum team to succeed.

“People who feel good about themselves produce good results”

~ Ken Blanchard, Spencer Johnson, The One Minute Manager

(Read more about my experience with The One Minute Management Learning)

Cannot agree more: People who do not feel good about their work, cannot produce good results!

And, Scrum – or any other Agile framework for that matter – exist to produce great results; not for any other objectives.

Scrum Masters need to figure out ways to understand the feelings part of their team members and create situations where the team is motivated to assume the ownership of the tasks they undertake.

So, ask your team member directly how she feels if you have a great rapport with her. If not yet, there are other ways figure that out. Some example questions:

1. What excites you to do X, Y and Z?
2. What situations make your low point?
3. What situations make your high point?
4. How did you find working with other team mates on this sprint?
…and so on.

Choose the questions that open up your team members and share their experiences.

Experiences express feelings.

Understand what makes them feel good; what makes them feel uncomfortable and create situations that are motivating for the team members to perform.

A small but important soft skill that every ScrumMaster should have.