Improving Software Delivery

Blogger: Kirk Knoernschild

Many software development teams already do many things well, and these practices should be built upon, not discarded as teams seek to improve software delivery. Instead of attempting a large process improvement effort, teams should identify and eliminate the pain points of their existing delivery effort, and this is where the practices espoused by many Agile processes shine.

Suffering through failed delivery cycles? Leverage continuous integration to ensure your software product is always functional. Low software quality your problem? Develop a suite of automated tests that can be run on demand. Struggling to measure the current state of the development effort? Create a project dashboard that increases the transparency of your software development effort. Each are simple, incremental improvements to your software delivery strategy that help increase your ability to deliver high quality software.

Here are a few nuggets of wisdom to chew on as you seek to improve software delivery.

• Tools don't solve problems - Before you buy that shiny new hammer, make sure it's a hammer you need. Does  your existing software delivery strategy rely heavily on modeling to deliver great software? Or are you hopeful that by purchasing the modeling tool you'll discover a better way to deliver software that has escaped you in the past? If you really feel the need for a power tool, make sure it's a tool that fits your process.
• Traceability is a myth - Many teams are enamored with traceability. Changes to requirements can be traced through the analysis and design model into the code through the components and onto the executable nodes. But traceability is fundamentally flawed due to synchronization issues across artifacts. Teams do not possess the discipline necessary to maintain consistency across all artifacts, making the source code the only true artifact representing the current state of the system. Build on that idea, and surround your source code with executable artifacts that offer valuable insight to the code's quality, functional correctness, and feature set.
• Software delivery must be disciplined, not ceremonial - Significant phases of the software lifecycle should not be marked by ceremonial milestones. Many teams celebrate requirements sign-off. Design is done; throw a party. Such ceremonial milestones offer a false sense of progress. On the other hand, delivering functional software on a frequent and repeatable basis requires tremendous discipline. The discipline to continuously test that software through the evolutionary growth of the system is a fine example.
• Conform process to people, not people to process - Software process cannot be made constant because the people involved in the development effort continuously change. People cannot be made pluggable parts because each is an individual that brings different experiences and personality to the development team. Forcing people to conform to process stifles innovation.
• Source code is a corporate asset - At the end of the day, the reams of paper consumed documenting requirements and design models are never used to judge the success or failure of the software system. When all is said and done, the one artifact offering accurate feedback on the quality of the system is the source code.