Ramblings on Software Delivery February 28, 2016Posted by Edwin Ritter in Cloud Computing, Project Management.
Tags: release management, release management process, software delivery
add a comment
I expect there will be a time in the not distant future where software development will be easier. So we are clear, I mean predictable, common even.
While not fully equivalent, here is an highly simplified example.The electrical socket outlet is a common fixture found in commercial and residential buildings. This did not happen by accident. The generation of electrical power and subsequent demand caused a great deal of standards, regulation and common design elements. They were required and fundamental to broad use of electrical and ubiquitous availability.
Software best practices constantly evolve and there have been lots of advances from the 1GL, 2GL and 3GL days. Yet, despite those improvements, a recurring challenge on projects for me concerns the final product. By that, I mean delivery and all that goes with it. Not in any order, but these include customer acceptance, integration testing, launch, cut-over, final QA. From my experience, what should be common and predictable instead is anything but. Each project has unique challenges but the over all release process is the same.
And, yet. Here we are with 4 and 5GL programming and the fundamental challenges that remain to be solved. Code objects are inter operable; APIs are well understood but ad-hoc. Seems to me that there should be more common functions and libraries that provide a lot of the basics. And they do – to a point. But not at the same level as electrical outlet.
Perhaps the challenge is more with interfaces and data types (schemas). But I digress. Delivery and integration of software remains a crucial phase (see delivery above). Imagine a time when delivery is the same as generating power and connecting to the ‘grid’. Delivery is then driven by demand and usage among other things. Yes, cloud computing comes to mind and that has made things easier.
Which leads me to release planning using Agile practices. A good step forward toward common delivery. Getting more consistent release process is always preferred to ad-hoc. I have earlier posts about this topic and I expect there may be future ones as well. It is an evolving practice and gets better all the time.
ITIL outlines release management best practices. I know that the state of the art in software development will get to the electrical power example I mentioned earlier. The general consensus is we have achieved a basic process for delivery. Understanding current state, defined and consistent intervals,use standards and automate when and where ever possible are part of best practices.
What other challenges will remain going forward? How will standards be revised, improved to get to the electrical power equivalent state?
Ramblings on Release Management August 30, 2015Posted by Edwin Ritter in Project Management.
Tags: release management, release management process, software configuration management, software development, software development lifecycle
add a comment
From a recent project, one of the lessons I learned concerns release management and who drives that process. What I find most interesting is the developers’ view that once code is checked in, the deliverable is complete. I have worked organizations that use a formal software configuration management and release management process (SCM/RM). That role can be a fully staffed position working with development teams to get code changes tested and released.
Related to this topic is environment management and configuration, the related tools and workflow to keep the organization working on the right things and at the right time. Ultimately, the changes are provided for use by external customers to meet their business needs. Let’s not forget that customers keeps the business going.
The SCM/RM process can easily be used with change control to manage the code base consistently. When the SCM/RM is not the responsibility of any single person, I submit that the developer shepherd their respective code changes through the test and release cycles. What I find lacking is ownership from developers on following that through to getting code changes released.
While my expectations are influenced by past experience, I am aware that it is naive to expect other team members will have a level of ownership and commitment consistent with mine.
So the next time there is a change, I will use my greater understanding on what is needed to keep things moving and align my expectations. A lesson learned and one that I am willing to share with others.
Comments invited on the level of effort and ownership with release management. Who drives changes through to release? Is it automated in your shop? What tools and process do you use to manage the code base?