I’ve been doing software development professionally for the last 25 years, almost exclusively in the Cleveland-Akron area, mostly with medium-size to large companies, and over the past ten years mostly with .NET Microsoft shops. About two thirds of them are proud to proclaim they’re “Agile.”

All told, I’ve seen how about eighty different organizations approach development. Narrowing down a bit, I’d say I’ve done relatively long-term projects with about a dozen reasonably large companies with “Agile” shops (generally all Scrum-based) in the past ten years.

This is another item in my ongoing series of “How to Mess Up Scrum.” This time, I turn your attention to…

Overcomplicating the Objective

Let me give you an example. A few years ago, I was on a Scrum team that was assigned to develop a “retail portal” for the services this company already sold at old-fashioned store locations. In “phase one” the goal was to put up half a dozen or so static pages, plus one “contact” page to capture basic information so our sales rep can call you soon. That’s all.

Some Scrum teams–whether formally or informally–have a recurring “hardening” sprint after every few regular sprints, in which they fix outstanding defects and make the system actually ready for delivery. This is a bad idea. Here’s why.

If you care about why you are “doing Agile,” you should care about the principles of Agile development, which include “early and continuous delivery
of valuable software.” Delivery. If you’re not continuously delivering software, you’re not Agile.

If you have legacy defects, which are any defects not tied to a current story, then those defects need to be made stories in their own right. If your current stories are implemented with defects, they are not done and you have no business considering them completed. If you haven’t integrated a pipeline from development to deployment, that is infrastructure! It’s not part of a sprint!

Make every sprint a “hardening sprint.” That way you always have a product to deliver. That way you are never wrong.

I do lots and lots of development with the .NET platform, mainly because the corporations in the Cleveland area that have money to fund large projects are Microsoft shops.

I used to have a real problem with Microsoft development, back when it was all Windows 95; the tools were expensive, flaky, and unreliable. Since then, the tools have improved to an amazing degree; now I can write code that actually works consistently on more than one computer, and it’s not utterly ridiculous to run Windows on servers anymore. So there’s that.

But in just the last couple of days, I’ve gotten back into the Ruby on Rails environment. Partly, I’m jamming with my college homie Dave Stagner on his amazing Congruence product; and also, I had to update this old Perl script that I’ve been using for years to sort my incoming email.

Failure to Prioritize

You know what? Humans aren’t that smart. We can think a lot about a given thing, but we’re not good at thinking about everything at once. Agile development recognizes that by letting us do just one, or perhaps two, things at a time and put aside the things that aren’t immediate. “Do today’s work today!” we say. “Do the simplest thing that could possibly work!” we say.

Those aren’t just cute slogans. They are reminders of how limited we are in our brilliance.More →

I saw this and just wanted to share it. What a great summary of how Agile development so often goes wrong!

I love this part in particular:

There needs to be an absolute lack of fear around punishment or reprisal for negative information.

Someone who fears reprisal will withhold information. This is especially significant on under-performing or troubled teams.

Look at teams that are behind schedule (and not by a small amount), and you’ll tend to find that people usually know what the problem is. Yet if they’re not able to communicate that, well, things go south quick.

Continuing in the series of How to Mess Up Scrum!

Last time I explained how adding work in the middle of the sprint wrecks the rhythm of the team and undermines the concept of setting priorities.

Long story short, if you’re management and your highest-priority requirements repeatedly become visible to you in a shorter time frame than the length of a sprint, your sprints are too long! Finally, if you can’t make your sprints short enough to accommodate changes that are truly of the highest priority… then Scrum is not for you.

But let me talk about another great way to mess up Scrum, if that’s what you insist on doing.