BOSS logic

Low IQ connection

I found this post interesting, although the lack of citation means that it’s potentially meaningless. But the graphic somehow explains a lot:

What I really identified with, though, is not the fancy chart that shows how red states tend to have lower IQs, but some of the comments posted by other readers. The fact that the majority [...]

The agile disease

Luke Halliwell recently wrote an exceptional piece titled The Agile Disease. And, as someone that pushes this disease in various forms, you might be surprised to hear that I agree with just about everything he’s written on the topic, save a few points. For example, the commercial trendiness of Agile and its “manifesto” is just [...]

Tell me thrice

In certain military contexts there’s the concept of “tell me three times,” a form of checksum that eliminates error by introducing redundancy. This is something I’ve been meaning to write a meaningful piece on for a while — and this diagram is at the root of it. It’s an integral part to any complete process… [...]

Finding strategic learning funds

Training Industry Times recently published some rather disappointing statistics: Over 92% of surveyed business have experienced pressure to reduce their training budget in 2007. Worse, 56% reported that the pressure to reduce or altogether cut training costs were “significant.”
Is this attitude regarding education part-and-parcel of the declining attitude toward education in the United States? More [...]

Whiteboard-space to wall-space (WBS/WS) ratio

Patrick Wilson Welsh has a great little rant on this really incomprehensible trend. I think the root of the problem is that too many companies still think of software development as an industrial, assembly line process and too few have really embraced the idea that it’s a creative effort. That might be why it’s called [...]

Recommended reading

If you want to learn about Scrum there are two books I recommend. Well, more than recommend: These are, in my mind, the definitive works on the subject. They’re both an easy read and if, like me, you get engrossed you’ll probably mark them up extensively and finish the set in a weekend.
Agile Software [...]

Rational Scrum

Recently I tried out a variant on methodology that I’ll dub Rational Scrum. I’ve been trying to put together a few thoughts about the overall process for months, and finally found some time for it.
Just as people have specializations, so do processes. Applying one process to all situations is just as wrong as calling your [...]

Whole teams

Creating a cohesive whole team means building a project team with representation from all stakeholders in the project. Doing so requires both defining the team and creating involvement. It also means creating a structure for involvement that does not slow the project down. Creating this environment of constant, informed involvement does not mean throwing everyone into long (and ultimately unproductive) meetings every day.

Coehesive teams

I really liked this post by Patrick Wilson Welsh about the The Fallacy of Individual Accomplishment. Yes it’s true, your heads-down cubicle dwelling knowledge hoarders are more of a liability than an asset. And while we’re here, let’s all just recite: “Hero Culture Is Bad.”

The case for certification

I had to read the Agile Alliance’s position on certification a few times before I could decide whether I liked their position or not. Part of this is that the opinion is not that well written. Getting past that, I came away with these core statements:

Employers should not require certification.
Non-skill-based certification testing procedures have little [...]

Formal inspection: an introduction

Formal inspection is a defect detection, removal and correction verification process carried out by a small group during the pre-test phases of the development life cycle. The primary objective of formal inspections is to remove defects as early as possible in the development process. This is a brief introduction into formal inspections and the background behind them.

Don’t ship broken software

There are two kinds of organizations: Those that ship faulty software, and those that don’t. Unfortunately, trying to change from one that does ship faulty software to one that does not is nearly impossible. Why is it that changing into a “defect free” organization so difficult?