software development methodology

Continuous Integration in Waterfall?

It’s has been a while since I posted on this blog.  Now that I have aligned all my ducks in a row, walked the dog and fed the cat it’s time to blog again.

I can’t address enough the benefits of Continuous Integration on IT projects.   In a nutshell, CI is a software development methodology that is based on the premise that developers check their code into source control multiple times a day.  The code check-in triggers an automated build which compiles all the code and runs unit tests.  Thus, a software development team has many integrations in a day.

As Agile methodologies continue to overtake the traditional Waterfall, yes waterfall is not dead yet, we can witness CI become a key activity in driving software quality.  Quality is driven by the many integrations and the early identification of software defects during the automated builds.

Working as an adviser to many project teams, another key activity that it’s missed is the “Demo”.  Whether you use Scrum, Kanban or any other methodology, be sure that your team gets to demo what they built iteratively  Recently, I was on a project where the development team did not demo their application until the last week of the development cycle and the customer had a large number of changes that they wanted.  Unfortunately for this customer, the Waterfall approach that the System Integrator was using did not take into account this simple activity.  Instead, the changes were logged as “Change Requests” and left to another process in order to define the priority.

How do we fix this symptom?  If you are in a Waterfall vacuum, try to schedule a few demo’s with the stakeholders either a product owner or a system user.  Get feedback early in the process and incorporate the changes that are within the scope of the SOW.  If the changes or feedback fall outside of the SOW, the notify your customer and log the request on a risk register.

Also, incorporate CI into Waterfall.  Have your team stand-up a build server and have them check their code with unit tests.   Build often and reward the build breaker with a special hat or task.

 

Advertisements