Category Archives: Agile

road

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.

erie

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!

sprint-velocity

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.

retro-chart

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:

burndown1

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:

burndown3

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.

laundry

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.