In Agile sprints and cycling, a hill can be your friend

“They didn’t mention this in the brochure!”

My wife and I were three days into a 400-mile bicycle trip across New York State along the Erie Canal with about 450 other riders. Except for the occasional lock here and there, canals are generally flat. At least that’s what the marketing implied.

Neither of us are what you would call “cyclists,” and while we did some training beforehand, much of the appeal of the ride was that it would be along the historic waterway in scenic upstate New York. Much to our surprise, there were sections of the route that veered away from the canal proper and into some of the more hilly sections of the state.


Chick Rubenau cycling along the Erie Canal in New York State

The first couple of days after leaving Buffalo were smooth riding with level trails along the banks of the canal. But somewhere outside of Palmyra we rounded a corner and came upon a large hill. The first of many on our trip!

While we weren’t necessarily looking forward to such challenging, grueling climbs in the torturous, sweltering heat of mid-July (I hope I’m amping this up enough), we came to realize that while cycling on the flat sounds ideal, there is a certain sameness to it, a repetitive cadence that can be tiring in its own way. Sure, there are no hills to climb, but there are also no chances to coast, to give yourself a bit of a break.

Your Scrum sprint teams may be feeling that same kind of burnout. When you’re in the midst of an extended series of sprints, you can work yourself into a cadence that promotes a focused level of effort and increased output. That’s good. It’s one of primary upsides of time-boxed development. But over time it can also be draining without some kind of change up.

Sure, you could spend a couple weeks vacationing in Cancun lathered up in SP-50 to protect your pale programmer skin, but what about the rest of your team?   As a group you may benefit from mixing it up a bit, some hill climbing and some coasting for a stretch.

We had a break in our routine at work these past couple of weeks. There was a bit of a push as we tied up a new release followed by a couple-week break from daily stand up meetings and other Scrum ceremonies to take some time to discuss and plan at a high level our next release cycle. We also had our first ever company hack-a-thon (with t-shirts), a three-day free-for-all of coding and research into new development skills of our own choosing.

After some hill climbing and a bit of coasting we’ll be reinvigorated and ready to get back into a groove.  We’ll be back to heads down development, pedaling on the flat with our predictable cadence of two-week sprints and daily stand ups as we begin anew, churning out fresh projects and features.

If you’re ever looking for a unique summer vacation, I highly recommend the Cycling the Erie Canal annual event. You’ll meet some fantastic people, experience history up close, and see some of the best scenery that upstate New York has to offer!

And those hills? You’ll be fine… until you hit Canajoharie!

Celebrating Pi Day with frozen hot dogs

If you’re in a hurry and just want to hear about the frozen hot dogs, feel free to skip to the “But what about the hot dogs?” section… or kick back for a little background on how we got there.

Today is one of the geekier days of the year: Pi Day. And this year it’s extra geeky because not only do the month and day match up with 3.14, but 2015 also gives us 3-14-15 9:26:53.

I’m sure we all have our own personal pi stories, but for me, these two from the Freaks and Geeks days of my teen years come to mind…

A couple bored kids in study hall

It was junior year in high school and my friend Jeff Applebee and I entered into a cerebral duel of sorts to see who could memorize the most digits of pi.

We used two different approaches:

I got some pointers from The Memory Book written by former pro basketball player Jerry Lucas and some other guy whose name escapes me at the moment. Their technique involves associating a consonant sound with each digits 0-9 and then crafting a story in your mind by chaining objects with the consonants corresponding to the digits in the sequence. The more fanciful the story, the easier to remember and convert to the digits of pi.

A book from the 1970s that I still have

A book from the 1970s that I still have

Jeff didn’t need no stinkin’ book (show off), he just sucked it up and memorized the sequence.

Given the fog of time, the exact count escapes me, but I seem to remember we each wound up memorizing around 150 digits. But in the end, it was Jeff’s brute force approach that claimed honors.

Pi out to 150 decimal places:


Let’s code!

Around the same time I got this idea that you could calculate the value of pi by writing a program to generate millions of random points in a square, and by using the Pythagorean theorem, easily calculate if each point was either inside or outside a section of a circle contained within the square.

