Tag: software

The difference between caring and caring enough to do something

narcissistic man

Product development doesn’t have to be narcissistic

I’ve been accused of being a narcissist before. Not in those exact words, but I will never forget the conversation. I was 25 and a good friend of mine and I were talking. She finally said (in a rare pause of my banter), “Natalie, you always talk about you and never ask about me.” Wow, that one hit hard and I felt guilty and ashamed. I had never thought about it before. I wondered where my baby-boomer parents had gone wrong in raising me as a millennial snowflake (who was nothing but extraordinary) who didn’t know the true definition of meaningful discourse. Ever since then, I’ve put a concerted effort into making sure that I ask the other person I’m talking to questions about themselves. It’s a constant reminder in my awkward conversational brain – “ask them about their day, weekend, year…yeah—that’s perfect!” We often run into a narcissism problem in product development, too, and it can stem from fear and shame.

Estimating defects and tech debt – should we?

This is a good follow on to the velocity and capacity discussion. If velocity is the amount of new feature work we can get done in a sprint and capacity is the amount of bandwidth we have in the sprint, other stuff fills in the delta between velocity and capacity. SO…do we estimate it?

How do companies make themselves stand out via interviews?

When interviewing for jobs, you want to leave the a memorable impression on the interviewers and company you’re interviewing with. But what about the opposite? Shouldn’t the company be focusing on leaving a memorable impression on you? I’ve been interviewing extensively over the past few weeks looking for my next contract, and a lot of the interviews melt together. Some, however, stand out very clearly and make me positively remember how the particular companies differentiated themselves in my head. Here are a few examples on how you can leave a memorable impression on potential employees and stand out from the hoard of other companies they are inevitably interviewing with in the high demand IT/Agile industry.

Changing the code base landfill into a lean and learning recycling center

Waste seems to be a simple enough concept: anything that does not add value should be eliminated. But what about the features that are supposed to add value and actually don’t? What about the features that are started working on as an idea or a quick win that we do to just get it out there quickly – MVP style but not really – that end up being thrown away or redone soon after? Afterward, no one denies those are waste; but how do we turn waste into something that can be recycled?

Why making things “easier” makes them harder: The argument against modifying Scrum

I’m sure many ScrumMasters implementing have heard this or similar: we’re not like other teams; we do things differently; Scrum won’t work in our organization. The result is usually: “let’s modify Scrum so the adjustment is easier on the team/organization/processes.” Sound familiar? Well I’m going to call that bluff.