c o d i n g f r o g s

croaking about programming, programming languages, software engineering, and the business of software

Software Development Methodology Profile – Novell Forge

It was the fall of 2002 and I hadn't been in Novell's Developer Services group for more than a couple of months when I realized that the way Novell was maintaining and offering their developer content was flat-out broken.  We needed a new process for delivering developer content that was a lot more dynamic and interactive.  So I proposed we create a new web site with a web application that would allow us to publish more freely.  We soon realized that we wanted to publish code too, not just documents, and that many of our developers wanted to also host and share their own code.  The idea behind Novell Forge was born.

We were starting with an open source CMS, Xoops, and a fairly good-sized Xoops plugin named XoopsForge, but there was still a lot of software development needed to deliver Novell Forge from these foundational pieces.  We had a smallish development team of four or five engineers and a project manager.  I was somewhat unofficially designated as the lead.  Having recently read a bit about Extreme Programming and being interested in trying some of the techniques out, I somehow convinced the project manager that we should try out a new way of developing software.

This methodology was so amazingly lightweight and simple, and yet it worked so remarkably well.  It's shaped a lot of my thinking about software development ever since.

I wrote a very simple web application in PHP to facilitate the process.

• There was a story card entry page, where you could add a new story to the list of stories that comprised the product roadmap, or edit a story.  Each story had only a couple of fields:  a name, a description, and exit criteria.  The exit criteria outlined a number of objective criteria that, if true, meant the story was complete.  A developer could also assign himself or someone else to work on the story.
• There was a participant entry page, where you could add a new developer to the project, or edit one.  This was pretty simple also, maybe just the name.
• There was a story prioritization list page.
• There was a dashboard where you could easily see who was on the team and what they were working on currently.

That's pretty much it.  It took me about a day or so.

There were two keys to this.  The first was that the stories were prioritized from 1 to N where N is the total number of stories remaining to be completed.  This required a leap of faith on the part of the project manager, who had spent her entire career prioritizing features as P1 (mandatory), P2 (important), and P3 (desirable).  Maybe your project does things this way too.  Most companies I've worked for use this same technique.

Here's the problem with the P1-P2-P3 prioritization.  Suppose the product manager, or whoever, puts together a requirements document.  He lists all of the features and prioritizes each one P1, P2, or P3.  Any guess how many of the features are P1?  Based on my experience, probably about 60%-70%.  Another 20%-30% are P2, with maybe only 10% or less prioritized as P3.  What if the schedule can only allow us to do half of the requirements?  This prioritization doesn't help us at all.  When a developer finishes one assigned task, which should she work on next?  If they are all prioritized P1 it is hard to differentiate.

Sorting all the stories from 1 to N forces the people managing the requirements to think about what really matters first.  If you deliver each story completely and meet the exit criteria, the product should be "functional" with the new story fully integrated by the time it is done.  Note that this doesn't necessarily mean the product is shippable after the first story.  With Novell Forge, we knew we needed to deliver to about story 30 or 40 before we had a product we felt was worth releasing, but still we numbered every story from 1 to N.

A great benefit that comes from this is that now the developers can self-manage.  Is my work done?  This is easily determined by evaluating the progress against the exit criteria.  What should I work on next?  Just assign to yourself the next item at the top of the list.

The second key is trust.  A lot of more complex methodologies add a lot more process to replace the need to address incorrect behavior by your developers.  My web app didn't have any access controls, didn't have any roles or responsibilities.  Anyone could add, delete, reprioritize, or assign stories, but the key is that they DIDN"T unless they were supposed to.  Developers closed issues when they were done and assigned themselves more work when they needed stuff to do.  They kept themselves busy and continually marching toward the goal.  My point is this:  If your team can't follow very simple processes, you might have a personnel problem, not a process problem.  So don't try to fix your personnel problem by adding process complexity.

What were the results of this simple process?  Well, for one thing, it put the team and management at ease.  At any given point in the cycle, we had a functioning product with the most important features already delivered and the next most important features in progress.  We could ship whenever we felt like it.  We could decide to delay shipment until specific stories were done, or align our shipment with a specific event or announcement and go with what we had at the time.  Great flexibility here.

But another, arguably better, feature of this methodology was that the developers loved it.  They wanted to follow it because it was so lightweight, required so little of them, and assumed such a high level of trust from them.  It helped them to focus on just doing their work, and it was easy to see us progressing toward shipment.

Ultimately, Novell Forge was delivered on schedule with the full feature set, but having the flexibility along the way made it a lot less stressful.  Really, does the process have to be more complicated than that?