Would you do it differently today?

A year and a half ago I wrote a post called My Gameplan for Starting a New Project from Scratch that just detailed my thoughts on starting up a new project.  I was asked via email last week if I had any changes to that post.  Yes, absolutely:

Follow it Through!

Don’t jump into the work too early without a good story backlog definition, an understanding of the goals of the system, and some inkling of the expectations of the client (which are undoubtedly going to turn out to be ridiculously unrealistic).

All processes, even XP and Scrum, have some sort of fuzzy project conception phase.  The activities that you perform in that phase are crucial to the success of the project by preparing the field, but easy to neglect because there isn’t much pressure upfront and the feedback loop that says “you’re wrong!” hasn’t started yet.  On the other hand, I think you need to work with a sense of purpose early in the project to get through that initial phase and get started.  In My Gameplan post I talked about the importance of getting momentum early on in the project.  That’s largely based on my experiences in a large organization that let the early phases drag on way too long.  After doing three projects and starting a fourth since that post, I’d still err a little bit on the side of starting the coding in earnest too early rather than too late. 

I did have some issues with coding outrunning the build, test, and deployment infrastructure.  Take care of that stuff as early as possible.  Especially early on the project, if you see chances to add some automation to reduce friction, do it right then.  Investments early on pay off more in the lifecycle of a project. 
 

 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Starting a new Project. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://http://agileconsulting.blogspot.com Jeff Anderson

    Jeremy ,
    good post,as usual .

    While I try to use as many agile techniques as possible on any given project. I also agree that you need to do some upfront work before you can just jump into development .

    Setting up the building testing framework is a good example, but I typically also need to do things like outline the architecture at least a high level (whiteboards, digital cameras and wiki’s are often sufficient), get a reasonable understanding of how the business is going to be measuring the success of the project/product (i.e. the business case), and if I am on a large project make sure I understand the dependencies between teams and existing systems being affected, to name a few .

    I do make sure to avoid detailed documentation, and focus on getting context necessary to make my agile team successful.

    Regards
    Jeff

  • http://www.grantpalin.com Grant Palin

    Just read that post – a bit heady but very informative. I’ve been using source control for some time, and have more recently learned and integrated automated builds and analysis into one of my projects. It was somewhat painful trying to get it on after the fact, and I can appreciate it will be much easier to have it in place the next time I start a project.