A diagram with a lot of 2's and lowercase letters on it

A diagram with a lot of 2’s and lowercase letters on it

By using the ratio of points that fell inside the circle and given the formulas for the area of a circle and the square, you could solve for pi. The more points generated, the closer your estimate would be.

With the hubris of youth I fancied myself quite the Einstein for coming up with the idea only to find out later it’s a well-known way to estimate pi called the Monte Carlo Method. There are a slew of articles on the web about how it’s done. Here’s a quick C# method that estimates pi using 10,000,000 random points:

Some C# code that estimates pi

Some C# code that estimates pi

But what about the frozen hot dogs?

I thought you’d never ask.

After doing some Googling to prep for this article and reacquaint myself with the Monte Carlo Method, I saw a few links for “throwing frozen hot dogs.” Click bait? Nope. It actually works.

It’s quite simple and involves basic math, some tape, and a few frozen franks.

First, get some masking or painters tape and mark off a bunch of lines on the floor making sure that the space between the lines is exactly the length of a hot dog. Actually, first you should tell your wife what you’re doing and that you’ll clean things up when you’re done.


Throw a bunch of hot dogs


Keep a count of the total number of dogs thrown and the number that cross any of the pieces of tape.

Pick up the hot dogs and throw them again.

When you’ve had enough (or the cats lose interest), you’ll have two numbers: the total number thrown and the number of hot dogs that landed on a line. Divide 2 by the number of dogs that landed on a line and multiple that result by the number thrown. Of the 300 dogs I threw as a test, 193 crossed a line… (2 / 193) * 300 = 3.108807. Not bad.

If you’re going to try this yourself, frozen hot dogs are COLD and they slide around a little too much on the floor, and dogs at room temperature start to break apart after a few throws.  So “gently thawed” works best.

Happy Pi Day!


11 tips for Scrum team buy-in

If you’re thinking about adding Scrum as part of your software development process (and who isn’t these days), one of the key considerations in rolling it out is getting some level of buy-in from the team. Scrum is often “sold” as an empowerment tool for the rank and file, but it’s not always perceived that way by the staff.

We started using Scrum nearly two years ago, and there was definitely an “adjustment period” in crafting a day-to-day plan that worked for us. After 40+ sprints, here are some of the hurdles we encountered along the way, what we learned, what we did and didn’t like, and tips that may help others become believers in the process.

1. Let it be the team’s idea

Wait… don’t tap out yet!

Yes, the “We’re going to start using Scrum!” stone tablets may have already been delivered from on-high to your group, but even if you’re in the beginning stages of adopting an Agile/Scrum approach, having early champions come from the ranks will help with overall acceptance of the process. If you’re a manager, work at getting some buy-in from key staff to help your cause. In our group, the initial thought that Scrum might be the way to go for us came from a senior developer, and that certainly helped.

2. You will not get this right the first time

Read all the books and web articles on the process you can. If your company will spring for it, go to a week-long class off site. Knock yourself out. All of that will help, but the actual experience of getting a team up to speed will take many sprints, and you will have to make adjustments along the way. Team members will groan and roll their eyes from time to time as you collectively put the pieces together. If everyone from stakeholders on down view it as an evolving process, getting into a groove will be less painful.

3. Walk before you run

Don’t throw every piece of the process at your team during the first sprint. At worst they may freak out, but more likely they’ll just feel overwhelmed, and the mere effort of incorporating the process will become their main focus to the detriment of actual work getting done.

4. Start with paper swim lanes

Our first couple of sprints were a bunch of sticky notes on a whiteboard with some basic swim lanes for Todo, Coding, Testing, and Done. And we weren’t even that conscientious about moving the notes around. The idea was to get used to having progress tracked openly by the whole team and visually gauging how we were doing. We’d add in stickies without team approval, etc., all the things you shouldn’t be doing, but it did help us become familiar with the cadence of Scrum and breaking projects into sprints.

4. Don’t let a bad tool derail the process

