Demo Showcase Suite – A History – Part 4

A continuation of the lessons I learned from previous projects.

Lesson 2:  I wanted to accurately track scope changes

If you’ve never been burned by a scope change that wasn’t accurately tracked, this might not seem important.  This is an agile environment you say.  You should be able to adjust your plan every couple of weeks.  You start the project knowing full well that you don’t know everything.  That’s what agile is all about.  Well, as a developer I used to work with said frequently,  yes, and no.

I’m not an expert on agile.  I’m sure I’m doing it wrong, and about to give bad advice.  I know requirements will change as the product comes to life.  Feedback will drive changes.  Features that were once viewed as critical will be swept aside as new features take center stage.  I know this.  I just don’t like it.  I like having a nice stable target, and a plan to get from there to here.  I hate surprises.  In my work, surprises are never good.  I’m never pleasantly surprised by a customer request.  I’m never optimistic about a conversation that starts with ‘What would it take to…?’.  Remember, I’m not in sales.  I have to get the app built.  I rely on sales and the product owner to drum up new business.  I have to get ‘er done.

I know these changes are going to happen, and I know I’m going to grump about it as I try to protect the team.  That’s my job.  But I also know that customers have extremely short memories.  They never remember, and they hate being reminded, that the change they asked for resulted in the two week launch delay, or another feature being pushed to a follow-on release.  I’ve actually been on projects where I had multiple customers who all thought they were in charge of the product, and didn’t like the final product because someone else made a change to our marching orders without informing them.

This all comes back to the change tracking section at the top of the requirements document.  Every change has to be annotated there, even if the change tracking is turned on in the document.  Changes can be ‘Accepted’, and the history can be lost.  Religious adherence to updating the change tracking section is the great equalizer to the argument over why something changed, was late, or was missing.

As time went on, and the project evolved, we began adding the changes into our change management system (TFS), but at the start, we used plain old Word documents.  I’ll get into TFS and our development infrastructure later.   That’s a whole other conversation.

Was this approach successful?  I think so.  Unlike other projects, there were no last minute surprises from the client.  There were no gaping holes in the product that were missed requirements.  The customer was (I think) quite happy.  But I haven’t had to go back to those documents yet.  Maybe we just did a good job with them in the first place, or maybe we haven’t stepped back and looked hard enough yet.

Regardless, it’s a practice I intend to keep doing, one way or another.