As somebody who is interested in Scrum but hasn’t yet had a chance to try it, I’ve been paying attention to the various experiences people are having with it.

I’ve been noticing something for a while, but I didn’t really realize that there was something bigger going on.

I call that phenomena “Scrumbut”. It shows up in the following way:

“We’re doing Scrum but…“

• our sprints are 12 weeks long…


• we do two normal sprints and one bugfix sprint…


• we do all our planning up front…


• we skip the daily meeting…


• our managers decide what’s in each sprint…


• we haven’t read the books yet…


• our team has 30 people…

I’m not a strict methodologist – a specific methodology may need to be adapted to a specific situation. But most of these are anti-scrum rather than modified-scrum.

That this phenomena exists may not be news to you, and it wasn’t to me. But what I realized this last week is that scrumbut has led to another phenomena…

Namely, it has led to scrum being a naughty word. Managers are working with groups that say they are doing scrum, and then when scrumbut doesn’t work, they decide that scrum doesn’t work.

How to approach this? Well, I think you need to advocate specific principles rather than advocating scrum. If you tell your management that you are going to be “ready to release” on a monthly basis and that they get to give feedback on what has been done at what to do next every month, I think you will likely get a better response.

NewsGator – which I use to fetch blog posts – today decided to fetch an August third post for me. At least it’s from this year.

In it, Larry talks about the volume control of a TV going from 0 to 63. And he discusses a possible reason for it, as do many of his readers.

Which brings me to:

Eric’s Law of Arbitrary Limits

If you are designing a piece of tech gear – be it hardware or software – and you need to choose an arbitrary limit or range for something, make sure the limit is either 2^n or 2^n – 1.

The majority of the developers who use your product will convince themselves that you’ve chosen that limit for some well-thought-out reason, such as the internal data structure of your product, rather than just choosing a number because. They will speculate on why you chose that particular number, and you won’t spend your time justifying the limit.

And they will be happy that they understand “the secret” behind why you chose such a strange number…

A while back I came across this post about agile.

I originally was going to write a comment about that post, but I think the commenters have done a good job at that. I will point out that the environment described in the post is a lot like many of the internet boom startups, few of which are around right now.

But in writing some thoughts down, I realized that I was really writing about why I found agile to be interesting. So that’s what this post is about.

I’ve worked on a ton of projects, some short, some long, some small teams, some big teams. But fundamentally, writing software is an exercise in:

• Making progress in the face of imperfect information

and

• Managing change

These shouldn’t be a surprise to anybody. When we start coding, we always have imperfect information. We don’t know if our design will really meet the customer’s needs, we don’t know how long it’s going to take us to write, we don’t know if our architecture is feasible to build, we don’t know if it will perform well enough,  etc. And things will change along the way. Market conditions will change. Customers will modify their priorities. New technology will become available. People will join or leave the team.

There’s a name for trying do something in that sort of environment, and it’s not “engineering”.

It’s research.

Applied research, to be specific.

And doing research requires a different approach than engineering.

Way back in 1961, President Kennedy made his famous “moon speech“.  At that time, the only US astronaut was Alan Shepard, who had flown a 15 minute sub-orbital flight. The ability to send people to the moon seemed out of reach. But the leaders at NASA came up with a plan – they decided on three different programs: Mercury, Gemini, and Apollo. Each program had a theme and a set of goals, and each flight had a set of smaller goals.

Sometimes things worked, sometimes they didn’t. After each flight, they looked at what had happened, decided how to adapt, and went on to the next flight. And over the span of 8 years, they accomplished their goal. All by following the “design a little, build a little, fly a little” approach.

After Apollo, NASA decided to build the shuttle. They did a lot of design up front, made a lot of promises (both schedule and capabilities) and then started building. They ran into lots of difficulties with the main engines (ultimately solved), and the thermal protection system (not really solved). Ultimately, they finished the vehicle, but it took years longer than they expected and ultimately didn’t do what they had designed it to do or what they needed it to do. And it has very high maintenance costs.

The analogy to software development projects should be obvious. Shuttle is like most big software projects – lots of planning up front, lots of promises, followed by delays as problems are addressed, and then the ultimate release of something that doesn’t measure up to the original idea. We convince ourselves that “this time it will be different”, despite the fact that the same thing has happened every time we take this approach.

Incremental development accepts the realities of the environment, and takes a different approach. You know that you don’t know enough to finish the project and you know that things are going to change, so you bite off a manageable portion – say a month’s worth of work – do enough design, write some code, and then see how well it works.

And after that month, you modify your plan based on what you learned.

Design a little
Code a little
Fly a little

That’s what agile means to me.

Yesterday, I had the chance to go on the Kitsap Kolor Klassic (really, the Kitsap Color Classic), but I didn’t.

Excuses were proffered and accepted. I was tired from all the rides I’d done. I needed to work on my deck. I had family committments. All were good.

But in truth, I just didn’t feel like a long ride. So, I went out on a short ride (about 30 miles), and 12 miles into it, my bike converted itself from a 30-speed to a 2-speed through a break in my rear shifter cable (right at the shift lever). And since you can’t run a chain from the small chainwheel to the small sprocket in the back without a lot of mechanical pain (and risk of chain break), neither of the gears I had were of much use.

A quick look around showed that Richard Dean Anderson was nowhere in sight, so I jury-rigged the shift cable. Here’s what you do:

1. Shift the bike onto the largest sprocket by pushing the derailuer by hand (watch out for the point parts)
2. Bend the cable in half sharply in the middle of the exposed section on the downtube.
3. Tie the bent cable into a single knot. This gives you a loop tied into the cable.
4. Loop the remaining cable around the front attachment for the cable (where the cable comes out of the sheath from the shifter), back through the loop, and pull it tight.
5. Wrap the cable around itself, put it back through the loop, and arrange it so it won’t perform minor surgery on your leg as you pedal.
6. Ride. You may have to readjust it as you go.

Happy was I that this didn’t happen in the middle of a long supported ride. My laziness saved the day!