Experiment with a couple of software tools for managing the process. Since we’re a Microsoft shop and live inside Visual Studio, we started with the Agile Scrum tools that Team Foundation Server (TFS) offers. For whatever reason, possibly because we were new to Scrum, we became frustrated trying to shoehorn that particular tool into our team’s workflow. It just did not work for us. Once we switched to Jira, it no longer felt like we were fighting the process.

6. Hold off on using story points

Tracking progress by assigning story points is a key part of Scrum, but it can also trip teams up. There can be a paranoia factor, that management may be concerned solely with numbers, velocity, and burn down charts. Also teams can struggle with the notion that the points are intended to be more of a slushy, relative weighting than hard and fast hours of effort.

Once we started storypointing as a team, the whole process finally fell into place for me. Yes, you’ll soldier through the “What does a 5 really mean?” debates more than once, and it will take staff a while to get loose with estimating this way, but you’ll get there.

7. Suck it up, have the daily meetings

This can be one of the most contentious part of Scrum for a team.

  • “Just look at the board, you can see what I’m working on!”
  • “We don’t need to hear about every line of code Joe added yesterday!”
  • “We’re not children!”

This is something the team should start doing from day one (the meetings, not the whining). As a manager, this can be the one time you say to your group, “I know this seems like overkill, but trust me on this, just give it a try.”

8. Keep daily meetings time boxed but loose

To help with buy-in of the daily standups, make sure they’re kept to 15 minutes max, but allow for some flexibility on how they’re run. Our meetings have shifted from the traditional “I did this yesterday, I’ll do this today, and I have this impediment” to a more relaxed conversation focusing mostly on impediments and questions. You’ll have the boards and charts to look at during the meeting to see how tasks are moving along.

9. No stakeholder input during daily meetings

If you have higher-ups turning daily team standups into “can you get {insert feature here} done by Friday?” status meetings, you’re doomed. The team will resent it and, in turn, the whole process. Anyone can listen in, but only members of the team should speak. This was not a huge issue for us, but it’s something to be mindful of.

10. Piggy back ceremonies onto daily standups

Early on there was a bit of a “death by meetings” vibe with the daily standups, the retrospectives, the reviews, the backlog refinements, the planning. We found combining meetings where it made sense helped. For example, instead of doing a daily standup and then backlog refinement a half an hour later, all of the Scrum “ceremonies” are piggybacked onto our daily standups. As a result, we only ever meet once a day.

11. Don’t skip the retrospectives

Sadly, in most corporate environments, there are few opportunities for rank and file to get together and discuss what is and isn’t working. Scrum incorporates those types of water cooler conversations as a formal part of the process. These retrospectives at the end of each sprint are vital. Not to get too Oprah-esque here, but a core human need is to be heard and understood, and that’s a key part of buy-in for any team whether it be Scrum or otherwise.

So… take it slowly, expect an evolving process, keep lines of communication open, and view implementing Scrum as a collaborative, team effort. And one day you may scratch your head and wonder how on Earth you ever developed software without it.

Chasing the Ace… and the odds

For years at work, our activities committee (fondly referred to as “The Fun Club”) has held a 50/50 raffle each Friday. A few months back they decided to mix things up a bit by replacing that with something called “Chase the Ace.”

The rules are pretty simple:

  • Tickets are a dollar a piece.
  • A single ticket is drawn each Friday.
  • The ticket holder draws a card from a deck.
  • If it’s an ace, you win half the pot. If not, all the money rolls over to the next week.
  • Rinse and repeat until an ace is drawn.

This all sounded fine and good until weeks and weeks passed with nobody drawing an ace. In fact, we got up to 15, 16, 17 weeks… and still no ace! Seriously? Wouldn’t the odds of that happening be infinitesimal? Were we somehow being hoodwinked by some nefarious faction in the Fun Club?

With some rusty high school probability theory rattling around in our brains and Excel just a click away, a couple of us computer nerds went to work to find out just how unlikely this really was. We set up a simple spreadsheet with formulas to calculate the odds of pulling an ace up to and including 49 pulls (the worst possible outcome).


