Daily Standup Vs. Daily Standup

There’s a fundamental difference between participating in daily standup meetings because you want to and attending daily standup meetings because you have to.

You want to attend Daily Standup because you believe you’ll inspect and adapt.
You have to attend Daily Standup because your organization is following Scrum or your boss has asked you.

Former helps the project and the latter does not.

When you do the former, everyone benefits. You. Your project. Your organization. Your customer. Your customer’s customer … everyone.

There’s no “have to” in Scrum. You do it or you do not.

Are you doing Scrum or are you doing Scrum because you have to?

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.

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?

On Scrum and Estimations

I have seen many Scrum novices arguing and saying that Estimates are not useful as we are anyways putting in our focus and energy on the most important tasks.

That’s seldom true. Estimates are important and provide a rough idea about how future should shape itself.

Read this insightful post on Estimation in a Scrum Project  from Mike Cohn. It shows a dialogue between client and the Scrum team.

It is important to note that Scrum projects are part of real world that requires some idea about what will be delivered. Any Scrum team cannot take the flexibility that the framework provides for granted.

The flexibility is to eliminate the unnatural, rule-powered ways from the project. It’s not to disregard the need of business.

Here’s my take on it:

“If it doesn’t make a business sense, it is not the right implementation of Scrum.”