I Haven’t Gotten This Feeling From Software in a While

Yesterday, I was using Excel to fill out a list of names and e-mails. As I was happily (well not really, I was typing in a bunch of email addresses) going about my business, I accidentally came upon a feature of Excel I’ve never seen before (more about that in a bit).  Now, I should come clean and say that I’m not an everyday user of Excel, and I am certainly not what I’d call a power user.  I’ll bet there are a lot of people who know about this feature, but it was new to me.

The thing that made this stick out was that it just came out of nowhere while I was using the program.  I’ve seen other pieces of software do that and only end up creating a jarring experience for the user; this was seamlessly done.  Most importantly, it helped me get my task done faster, and to me, that’s what software is supposed to do.  This is a place where the folks delivering Excel did something that made my job easier in a really nice and unexpected way.  I need to challenge myself to do this for my users more often.

So what was the feature?  Check it out.  Keep in mind this is a reenactment (so I don’t share a bunch of IDT employee emails. You’re welcome).  The actual list of e-mails I was adding was much longer, so the time it saved me was significant.

(P.S. If anyone from Microsoft reads this, if 2013 had the feature, I’d have definitely given you a smile yesterday!)

Had a Great Time at Iowa Code Camp

Iowa Code Camp SymbolIt really goes without saying, but I had a fantastic time at Iowa Code Camp on Saturday.  It’s always a great reminder of the amazing folks who work in technology here in the Midwest.  Code Camp is often the only chance I get to talk to some of these folks every year, so it’s always awesome to catch up.

I attended some great talks and had some really great conversations just sitting around the tables between talks.  This is always such a great event.

So let me thank the people who came and listened to my talk.  I really appreciate you being there and hope that I was able to give you even one piece of information you can take back to your work to make things better for your team.  If so, then I feel my time was well spent.

I also want to thank all the people who volunteer their time to put the event together twice a year as well as the folks who come in from all over the place to share what they’ve learned.  You are all truly an amazing bunch of folks.

If you couldn’t make it, look for the next one coming this fall in Des Moines.  I’d love to see you there!

Agile Methodologies Aren’t Calvinball…

There are a lot of people who seem to think that agile project management means there aren’t any rules, and you simply do whatever you feel like to get software deployed. My best guess is that attitude comes from reading the agile manifesto and the twelve principles of agile without actually understanding what they’re saying.

It seems that people are over-focusing on phrases like “maximizing the amount of work not done” and “working software is the primary measure of progress.”  By cherry picking phrases and taking them completely out of context, agile can be twisted into something dark and evil.

I’ve listened to people justify horrible software practices by saying that they’re “more agile” because it helps them deploy software more quickly.  Never mind that what they’re delivering is riddled with bugs and not remotely what the users needed.  “No, I couldn’t actually test the software.  It had to be ready for the sprint review!”

When I hear things like that, I’m reminded of my favorite comic strip growing up: Calvin and Hobbes by Bill Watterson.  From time to time Calvin and his best friend, and stuffed tiger, Hobbes would play a game of their own creation called Calvinball.  In Calvinball there are two rules.

A) The rules are made up as you play, and new rules can be decreed at any time.
2) Calvinball cannot be played the same way twice.
(There also seems to be a rule that you have to wear a mask, but that should just be obvious)

So from now on, when I hear people describing their agile implementations and explaining why testing is a waste of time, customer interaction is stupid because they know what the customers need better than the customers do themselves, or that iterations are for wussies, I’m going to refer to them as Calvinball agile implementations.

Now we just need to get them to wear the masks.

Planning with Scrum – Flexing on Date

In this series of posts, I’ll be addressing the misconception that it’s not possible to plan releases using agile methodologies.  In a previous post, I talked about the three sides of the “Iron Triangle” that can be adjusted when project milestones start slipping.  In this post, I’ll talk about planning releases for a Scrum team where schedule (time) is flexible.

Why Flex Schedule?

The most common reason a team would want to flex schedule instead of scope is when they are running a parity project; a project that is replacing the functionality of an existing system.  Ideally the team would still only replace portions of the system at a time and use this method to plan each release.  However, this planning method works even if this is not possible and an entire system needs to be released at once.


As with flexing on scope, this kind of planning requires two things.  First, that you have a well-groomed and prioritized product backlog.  Second, it requires the team to have been sprinting long enough to have a fairly predictable velocity.  Lacking these prerequisites will reduce the accuracy of this method of planning.

Best and Worst Case Scenarios

Another similarity to flexing on scope is that this planning method requires a team to determine their best and worst case velocities.  Rather than restating how to do that, I’m just going to refer back to the post on flexing on scope.


Planning for fixed scope is very straightforward.  Simply add up the effort for all the backlog items that need to be in the release.  We then essentially build a burn down chart for the release, plotting the projected burn given the team’s average velocity.  After we’ve determined what the average burn looks like, we also draw lines for the best and worst case velocities.  Now we’ve got a range of time that can be reported for completion.  In the example below, we would expect the release to be finished in 5 to 8 sprints or so.

Planning with flexible schedule

Just like with flexing on scope, we would update this burn with current data after each sprint.  This will cause the date range to narrow as we get closer to completion.

What About Scope Creep?

Interestingly, I often hear the term “fixed scope” when what is really meant is “minimum scope.”  The scope is rarely actually fixed; there are often requirements that have been missed, and in parity projects, not implementing those requirements isn’t usually an option.

What’s the best way to account for requirements that have been added to the release?  Ok, maybe best way is a bit optimistic, but here’s how I do it.  Let’s say we’re working the release from the chart above and 75 points worth of scope gets added to the release during the second sprint.  I prefer adding the new scope below the original x-axis.  This visually differentiates schedule changes based on newly introduced scope from those based on varying velocity.  It’s important for stakeholders to understand the consequences of changes in scope and not blame changing schedules on “developer laziness.”

After adding the scope to the graph, we now draw a new baseline to get the expected schedule.  We can now clearly see that adding 75 points to the scope pushed our delivery dates out to somewhere between 5.5 and 9 sprints from our start date.

Dealing with scope change

I hope you find these planning techniques helpful.  Let me know if there are other situations you run into that make planning difficult.

There’s still time to register for the Iowa Code Camp!

Iowa Code Camp SymbolTime is running out, but it’s not too late!  Code Camp is coming up on Saturday, May 9th.  It’s a lineup of great speakers and it’s free!  I’ve been to a ton of these and they are always a great time.

I’ll be there, and you should too.  Come sign up here!

Iowa Code Camp Registration

Also, don’t forget that there’s always a great after party.  Free food.  Free beer.  Be there!