First let’s look at the odds of pulling an ace for each individual week.


With a full deck, the first week odds of not pulling an ace are 48/52 or 12/13 or 92.3%. So, of course, the first week your odds are pretty slim. That makes sense. The second week, the odds aren’t much better: 47/51 or 92.1%. It turns out it takes quite a few weeks before the odds of any given week reach some reasonable chance. In fact, to get to a 50/50 chance, you’d have to wait until there are only 8 cards left in the deck!

But those are the week-to-week odds. We all know that if you flip a coin 99 times and get heads each time, the odds of getting heads on flip 100 is still 50/50. But it would be crazy unlikely to get that far in without flipping a single tails. Similarly, wouldn’t compounding a long series of ace “no pulls” escalate in our favor pretty quickly?

Here’s the graph for the compounded probability week-to-week. The blue line is the one we’re interested in. At week 17, the odds are about 1/5 (20%) that no ace would have been drawn to that point. Yes, it’s less likely that this would happen, but it’s still within the realm of believability and certainly not infinitesimal.


The blue line shows the odds if the card pulled each week is not replaced in the deck. For comparison, the green line shows the odds if the card was being drawn from a full deck each week.

So with that, the nerds went back to work, the Fun Club was cleared of any suspicion of hoodwinking, and the pot of cash kept growing.

The new Kindle Voyage is a winner

It looks like Amazon still feels there’s life left in the dedicated e-reader market, so much so that people will be willing to plunk down $200 for one. At least they hope. Yes, the newly released Voyage is pricey for a device that only lets you read books in black and white, but I’m sold.

I bought the first version of the Kindle Paperwhite a couple years ago and I wanted so much to like it. The promise of a backlit screen that would make the display more “white” and easier to read in low lighting was a real draw. But I was really disappointed with the unevenness of the light emanating from the bottom of the device.

Continue reading

What’s in your woodpile?

It’s fall, and up north that means putting the deck furniture away and stacking the firewood high. My personal woodpile is not one of necessity to stay warm during the winter months, nor one that was actually assembled with much effort. Throughout the summer I leisurely cut and split about a cord of wood in preparation for the maple syrup season the following February.

A few days back I posted a picture on Facebook along with the Thoreau quote: “Every man looks upon his wood pile with a sort of affection.”  As I kept checking back to see how many likes and comments it generated as validation of my self worth, I began to reflect back on the pile and its genesis. It did have something to say…

Continue reading

Bacon Sausage? Mmmm……

I’m not prone to grammar and punctuation policing, mostly because I’d be throwing stones from my glass house. But, a recent visit to a Pennsylvania diner got me thinking about commas and the like.

Scanning the menu, “Bacon Sausage” caught my eye! I wondered what bacon sausage was? It sounded awesome! Then I realized that the anticipated awesomeness that I was about to order was the result of a missing comma. Bummer.

Continue reading

Thoreau’s Walden turns 160

I know… yawn.

It’s an old, boring book you were forced to read in high school, written by some bloviating crank in old clothes prattling on about ants, swamps, and the howling winds of winter. I get it.

Walden can be a bit of a slog to get through at times, but Henry David Thoreau’s view of the world just may be the perfect antidote if you’re looking to make sense of today’s hyper-connected, fast-paced, complex world.

This month marks the 160th anniversary of the first publication of Walden.

Continue reading

Revisiting the Bee Gees of home computers, the TRS-80

I was fourteen years old in 1977 when John Travolta strutted his stuff on the dance floor in Saturday Night Fever and the Bee Gees’ hits from the film’s score ruled the top 40 charts. The high falsettos of the brothers Gibb could do no wrong as they rhetorically asked How Deep is Your Love? and suggested that You Should be Dancing… yeah!

But it only took a few years before the crest of disco they were riding in flared-bottom, bejewelled, polyester pants would crash, and the three boys from down under would be the butt of many, many jokes, even by those of us who still had the double 8-track of the movie’s soundtrack tucked away safely for the sake of nostalgia.

Radio Shack’s TR-80 personal computer would suffer a similar fate.

Continue reading

