Category: Needle

Just some small thoughts bordering on rants. Something here for everyone to get mad about.

Let's try this again. The previous article was not clear to all readers. I suppose this is often the case with my work but in this case I thought I'd try again.

At the time of the Agile Manifesto, we all did the best we knew. Here's something I wish we had done. (Revised)

One great way to remove an impediment is to replace an old idea with one that's better. Let's give that new idea a new name.

You people could help me by doing a better job and making fewer mistaks.

Semantics is important. Or is it 'are'?

If we can't build software well, all our Agile is for nothing.

Privilege. No privilege. Screw it, improve your situation. Or don't. It's up to you.

Apparently the word 'estimates' is not clear. Here's what I mean and don't mean.

It's not up to Scrum or "Agile" or XP to make you successful or happy. It's on you.

Impediments are there to be removed, not there to be recorded for posterity. Drive them out, don't log them in.

Historically, this was a category for shorter, more edgy articles. I might just bring it back into common use.

Have all your desired features or make an exact date. What's so hard about that?

There are essential practices in Scrum and Agile. Not because we say so. It's the nature of the beast.

Here are a few links relating to collocation, thanks to Adrian Howard and others.

I just thought I'd make a page with links that may be worth exploring. If you have some, let me know. I have not explored all of these, nor, probably, have you. That's why I'm listing them.

Scrum luminaries freely grant the necessity for good developer practices, and the Scrum Alliance is thinking about developer certification. Some important people in the community are involved, and so am I. Read on ...

When terms like Agile or Scrum or TDD get watered down, everyone loses.

A pizza of radius z and thickness a has volume pi*z*z*a. That is all.

We humans like to take a very soft cloud of ideas and give it a name, and then to insist on how good our Named Cloud is compared to some other Named Cloud.

What should an iterative-Agile team do if it appears that not all the stories they signed up for will get done? Is Kanban the answer?

OK, let's talk about when to automate tests for the ten thousandth time. I'm patient, in a manner of speaking. I can keep doing this until you get it.

Scrum's job ends with the problem. Your job begins with the problem.

I don't believe this quite as much as I did when I wrote it. How about you?

Anything as hokey as this title needs to be preserved. Really.

Ward Cunningham posted a video on Technical Debt, and Kent Beck and Ed Yourdon (and I) have been tweeting about it. Let me share some thoughts with you here.

Bad product? Bad customer service? Don't care.

In order to do Scrum or XP or any form of Agile successfully, you must refactor. Sorry, not optional. Necessary.

Let's talk about more about code improvement. Some people seem to think that code improvement has a high associated cost. I think it only has a high cost if we're not very good at it.

Many teams seem to get in trouble because they do not have good technical practices. In Scrum terms, they can't get "Done". Is Scrum flawed because these teams do not "discover" such practices?

Some people think that there is a necessary trade-off between internal code quality, and getting things done rapidly. I believe they are quite mistaken.

The amount of context focus is too damn high!

Let's talk about the importance of pair programming.

How many times do I have to tell you this???

The statement means "I cannot refute your foolish and unrealistic argument but I don't intend to change my mind."

On the leandevelopment list, there has been a bit of a discussion on how long the "backlog" should be, and why.

Pressure only works if I get them done: otherwise it just frustrates me, makes me feel bad, makes me slower still.

When we make decisions based on any kind of "true faith" approach, be it religion, Waterfall, or Agile Zealotry, we know we are right. If things don't work out as we hoped, it's not our fault.

Some thoughts on always carrying a throw-down duck.

Burn stories, not tasks. Don't do tasks. Do stories.

Is a call for more principle behavior going to improve our performance? Frankly, I have my doubts.

As my old friend Charles Bair used to say, that's a two-part question. "How?" and "should user stories be written?" The answer to the second question is "No, not really."

SHORTEN THE ITERATION!!!

Code that slows us down is bad design.

There's nothing like a bean counter when it comes to improving your shopping experience.

Test-Driven Development checks intention. Customer Acceptance Tests check desire.

Scrum works, when it does, because you do just two things.

A link to a gem of an article.

Michael Feathers asks: Are nested classes really a good idea?