Hot Needle of Inquiry

From time to time in discussions, people will use a phrase like the one above. What it means, of course, is that the recipient is an idiot who doesn’t understand what’s going on. The statement means “I cannot refute your foolish and unrealistic argument but I don’t intend to change my mind.”

Still, it’s not quite as bad as “In the real world …”. You have to admit that.

“What color is the sky on your planet?” is right up there too.

If you ever catch me using any of these phrases, call me on it. I’m in the book. The Mars book.

On the leandevelopment list, there has been a bit of a discussion on how long the “backlog” should be, and why. This was triggered in part by a posting from Mary Poppendieck, in which she said:

It doesn’t matter who owns the backlog, the responsiveness of the development team to real needs of customers will be in direct proportion to the length of the backlog.  This is a supply chain issue, and in general, the shorter the supply chain, the faster its response. (more…)

For some reason, I’m remembering a guy in Florida who pushed his team to commit to more and more. I asked him why after the meeting. He said “People need stretch goals.”

Now a little pressure helps me get things done, I freely grant that. But it only works if I get them done: otherwise the pressure just frustrates me, makes me feel bad, makes me slower still.

For the business, the value of Agile is that you know where you are and that gives you a good idea of where you will be. If you’re working on stretch goals, you don’t know where you will be, you have some under-pressure wish-driven fantasy picture of where you will be. All you know for sure is that you won’t be that far along. You have doomed yourself to disappointment.

As managers, we need our developers to find their joy in getting things done. We will not prosper if they get off on the joy of heroic effort, or the joy of slamming in last-minute fixes that will save the project if only they are successful. 

People under pressure take shortcuts. In software development, shortcuts show up when poorly crafted code slows us down and piles bugs upon bugs. We don’t need that.

We need to know that when something is reported done, it is actually done, working, complete. We need to know that it won’t have to be revisited, taking up an unknown amount of time in the future.

Pressure makes that impossible. Pressure robs us of what we need.

To get what we need, to get things done in a predictable fashion, to get things done well, we cannot tolerate stretch goals. We need to value commitment to a result that can be attained. Stay away from stretch goals, that’s my advice.

Science and the scientific approach works well for many purposes, including possibly its ability to convince others.

When we make decisions based on any kind of “true faith” approach, (more…)

This idea came up while Chet and I were discussing politician’s answers to questions, which seem often to have nothing to do with the original question.

Q: Senator, what is your position on launching a pre-emptive attack against Georgia?

A: The protection of this great nation is my highest priority.

Q: Yes, but what about an attack on Georgia?

A: My opponent’s views on the economy are retrograde and misinformed.

Whenever we’re just going along and suddenly we see a duck, it is mandatory to say “Oh, look, a duck!”. This is well-known. Even though it derails the conversation, we just have to do it.

So if we were to carry a throw-down duck, when the going got tough, we could throw down our duck and say “Oh, look, a duck!”

I hope this idea is useful to you and I look forward to seeing a lot of ducks at the next conference.

I’m more or less beavering away on the Kate Oneal articles. The overall flow of the book will be events throughout Kate’s project, company, career. For now, articles are roughly chronological but are covering topics that she and I think are more urgent. I wish she’d do more of the work.

I’m very interested in people’s reactions to the material, and welcome ongoing comments here following this article, or via email. Remember to include [ron] as part of your subject in email to me, unless you’re sure you’re already on my whitelist.

Here’s the Index of Kate Oneal Articles.

Thanks!

Thought I’d enable comments just to see what happens. I’m requiring name and email and, I think, moderating first postings.

Let me hear from you. Thanks!

Don’t these people have anything useful to do? Even if Obama had been referring to Palin as a pig, which he clearly wasn’t, if you’re grown up enough to run for VP you’re grown up enough to wave off a stupid insult.

I’ve seen third-graders run better elections than this. 

I suppose politics has always been disgusting. We just didn’t have 24/7 media coverage back in the days of Washington and Adams. 

The thing that bothers me most, though, is that if you sow hatred, distrust, and fear, you’ll get hatred, distrust, and fear.

We are better than this. How can we make these people work together to make the world, and our lives, better?

Here’s a little something I wrote to the Scrum list, to the 14,321st team who are having trouble using tasks in Scrum planning. This team was having trouble getting through the planning in under 2.5 days. (!)

Well, first of all, tasks are teh suck. Breaking the job up into tasks means you have to put it back together, which is always difficult. I’m writing a Kate chapter about that right now.

What I recommend as a planning process is this:

1. Product owner writes story on whiteboard, and explains it.
2. Briefly discuss how the story will be tested.
3. Developers briefly brainstorm and list technical steps needed.
   (Similar to tasks but we’re not going to do the work, nor track it that way.)
4. Repeat until enough stories are on the board.
5. Look at the list, draw the line where you’re confident you can accomplish everything above the line.
6. Commit
7. Do stories as a unit, not broken into tasks.
8. Burn stories, not tasks.

Q: But for this to work, everyone would have to be able to work on everything.
A: Yes, that would be ideal. And you could do pair programming — that would fill in needed skills and people would learn as well.

Q: But even so, for this to work, stories would have to be very small.
A: Yes.