Oh, about that Notable Example…

In my post on Overcoming Resistance, I said, “I wanted to write an article with a shining example of a time when I didn’t try to overcome resistance, but used it to advantage, instead.”  Besides the Velvet Elvis principle that Don Gray describes, there’s another reason why one didn’t come to mind.

You see, actually listening to people doesn’t work in a big, noisy way like that.  Instead, it’s a quietly effective activity that doesn’t call attention to itself.

When was the last time you said, “Boy, I really listened to her, didn’t I!” Hmmm…  Doesn’t have the same verbal punch as “Boy, I really told her, didn’t I!”  It’s just more effective, that’s all.

No Comments

Categories: Individuals and Interactions

Tags: ,

Overcoming Resistance

Esther Derby posted an excerpt of a Management Consulting News interview with Jerry Weinberg where he answers the question of how to overcome resistance, “Yes. Don’t.” Oh, he says more there, and he can say a lot more on the topic, but that’s enough for the intro to this article.

You see, I wanted to write an article with a shining example of a time when I didn’t try to overcome resistance, but used it to advantage, instead. The problem was that I found myself in the trap that Don Gray frequently mentions, that when someone tells you not to think about something, you can’t help but immediately think about it. So what filled my memory was a time when I had tried, eloquently and earnestly, to overcome resistance on the part of my client. Read More

5 Comments

Categories: Individuals and Interactions

Tags: ,

Interface between Domain layer and Persistence layer

What’s in a name?

I happened across Debasish Ghosh’s post “Inject Repositories, not DAOs in Domain Entities” and it triggered a few thoughts. In this post, he suggests that the Data Access Objects that perform database reads and writes should be wrapped in a Repository wrapper to isolate the domain layer from the details of the persistence layer. What do I think? Well, yes and no. Let’s look at this in a little more detail. Read More

6 Comments

Categories: Tools and Techniques Working Software

Tags:

Mentoring, as Team Leader

I was asked about how I would mentor people in the context of being the team leader. Tricky situation, that.

On the one hand mentoring people without their request is an instance of what Jerry Weinberg calls “inflicting help.” At best, it’s ineffective. Usually it’s worse.

On the other hand, an organization has a reasonable expectation that the people working there will improve over time. Who better to help a team do that than the team leader? Read More

1 Comment

Categories: Individuals and Interactions

Tags:

Studying patterns for Fearless Change

Fearless Change: Patterns for Introducing New IdeasDon Gray got me started, with his posting of 3×5 notecards for studying the patterns in the book, Fearless Change: Patterns for Introducing New Ideas, by Mary Lynn Manns and Linda Rising. I agree with him that it’s a wonderfully helpful book, and I thought the idea of creating cards to carry and study at odd moments was a good one. I’m just too cheap to buy the Avery cardstock–not when I’ve found that I can print ordinary 3×5 cards in my wife’s inkjet printer (an Epson C60).

So, at Don’s suggestion, I re-formatted his format and created both OpenOffice and PDF versions of the cards. I hope you find them useful, but be sure to read the book! Not only is that fair to the authors, but the cards will make a lot more sense to you.

[2020.07.07 Fixed broken link to Don’s version of the cards.]

1 Comment

Categories: Individuals and Interactions

Tags:

Testing that no errors remain

On the Test Driven Development YahooGroup, Alan Baljeu asked, “It is my impression that whenever a feature is added, there may be many things which are affected by adding that feature…. And by not considering those things, you introduce bugs into the software.” In response, he got two types of advice. One was specific suggestions of software construction techniques that can reduce the occurrence of errors by reducing the number of places that need to change when adding a new feature.

The second type was general testing advice. Alan admitted, “I don’t see a way to properly identify what new behaviour will need to be covered. I want to be sure I’m not forgetting cases, but currently I’m overlooking too many of these effects.” In other words, the current test coverage is not catching all the errors. Read More

4 Comments

Categories: Working Software

Tags:

Make it work before you make it standard

Matt Heusser has just published a post about standards. In it, he says

So, when people rush to standards, I hold back a bit. Having a standard means saying “We believe the value of doing things the same, every time, is more valuable than the value of the lessons we will learn by experimenting with new things.”

I, too, have been puzzled by the rush to standardize. Read More

6 Comments

Categories: Working Software

Tags:

When do we get to the stage where we can tell the client what the answer is?

I saw this question in a blog post by Mark Schenk:

About two-thirds of the way through the workshop one of the students asked “when do we get to the stage where we can tell the client what the answer is?” This literally stopped us in our tracks ““ we were so accustomed to working on the basis that complex problems have no single correct answer that we hadn’t explicitly explained this and we had bumped headlong into a prevailing management mindset.

That question struck a chord. I thought back to the days when I first learned XP. Most of the ideas and practices resonated strongly with me. The one that seemed most foreign, Test Driven Development, became a personal fixture after trying it for three days. Yep, this was the way software development should be done! It was so obvious and right, and I told everyone I knew.

They all immediately agreed and thanked me for the information. Well, not exactly. Read More

No Comments

Categories: Individuals and Interactions

Tags: , ,