Is Google Street View ruining your vacation?

Earlier this month I took a road trip / pilgrimage to Indiana for GearFest, a big two-day music and sound event at Sweetwater’s facility in Fort Wayne. If you’re ever in need of any pro audio or music-related gear or just some advice, these guys are the real deal, and Sweetwater is one of the most customer-focused companies around.

Anyway, on my drive back I planned a couple of sightseeing stops along the way to break up the monotony (no offense Indiana and western Ohio, but you are flat and your roads are seriously straight).

Continue reading

Pimp your burndown chart!

Ah, yes… our friend the burndown chart, a daily reminder of how a scrum development team is progressing in its current sprint. If things are going swimmingly, they’re fun. If you feel like you’re drowning, not so much.

In general, I’m a fan. Starting each daily sprint meeting with a look at the chart gives the team a nice visual indication of progress (or lack thereof). They’re best used as a tool for self-policing developer teams within the confines of a single sprint, while management and stakeholders may find more benefit in the longer term velocity and burnup charts that track the project as a whole.

But, back to the burndown… here’s a sample chart from one of our recent sprints:


The progress looks good, but not great, right? Why aren’t we following the gray goal line? Are we behind? Well, actually, it’s hard to tell. Mostly because the goal line is what I like to think of as an “arbitrary line of hope,” particularly if what you are tracking are completed story points. If we were charting remaining estimated hours of effort (which some scrum teams adjust daily regardless of story completion) we may be able to get close to the “ideal” line, but it doesn’t work as well with fixed story points.

Our team only burns down fully-coded and tested stories, which is a more accurate reflection of what’s happening if the end goal is completeness. But, since it’s tough to finish coding and testing complete stories in the first day or two of a sprint, the graph line will almost always be above the arbitrary line of hope. This could lead to two things: either the team is in a perpetual state of bummed-out-ed-ness because they’re never near the goal (which isn’t good), or they slack off because, “hey, we’re always above the line anyway” (which isn’t good).

How about a “realistic line of hope” that mirrors past performance of the team, something like a rolling average of the last four sprints. The team could then easily compare their progress over the course of the sprint instead of waiting for longer-term velocity charts.

So, something more along these lines:


Ah, yes… much better!

The two charts show the same progress, but the second one shows us that we’re not only on track, but actually doing a little better than average.

That’s a chart I wouldn’t mind looking at every morning.

Scrum and the meaning of ‘done’

We’ve been easing our way into implementing some facets of Agile development using Scrum over the past year at work, and it’s been an interesting ride. As expected, there have been some bumps along the way as we try to fine-tune the process to meet our company and development staff culture, but after 20 sprints, we’ve settled into some patterns that are helping us be more productive and focused.

One of the key upsides for me is the goal to have releasable software at the end of each sprint (we’re running two-week sprints in our group). That means coded, tested software that’s (theoretically) ready to ship. So, when the phrases “done” and “done DONE” come up, I can’t help but think back to a home renovation project from years ago.

My wife, Chick, had to be out of town for a week, so I decided it would be a good time to gut the upstairs bath and laundry room. This would include shifting an interior wall, relocating the plumbing and electrical for the washer and dryer, and running a new dryer exhaust — a fairly substantial undertaking. This was all in the days before Facebook and smart phones, so I wasn’t dashing off any status pictures, but toward the end of the week I did call her to happily report, quote, “the laundry room is done!”

Then she came home.

As I proudly showed her the new layout and pointed out how the hose connections were up higher so they could be more easily turned on and off, she apparently was more focused on the plywood flooring and unfinished sheetrock walls.

“I thought you said it was done?”

“Well… it’s not done… DONE, but we can do laundry!”

As it turned out, the room didn’t actually make it to the “DONE” state until many years later, at a point when a lot of home projects get finished: two days before we put the house on the market!

But we and that room deserved better. Laundry rooms need tile floors and painted walls and trim, and so does the software we deliver to our customers. Just being able to “do the laundry” isn’t enough. And for software, the continued focus on finished product at the end of each sprint is a great reminder that completeness is important.