Software Development

AOL and Software Development and Work Life16 Oct 2007 07:09 pm

This sounds much stranger than it actually is, and every day I am less wary of saying it in public ;-) I am a Master of Scrums.1

The software development group I now work in did agile development in a kinda-sorta, half-assed way for about a year or two (during which time I happened to be their customer). Then about six months ago, a while after I joined the team, we decided to get serious about Agile — in particular, Scrum.

There were plenty of obstacles. The biggest was the fact that AOL has in recent years taken a very process-heavy, waterfall-like approach to product development. It was antithetical to developing software in an agile way.

Earlier this year our execs brought in an outside firm to do some Scrum training. Their two-day course — which I highly recommend — was a great foundation for us to build on. We found it most beneficial when all members of a team — product management, development, QA, project management — attended training together. This gave us all a common reference point over the coming months. On the whole, this has been a very useful and productive effort, and I hope Agile is here to stay at AOL.

Within the Scrum framework, there is some room to tweak things to suit your own organization. Half a year in, we’re still correcting mistakes, making adjustments, and learning what works best for us. One surprise: we find that best practices (which I’ll talk about in a future post) vary from one team to another.

So what are the benefits we’ve seen using Scrum?

One of the biggest benefits is that you get very rapid feedback on how things are going. Four days into a sprint,2 and you will know straightaway if you are having problems. We often find ourselves making adjustments after a week of work. In contrast, when using our older waterfall approach, we often wouldn’t become aware of a problem until we’d missed a major milestone, typically weeks or even months after a project had begun. Now these checkpoints and moments of awareness happen regularly: for small issues, on a daily basis, and on a larger scale every few weeks when we complete a sprint.

It is also much easier to make rapid adjustments. Even if you strictly follow the rules of Scrum, you can often get sudden requests into your next sprint, which means out to production within two to four weeks. In some cases we cheat a bit and incorporate smaller changes into the ongoing sprint.

If you are good about using a tool3 to keep track of tasks and progress, you gather invaluable data about your team: your development velocity, your hidden inefficiencies (like overhead for build management), how good you are about identifying tasks ahead of time, how well you estimate task effort, and more. Each team is unique, and the sprint histories provide valuable characterization of the team as well as a record that informs you going forward.

After you get a bit of history under your belt, you become a pretty good judge of the scope of a project — “this thing feels like three, maybe four two-week sprints…”

Finally, here’s a really cool benefit of Scrum: if you are diligent about knocking out the most important and highest-risk stuff first, you sometimes finish a project earlier than expected. On a couple of projects, we’ve suddenly realized that, while we still had a backlog of items (“stories”) to complete, none of them really needed to get done now, and hey — we’ve got more important things to do somewhere else. “So, umm, folks, I think we’re actually done here…” Man, imagine that!

Where have we had issues?

It definitely hurts when you try to do too much at one time (although this isn’t unique to Scrum!). We’ve had most success when a small team (1 to 3 developers) can be dedicated to a project until it is complete. If you find yourself spreading individual developers or QA people across multiple projects, you may have productivity problems. On the other hand, some of the ancillary team members, like the scrum master, product manager, or operational folks, seem to do ok handling multiple projects. As scrum master, I find that I do okay with up to 4 or 5 simultaneous projects (although that means I’m not getting a whole lot else done during the day!).

We’re still learning how to most efficiently manage projects where multiple remote teams are working on different components of a single, larger effort. This scenario — which is increasingly likely going forward — definitely presents challenges. For us a daily scrum of scrums improved communications a lot. And one definite win when teams span multiple locations: small- to medium-scale video conferencing; daily visual interaction can make a huge difference when working with remote teams.

It’s also worth noting that some of our groups that do heavy integration work, and others that work on projects with very infrequent but very large deliveries, have struggled with Scrum. I’m not directly involved with those efforts, though, and not particularly familiar with their situations, so I won’t comment further.

What else?

Agile methodologies were popularized in the software development world (though they really originated elsewhere), and are especially suited to the sorts of work in which the path to the desired solution is not clear at the onset.4 So where else could this approach be useful? I’ve worked in several fields that, in retrospect, could benefit from following a Scrum-like methodology (or maybe just using parts, like the daily scrum for keeping on top of things and getting frequent feedback):
* Physics. Namely, in the design of, and preparation for, medium- and large-scale physics experiments.
* Electrical engineering. For hardware and firmware design, especially where one is dealing with leading-edge technologies.

