Hurdles in production deployment of increments within Agile
Yunus AliSr. Project Manager| Al Rostamani GroupUnited Arab Emirates
I have noticed that in Agile when increments are delivered and if the vendor does not maintain the correct version of configuration, the production deployment becomes a nightmare and time consuming. How to avoid such hurdles and make deployments smoother? Saving Changes...
This is why continuous delivery is more than just implementing a tool to push software out. The process and people side is equally important to ensure that there is a common understanding of what configuration needs to be maintained to support successful delivery, and having regular monitoring of that configuration to provide early alerts if it is not.
Kiron Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Yunus,
as Kiron says, it is not only about the product increment, the process and people side especially on the operations is important.
For example, you could unbundle increment delivery from cut/over into production and require to make sure the cut/over is well prepared, happens at a convenient time for users, communicated well before, there is a fallback plan etc.. I employed cut/over managers for this. The production system should be under strict change management control.
It might be necessary to bundle increments into releases to avoid frequent disruptions of operation.
The other way is to look at Amazon, how they manage cut/overs, several a day.
Yunus
I think in such cases it is better to decrease the sprint length e.g. one week to enable the vendor collect early feedback from your side . Also setup of virtual kanpan board would be useful to visualise the project progress on daily basis so any required rectifying shall be early incorporated Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
This is not new and this is not agile related only. This is something that all the industries (mainly software) are trying to solve from 1950 up to date. Configuration Management is a world by itself. Today new names have assigned to it in the context of DevSecOps but the problem is still the same. So, my recommendation, is going to IEEE estandars on the matter. You will find there all you need, including practical implementations examples. Saving Changes...
I agree with Sergio that this is not a new issue, and you should look at CM standards.
To add a little as someone who's spent much of my career integrating CM with product design, there are 2 main areas where you need to focus:
1) Quality Assurance: Your process needs to assure that the vendor is working to the right configuration via your product data management system. The SW needs to be under version control, the system level documentation needs to call out the correct version, and a change record is needed to document every change to the current configuration.
2) Quality Control: Your quality system for receiving needs to ensure that the vendor sent you the right version. If you are accepting the wrong configuration, then you lack configuration management of the physical parts/SW loads. At a minimum, this requires a check of the metadata with the version control identification as a conformity inspection. More stringent conformity could be required such as a code comparison to ensure that the SW load contains the design requirements. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Configuration management is the responsibility of everyone: the vendor, the suppliers and the customers. Saving Changes...
