It’s right there in Tom Petty’s song: “Waiting is the hardest part.” But Tom got it wrong: starting is the hardest part.

Everyone from Alexander Pope to Elvis points out that fools rush in while wise folk wait (Elvis gets right to the point, while Pope takes considerably longer). And who could fault a team, timid ScrumMaster, or tentative manager for sounding the depths before diving in and doing what needs to be done?

Well, Ron Jeffries can. In his book and presentations, Ron says don’t wait—start reaping benefits (and revenue!) early by getting working product into the market now, before your competitors do. My colleague Skip Angel exhorts teams to “just do it.” And my own experiences with watchful waiting have shown me the rear end of many opportunities that didn’t just knock once, but found another door when I was slow in answering. So why do so many of us, knowing what we do, still hesitate to start, whether it’s start a sprint, start a project, or start telling the truth.

Maybe it’s because we’re afraid.

I was listening a week ago to a presentation Diana Larsen gave at SolutionsIQ when I suddenly sat up straight. “We only learn at the uncomfortable edges,” she said, and I was launched back into a time a few years ago when I was working with a team to deliver a functional overhaul of a B-to-B e-commerce Web site.

The product manager and I (the program manager) wanted to use Scrum for the project, but the development manager, who managed all the members of the team, was reluctant, and insisted on using what had worked for him before. What had worked before was a mish-mash of upfront planning, seat-of-the-pants estimating, and Microsoft Project-assisted project tracking. The tracking wasn’t really tracking, though; each time something didn’t happen as predicted, Project just kept telling us how much faster we’d have to work to hit the non-moving deadline for delivery).

The three of us were responsible for providing input to an executive dashboard that expressed the status of projects using the familiar red-yellow-green traffic lights. Each week, we peered intently at the Project sheet, which the dev manager had printed out on three sheets of paper that he taped together. After a handful of week, we knew that the project had drifted into red territory. Each week, the dev manager said that he thought that, with a little more effort and a bit of luck, we could get back on track. Each week, we were willing to believe something that we wanted to believe. And so each week, all three of us agreed to ignore our misgivings and doubts and delay reporting the project status as red. Until one week, more than half the way into the project, something happened.

Stay tuned to hear the rest of the story.

Not all of us naturally have the gift of helping people recognize and resolve dysfunction and impediments without, um, peeving people off. When serving a team as a ScrumMaster, it’s easy to turn into a harping kvetcher. When management and team members both start changing their paths when you walk down the corridor, you know it’s time to find a more effective approach to your job.

Gretchen Rubin makes a familiar but often forgotten good point recently in her blog: there are different ways of looking at a given situation, and some may be more palatable and effective than others. A frequent result of your good work as a ScrumMaster is exposed dysfunction in your team or company, but there’s no reason to rub people’s faces in it. With a little imagination or attitude adjustment, you can make your point in a way that’s effective instead of demoralizing, while avoiding becoming a Pollyanna or sweeping problems under the rug.

My favorite example of this approach comes from a performance review written by the best manager I ever had. Summarizing the primary accomplishment of my last six months, a technical manual that I’d researched for five months and written in one, she wrote, “Michael’s guide to system management is the best manual on the subject we’ve ever seen. One can only imagine how good it would have been if he’d started writing it earlier.”

Lately, I’ve been particularly aware of how, in response to a positive suggestion or idea offered by another, many of us start by saying, “The problem is…” We lead with the negative, hardly the way to make our conversational partner feel good about their idea or our interest in it. There’s always time for the challenges to surface and be identified, but perhaps that time isn’t seconds after we first hear the idea.

Agile teams spend a lot of time dealing with “the problem,” in retrospectives, in pairing sessions, in planning meetings, in raising impediments. This is why it’s so important to identify and celebrate successes frequently, but there’s no need to wait until success is obvious. Create environments where success can thrive, by focusing on what’s good and encouraging more of that.

Now that I think of it, that’s how you brew good beer. When the sweet wort enters the fermentation vessel, it has lots of wild yeasts (from the air) and brewing yeasts (from you) in it. The trick to getting good beer is to encourage the brewing yeasts to grow and work faster than the wild yeasts. The good pushes out the bad, or if I’m going to be more facilitator-y about it, the useful prevails over the not useful. I’m told you grow a nice lawn the same way, but I know more about fermenting beer and Scrum teams than I do about gardening.