DevOps Stabilization I

The DevOps Stabilization story is now available on the Dialectic website on the lower left corner of any page. It’s a fictionalized 2-page case focusing on an IT Director struggling to stabilize the environment during the fifth year of her company’s transition from waterfall to DevOps software development.

For those concerned I promise no names had to be changed to protect the innocent! This isn’t any one account of a specific client experience. However, there are elements of stories I’ve heard at numerous clients over the years, and not just in IT.

Policy decisions, each seemingly rational when put in place, accumulate over the years. As they accumulate, they begin interacting with one another in new and unexpected ways, even as the environment for which they were designed begins to shift. Eventually a Director trying to manage chaos is left asking themselves:  “What I am supposed to be doing here?”

Behind the scenes the story leverages the DevOps Diorama, a 1/10th-1/20th scale exploratory model I’ve developed. Exploratory simulation models are not meant to be perfect replicas of the real world. Rather they are built only with enough structure to recreate the behavior over time experienced in an environment and help isolate the causes in it. They can still be very powerful tools of change and understanding. The ten sectors of the model are shown below.  Each sector has additional model structure beneath it.

 

                                    Sector Map of DevOps Diorama

What I like about these models though is they capture the two worlds we live in: quantitative and qualitative. The sectors of financial metrics and staffing needs are driven by quant structures. There are also qualitative equations such as: how do people react when subjected to pressures from too much backlog? What is the logic that managers use to make decisions? What role does a firms culture play in these factors? After 20 years of work at dozens of clients I have yet to see one environment that wasn’t somehow a mix of the two.

From a technical perspective, developing this model was a nice challenge. Practical application as well as research in project dynamics has been a focus of system dynamics for over forty years. I’ve linked some of the great articles along that journey below. At WPI I’m working to expand that literature by incorporating new simulation structures for Lean & Agile theories into the traditional project dynamic simulations. That work can be followed here and was the reason for my post last week looking for reference mode data to empirically test my models. However, the academic models are relatively simple affairs with limited structure compared to the DevOps Diorama which presented its own challenges.

The first was putting in Portfolio and Program Management sectors to handle continuous-flow projects. This creates allocation problems not found in single-project dynamic models. “What should the next work be?” and “When should the next work be started?” are questions managers in the simulation have to answer. For DevOps (and Agile) specifically this is complicated by the tug and pull between new work and a need to eliminate techdebt through refactoring.  That means the simulation has to track both actual techdebt and what management believes it to be so that it can factor into their Portfolio Management decision making.

Perhaps, the biggest challenge was staffing mix. And I’m not sure I’ve got it exactly right. Anyone who’s ever deployed Agile beyond a team or two has lived first-hand the difficulty of load-balancing dedicated scrum teams with as-needed highly-specialized resources (e.g. DB admins.)  Simulating this is hard enough – but DevOps adds to this by incorporating Infrastructure and Support teams into the same environment. Staffing now becomes fluid between all three. Buy me a Diet Coke some time and I’ll tell you the woe of allocation algorithms for Brokered Resources! As I continue to work on refining the DevOps Dioramma this is an area where I’m going to focus on.

Writing wise I’ve simplified some of the DevOps specific terminology so purists may experience heartburn. But I wanted the model to be accessible to those in Agile and waterfall environments as well so I hope they don’t mind too much.

That’s all for now.  On the next article I’ll give a brief overview of how a simulation model like DevOps Dioramma is used differently than a traditional process map/architecture for performance improvement.  And how they can complement one another.  

v/r

Tim C. 

Leave a Reply

Your email address will not be published. Required fields are marked *