What do you think?


1 If you’re not familiar with Agile / Scrum, wikipedia has a good overview. The Google video of Ken Schwaber’s talk is also very useful.
2 We’ve been happiest with short sprints: typically two weeks, and sometimes less.
3 We’ve experimented with a few tools, with varying degrees of success. In a future post I’d like to discuss this in some detail.
4 Contrast this, for example, with building one of a dozen houses, or building a widget in a factory…

Open Source Software and Software Development09 Oct 2007 07:33 pm

I was cleaning out some old — really old — papers recently. Instructions, era 1994, about how to use vi and emacs, and how to dial in to the campus computer systems… Ack — thank goodness we’ll never have to go back to those days (dial up, that is — vi and emacs are still welcome).

That got me thinking about what a huge impact Open Source software (OSS) has had on my life — wow! Here’s a shout out to all the good folks who work on OSS :)

I first really started using Open Source software while studying physics at the College of William & Mary in the early ’90s.

Before then? Yeah, sure, I used the occasional GNU application on the resident Solaris and HP/UX machines at school. But at that point it didn’t feel like I had a particularly noteworthy relationship with OSS ;-)

Over several years, starting about 1994, that changed. We made heavy use of Perl at Jefferson lab (where I collected my thesis data), and just about everyone (me included) used LaTeX to author their dissertation.1 Before leaving I wrote some modest software to store experimental data in a MySQL DB and access it using Perl (using a UI toolkit, though I don’t remember which one).

My first exposure to Linux was when a more senior grad student explained why he needed more than 30 3.5 inch diskettes. Huh?! “It’s this new O/S, Linux. Kinda like Minix, in that you can install it on a regular PC.” Cool! “And it’s Open…” Hmm, what’s that mean? A short time later Red Hat came out with their first CDs, and I started using Linux regularly.

Years later (early 2000) I showed up on AOL’s doorstep. While I really enjoyed academic research, I quit a post-doctoral position partway through for a few personal and professional reasons (which we can chat about later). By that time I was completely on the OSS bandwagon. One of my personal goals was to work for a company that could help level the marketplace dominated by the behemoth from Redmond and other proprietary software vendors (yeah, I get the irony of working for AOL with that attitude, but that’s a more tangled issue for another time).

I wanted to get AOL to move their experimental AOLTV service from a proprietary platform to an embedded version of Linux. I wanted AOL to start using Linux and StarOffice internally. I developed grandiose plans to distribute StarOffice (later on the infamous AOL CDs in order to disrupt Microsoft Office.

Here is an understatement to note: Sometimes it is more difficult than you think to get a large organization to make dramatic changes. Yeah, we live and learn, don’t we?2

Nowadays I use more Open Source software than ever, and collectively it represents an amazing amount of work. At the moment I am using Linux (Ubuntu) / GNU tools, Gnome, KDE, Firefox, Thunderbird, OpenOffice, WordPress, Gallery, Joomla, MySQL, Ruby on Rails, KDevelop, Gimp, XPlanner, Digikam, TiddlyWiki, Rythmbox. There are additional OS apps that I use on a sometimes basis or used regularly in the past, the most notable of which are: Perl, Postgres, Latex (and then Lyx), StarOffice, Mozilla, and Gaim (now Pidgin). Holy cow!

So I will close by saying that for the last decade and a half, I’ve been mostly leeching off of Linux and Open Source applications… I’m really sorry about that :-/ The one exception — and I hope it is decent enough to make a karmic dent — is that personally and professionally I have been an outspoken advocate for OSS the whole time.

1Word 6 had arrived recently, and a few students tried using it to write their dissertation. Their recommendation was to stay away… Word had several serious bugs specific to long documents and the particulars of scientific treatises that Microsoft wasn’t very responsive in dealing with.
2In fact, several years after I arrived, AOL became more aligned with Microsoft. I don’t know details, but we apparently signed some sort of deal to work more closely together. By that time it didn’t hurt so much, if only because I had a better understanding of the strategic game that AOL had to play in order to survive in the marketplace.