So you’ve been working on this complex project for six whole months and you’ve satisfied requirements, been through testing and ready to go… Go where?

In a well run project, that would be production. If you are one of the many, you are ready to go to the drawing board for more features because scope creep has festered to the point that is has become malignant and the marketing department (or champion(s) of your project) insist that all bugs be fixed before releasing. Sure, you tell them that dirty little secret about how software can never be bug free. But don’t worry about them because they can shake you off with no difficulty. Next thing you know, you’ve got a task list of several weeks worth of work that needs to be done in two days for the release.

Non-developers, especially those that have been given command over a development team, think that software that ships to production is perfect - little do they know. We all know that software isn’t perfect and sometimes you just have to draw a line in the sand and say enough!

Requirements will change during the phases of development and there is really nothing that we can say about that. If you consider the objectives of the ones that are paying you to sit and write software, you see that they don’t really care about how the software gets developed. They don’t care about you getting on your soapbox to explain right and wrong to them about process. But they do care about meeting customer expectations and that is the desire to which you should appeal when making your case.

First of all, scope creep needs to be managed up front. If you wait until the very end of the project to start denying requests from the “request machine” then you will simply appear lazy and as though you are willing to settle for lackluster software. Expectations need to be set in the very beginning with all parties as to what specifically constitutes a request eligible for interruption of development.

Software will always have bugs. It’s important - from the very outset - to be preparing the owners of the product for the day that they will need to realize the code is not perfect but needs to be delivered. It will take a little time for many to accept this fact, but they will make that decision much easier if they are prepared.

Tags: agile, shipping