Model for Software Release Schedule Process

In keeping with my wish to share the tools I've come to use in managing my projects, in this post I plan to share a simple, yet effective template for planning, coordinating & managing the Software Release Schedule (a.k.a Bill of Materials BoM).

This process is typically owned by the party responsible for System Integration or producing the final Software Deliverable. Again, my context is a Set-Top-Box (STB) Software project, where the system basically consists of a number of software components, typically provided by independent component providers. For instance, the common building blocks in a STB Software stack are:

• Physical Target STB Hardware Device (Decoder) with Platform Software
• Platform Software is basically:
• Firmware - Bootloader
• Operating System - nowadays mostly Linux Kernel
• Customised by Chipset Provider, e.g. Broadcom's own Linux Toolchain
• Device Specific Drivers complying to a Middleware Interface (Macro - OS)
• Middleware Component
• Virtual Machine Component (VM Engine)
• Electronic Programme Guide (Primary User Interface / Application component)
• Interactive Applications

If you would like more information on what goes on in DTV Software Projects, just search for "DTV" on this site. I have previously written about DTV Architecture, STBSI and Agile Development Methods.

Because these components may come from a variety of sources, there is usually a need for assigning the role of [STBSI], or Set-Top-Box System Integration. This team is responsible for producing the system software build that will eventually be deployed by the customer, the [PAYTV OPERATOR].

[STBSI] in my opinion, is core to the success of any project. They have ultimate responsibility and accountability for ensuring a fit-for-purpose product is assembled and deployed. They have the freedom to drive and manage the independent [COMPONENT VENDORS], often delegated the role of customer, i.e. [STBSI] has the [PAYTV OPERATOR]'s best interest at heart, and often makes the necessary judgement and priority calls for the customer. However, this is not always the case, as some [PAYTV OPERATOR]'s have a strong Product Management team, where the [PRODUCT OWNER] works with [STBSI] in determining the priorities, etc.

So what's a Release Schedule or BoM anyway?

I've seen projects executed through the classic methods of Waterfall, Spiral/V-Model and more recently more Agile, Iterative models of project delivery. Once the early development / integration phase is reaching completeness, with STB projects in particular (despite using Agile) there is generally a massive effort of further integration & stabilisation. In this phase, the component releases need to be carefully controlled, and clear communications must be maintained with all parties, to ensure the correct issues are worked on, the priorities are made clear, and that everyone understands the goals [STBSI] is ultimately aiming for.

So there is a need to maintain a sense of a Software Release Schedule or Bill Of Materials, that is executed in a timeous, methodical manner, in producing software component releases. There needs to be some structure and method, that all parties need to understand and agree on as a way of working. This then becomes a blueprint, a regular heartbeat that is executed timeously - removes ambiguity and provides a sense of clarity and control.

Brief Walk through of the Tool

I wish I could take credit for conceiving the original visualisation, but this is actually something that I picked up from a previous project from four years back, however I've since then modified & added my own enhancements in producing a generic model for my PM Toolbox, reusing on all future projects:

Generic Model for Software Release Schedule (BoM) Process

This visualization should be self-explanatory. If you don't think it is, then I've failed in communicating the essence of the process, which will make it difficult for people to pick up and reuse. If you need more info, please get in touch.

This model assumes a timeline, as shown by the main arrow in the centre - showing a timeline of working days for the period leading up to a specific release iteration point (a.k.a. sprint or release cycle), during the cycle, and post the release cycle.

More projects are adopting some form of Agile, the basis being iterative, incremental release points. The typical STBSI release cycle is [TWO] weeks, it can be more, say three weeks, or less, about a week. It all depends on the strength of your STBSI team, the maturity and stability of your components, and the willingness of your component vendors to be flexible in producing regular release drops. Traditionally DTB Component Providers, especially Middleware providers have been very poor in delivering continuous incremental releases - which has been the bane of many PAYTV Operator's projects because the Middleware providers lock the customer in to their own processes, rigid and slow, rather than bend to the norms of current trends of flexibility. Times are changing now, and these component vendors are realising their mistakes because PayTV operators are seeking alternatives - features must be deployed in the order of a couple of months rather than at least 6-12 months...

Coming back to the process, in a nutshell:

• Assumes a Release Cycle is in the order of TWO working weeks, or 10 man-days
• The work or backlog for the next release cycle is governed by the Release Schedule or BoM
• The BoM is produced leading up to the Next Cycle, a few days in advance to allow Vendors to plan
• The BoM is baselined at the start of the Release Cycle
• The BoM is subject to change based on any new Showstopping defects the Project uncovers
• Vendors are continually monitored to track the progress with burning down the issues assigned
• Any deviation to the agreed BoM is subject to Programme/Management interventions
• Vendors release their components at the end of the Release Cycle subject to meeting the Acceptance Criteria as defined by SI
• [DTT] - is a placeholder for your own Defect Tracking Tool
• [STBSI] - is a placeholder for your Integration Team
• [Vendor] - can be used as a placeholder to replace if you only have one vendor, otherwise keep it generic

Click Here to Download the Tool for your Own Use

Is the Tool/Process Effective? Surely this goes against Agile? Is this Not PM Overkill?

I believe the complex, variable and unpredictable nature of a STB Project calls for some processes to provide some sense of control. This is especially true for STBSI teams who are new the to SI process and are in a state of chaos. I've seen this on past projects, and on introducing the tool, it brought a sigh of relief to the project as it allowed for all players to settle on a common understanding and goal. So yes, I believe the tool, a visual representation is always useful way of communicating a method of working.

Is the Process Effective - it is as effective as the team responsible for execution. Like any process, there is some management, administration and diligent participation required from all impacted players. It certainly can make a Release Manager's life much easier, and planning more predictable. There is a time and place for instigating this process, so used prematurely, this BoM process might not be very effective, and could become a hindrance more than anything else.

Agile: First, I don't believe Agile or Scrum works well in the context of a STB project delivery, without a massive investment in management, contractual agreements between vendors, etc - such that the delivery is managed, end-to-end in an Agile manner. I will expand on this in a future post as to why I think Agile will not work in Digital TV Systems projects. The BoM process is iterative, and is aimed at producing incremental releases of sound functionality and stability. There is a Backlog, called the release schedule. Work is broken down and executed in release cycles, two week sprints. So the concepts of Agile are present, but the fundamental issue of leaving bug/fixing/stabilisation toward the end of the project cycle, after the initial development/integration cycle, indeed disobeys a fundamental rule of Agile/Scrum as delivering shippable, stable product at the end of each iteration - and doing so, would not call for a separate stabilisation/bug-fix stage...again, this is a topic for another post.

PM Overkill? To some yes, it might be. But to others, this brings a sense of clarity and purpose to a project delivery team. It sets the stage for Release Management, communicates the rules and behaviours expected from all parties, and establishes a baseline for communication and project escalation. So no, I don't believe this is Project Management Overkill!