This post was inspired by David Greer who presented us with the topic of devops and continuous delirium.

When it comes to devops, continuous delirium has two connotations as in wildly excited, and incoherent and bewildering.  When done appropriately, the development personnel and our customer will be wildly excited to be a part of such a wonderful and productive project.  When done poorly or inappropriately, our work resembles a sense of random and non-sequitur moments that leave the team and customer feeling like they have been thumped on the head.

Constant Builds and Poor Configuration Management

Constant builds of software with insufficient configuration and build management leaves everybody bewildered and wondering about the build and the constituent parts that actually comprise the build, not just what we suppose it to be.  Defects come, then are solved and in a subsequent build we find a defect very similar to the previous defect. Upon investigation, we will find that it is, in fact, the same defect. Cure this malady with some rational approach to the build and configuration management process. This can be establishing check-in and check-out procedures for software module as a tracking sheet that identifies the revision of the sub-modules for the entire software.  At the higher level, the compiled product iteration should have its own corresponding designator.  Ultimately, we need to be able to reliably go back to earlier revisions and understand the contents therein.

Who is Responsible for What?

Poor understanding of the work, we do not know who is doing what; neither do we know what constitutes successful delivery and pandemonium reigns.  Consider the example where a person is assigned a set of tasks or objectives and they work toward that end.  Person one’s output or deliverable goes to the next in the chain of development.  Upon delivery of the output, the receiver notes that many questions are unanswered. These questions require answering before the receiver can start their part of the work.  Invariably this will require rework.  Cure this malady by understanding what constitutes appropriate quality of the proposed delivery as well as periodically review the state of the objective with the receiving or depending entity.  There can even be metrics associated with the quality of the delivery that are periodically reviewed to understand if the work is on time and target (for example, the number of features documented, the total number of features, number features delivered, the number of test cases).  Do not wait until all of the work on the subject has been theoretically completed before reviewing.  Rather define the work and specific critical metrics and review as the development progresses.

Clean Compile is not Considered Testing

A clean compile daily is not to be considered testing, though some may have you believe that to be the case, neither should testing be relegated to the end of the development, this is another failure similar to the one above.  Often testing is treated as the final act of the delivery. On top of this, it is scheduled against the delivery as if there will be no defects found. I suppose if you do not look, you will not find defects, but that is not a productive solution. The problem comes when your customer uses the product. Then the defects are discovered and the ability to correct is much more complicated and costly. If the application is sufficiently critical, there may be legal ramifications.  Rather than relegate testing to the final stages, integrate the testing with the development.   Use numerous complimentary approaches such test to requirements, combination of stimulus testing, extreme testing and exploratory testing.  Where testing to specification is concerned, invest in automation freeing the testing talent to perform exploratory testing on the product.  This testing will be outside the specifications but in the practical application of the product by the customer. Often, the things we believe the customer would never do are the very things they do and when they do, there can be consequences we would rather not the customer experience. Define key test metrics, for example, the number of defects found per iteration, the distribution of the severity of those defects is also a key metric.  Defects that are a minor blemish are not the same thing as a defect that can cause harm. An understanding the defect arrival rate and the severity of those defects make some level of prediction possible.  We would expect to see the number of severe defects (that is defects that can cause harm or monetary loss) to abate over time if our development and test work are successful.  This provides for the prediction of launch based upon the product quality.

Predicting the Future

Planning horizon is really the duration into the future we can reasonably and reliably understand, predict and control.  We delude ourselves when we plan projects out year or more into the future. The further into the future the less we are able to predict.  When we treat a plan as if we know everything associated with this project for the next 12 to 18 months we are suffering from delirium.  In fact, one study shows that 90% of successful projects were less than 12 months long and 47% were less than 6 months in duration[1].  Break the project down into smaller and incrementally approach the plan and the work.

Insufficient Customer Involvement

Customer (user) involvement is essential to meeting the customer target and in my opinion is a significant source of agile successes.  Getting the product or a facsimile (model, prototype or iteration) of the product in the customer’s hands for exploration as this provides the feedback loop to the developers.  Many may see this as a problem as this opens the door for change but that would be a very myopic way of thinking indeed.  Rather than being guided to what is required, we assume we (customer and developers) know all we need to know about the proposed product.  Rather than try to deliver one incarnation of the product to the customer at some future date, break the delivery down into iterations that will meet the prioritized customer expectation, refining and incrementing the feature content as progress on the product is made.  According to a study from The Standish Group, number one of the top 10 success factors was User Involvement[2].

Uncontrolled, Uncoordinated Changes

Product Change Management goes hand in hand with customer involvement. We can choose to not involve the customer, but this will be done at our own peril.  Waiting to give the customer the final product often uncovers questions that we should have been asking all along. Since we know to involve the customer, we also know we are going to require a consistent and capable way of managing the changes.  Change itself is not a problem within the development, unmanaged change is the problem.  There are ways to manage any costs associated with altering the product design over time. However, if our planning horizon and work duration are not excessively long, budgeting becomes easier to manage.  Ultimately a connection between the budget and the delivery must be known and a good mechanism for this is Earned Value Management techniques defined in conventional project management.

Systems Thinking

Collaboration (systems thinking) is required for all but the most remedial of software development work.  Streamlining delivery to the customer requires clear and quick communications channels throughout the devop chain.  Everybody from the customer, through the developer and testing personnel, should work like a well-oiled machine by free-flowing communication.  If our enterprise produces a manufactured product from operations, then this manufacturing group would also be required to participate in the development of the product.  In this way, we shorten the development cycle and obtain the most from our talent as we strive for clarity (rather than delirium) and constant improvement.

Conclusion

Save yourself from the bad case of continuous delirium.  Instead, pay close attention to the fundamentals and your customer will remain in a continuous state of delight, wildly excited by the growth and quality of the product.  The team will likewise be in such a state, as the frequently ridiculous requests that are required to save the project will be reduced greatly.