Category Archives: Software Development

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!

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.

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.

Driving and software… idiots and maniacs

We’ve been getting our fair share of snow this winter in upstate New York, and on those particularly bad morning commutes, the dreaded “idiots and maniacs” pattern is on display in all its glory.

There are the overly cautious drivers creeping in front of you (idiots), and the NASCAR wannabes lapping you in the passing lane or riding your tail (maniacs). And we, with all our prudence and common sense plod along smugly with our morning coffee rolling our eyes at the outliers.

Continue reading

1 Reason is so cool

Even though I’m only offering up one cool thing about Time Magazine’s web site (I’m sure I could find more if I really tried), it seems the best way to get anybody to read anything these days is to make a list out of it.

So here’s my list:

1. Copy and paste a snippet from one of their articles into an email or document!

How many times have you been reading something awesome on the web and you’d like to send it to a friend? You could find the appropriate “share” button on the page, but you’re not sure exactly what will get sent in the email message, or what the site will do with the email address you provide. Too many unknowns.

And what if you want to include a specific snippet from the article in the message, to entice your busy friend to actually click the link and read the article? To accomplish that you have to copy and paste the snippet, and then copy and paste the article’s URL, and then if you want, add in some friendly link in your email instead of just the raw URL. It takes effort. Effort you can’t afford because there are 22 Cats Who Are Too Proud To Admit They Hate Snow on BuzzFeed that you need to get to. has *solved your pesky inconvenience!

Just copy a sentence or two from any article on their site and paste it into your favorite email or word processing app. Not only is the text copied, but also a line stating “Read more:” with a subject link and URL to the article. When I first saw that bit of magic, it made my day.

Sometimes it’s the small things. And, it’s not so much that Time is saving us a ton of time by adding this feature. But when a web site or app, a store or restaurant can make the mundane processes of life just a little easier, we smile… and we remember.

* Some other sites are doing this as well

What’s up with that room?

There’s a point in every software project where you take that first step into the “Oh crap!” zone. As a coder, you’ve worked out how you’re going to layer and abstract your modules, the naming conventions and project folder layouts are perfect, and you’re coding away in earnest with a big ‘ole smile on your face. You think, finally, a project that will be easy to maintain and extend!

Aren’t you cute.

Then that big gotcha comes along that you need to shoehorn in to your masterpiece. Some customer-driven “why the heck would they want to do that!?” enhancement, some third party software package you need to interface with, a new last minute “gotta have” from your marketing department.

When I was looking out from my hotel room in New Orleans recently, all I could think of was the architect who designed the Sheraton and how that bank of windows in the upper floors came to be. Was this part of the original design or some last minute executive request… “We need a big conference room on the 30th floor!”?

I guess we software developers aren’t unique in having to “make do” sometimes, and need to be flexible enough to accommodate change and unknowns that suddenly become known. And we can hope that our original “perfect” design, while dinged up a bit here and there, will help make those changes possible.

This came across by Facebook feed a few days ago…

“Much of the pain in life comes from having a life plan that you’ve fallen in love with, and when it doesn’t work out, you become angry that you now have to pursue a new life plan. If you want to tame your inner demons, you must not become too attached to any particular life plan, and remain open to there being an even better happier life plan.”

I’d still love to know what that room is high up in the New Orleans Sheraton… and whose idea it was.

Rethinking software… and dishwashers

We’ve been spending a fair amount of time at the office shifting parts of our legacy Windows-based software to a web-based, cloud solution. Part of that process involves working with some UX designers from outside of the company to help us rethink some of the workflow decisions we made more than a decade ago. It’s interesting what a fresh set of eyes can do when it comes to crafting “better ways” to perform certain tasks.

It’s sort of like an issue I’ve had with our dishwasher. We’ve all dealt with it: the water that accumulates in the wells of the bottom of the glasses. Ugh! And when you pull out the top rack, you’ve got to take great pains to not jiggle anything because water may fall on the already dry dishes below. And forget about actually removing the glasses, particularly if they’re near the back of the rack.

There are a few things you can do to help mitigate this vexing nuisance, like leaning the glasses when you load them in such a way that a minimum amount of water accumulates. Or, I suppose, you could put anything with that type of well in the lower rack, but Mother always said glasses went in the top (I was never quite sure why).

But, like some new, elegant software workflow design feature, there is a simple “why didn’t I think of that?” solution… Unload the bottom rack first!

Another major first world problem solved!

Or, I could have just followed the lead of my nephew, Richie, who as a puzzled nine-year-old once asked me, “How come you’re unloading the dishwasher? Isn’t that Aunt Chick’s job?”

Build 666?

I was doing a bit of HTML trouble-shooting on a customer’s Wyse thin client this week, running IE 6.0 of all things. Argh!!

Anyway, as I was trying to figure out how to get the thing out of kiosk mode, I noticed the build number on the OS release was 666. Now, there’s a software shop with some guts! I can just see the company email coming out of their QA department… “Build 666 looks good, let’s ship it!”

Like the fear of the number 13 (triskaidekaphobia), it turns out there’s also a term for those suffering from the fear of the numerical equivilent of the antichrist: hexakosioihexekontahexaphobia.

I guess I’ve got a bit of hex-hex-hex-itis myself… during our last house move, my wife, Chick, and I were scheduled to move into the new place on 6/6/06. Holy schnikies! Who cares, right? But, why tempt fate. We ended up spending the 6th in our old house and moved on the 7th.

So my hats off to the Wyse folks for a daring build 666 release to distribution. Now can we just move beyond IE 6? Please?