Agile in a PRINCE environment with a dash of Release Management

Agile has been kicking around for a number of years now and has become more and more accepted as a valid development methodology.  So accepted is Agile, it is possible to become (for example) a Certified SCRUM Master, and has virtually reached the point where being a certified SCRUM Master is a necessity for any software project manager.  One of the original Agile proponents has expressed displeasure in this and would like to see things go back to how they were.  However, for the time being Agile is king and this king is not dead in any shape or form.

I am sure in the ideal world, developers would develop in a pure Agile manner, release code on a whim and not have to worry about such inconveniences as Project Managers, Release Managers and the complete range organisational controls that impose themselves on developers.  However outside of fast moving start-ups, the controls are there and it is up to the project team to ensure they abide by them.  This is especially important in heavily regulated industries such as Financial Services.  So how can "uncontrolled" Agile development sit in a controlled PRINCE environment?

The Project Manager's View

A Project Manager will no doubt manage his project as a sequence of stages - some would even say waterfall-like stages.  This is the approach that PRINCE takes, and is shown in figure 1 below.  In this diagram, we are only going to focus on DS1 and DS2, so the remaining stages are in grey but they are equally important to the project.  Depending on the nature of the project, there may be one or many such stages and it will be determined by the feature set of the application being developed.

Figure 1

So what does each delivery stage contain? This is where the PRINCE project deviates from the waterfall approach as each stage will likely contain analysis, development and test activities for each sprint in the delivery stage.  Thus if a stage is 12 weeks in length, then (assuming a 2-week sprint) the stage plan will have 6 analysis tasks, 6 development tasks and 6 test tasks.  This is shown in simplified form in figure 2.

Figure 2

The question may be asked "Why not have everything in one delivery stage then?". Well, if your project is simple, then there is nothing to prevent that.  However, if you are building a complex application then you would probably want to consider breaking that into more manageable chunks (or delivery stages).  As an example, a hotel booking system would want to introduce core functionality to search and book rooms as an initial release, but then save the ability to pre-book spa treatments to a subsequent delivery stage.  Delivery stages also simplify the production of "road maps", which the Project Manager can use for project buy-in purposes to key stakeholders.

The Release Manager's View

A Release Manager's life in an organisation where Agile is being newly adopted can be hell; especially if the communications between the Project Manager and the Release Manager are not up to scratch.  With the short sprints and code drops every two weeks, the development team will probably expect a release to occur every two weeks as well.  This in itself is fine - if the Release Manager is aware of this schedule, however if they do not find out about the release until late in the day, they will have to plan around it by aligning resources, ensuring dependent releases have been implemented, etc. So how can this be avoided?

Pre-Production Environments: if at all possible, a pre-production release environment gives a controlled area where the release can be verified by super users.  The pre-production environment is going to give designated super users the opportunity to review the contents of the latest sprint, before releasing it to the wider user base.  When performing the full release, the Project Manager may want to release the latest sprint, at the end of the delivery stage or at the end of the project.  It is therefore possible that several sprints may pass before the users see any application change - however, if the delivery road map has been made available to them, this should align with their expectations. Figure 3 shows such a release strategy, with final release occurring at the end of DS2.

Figure 3

Scheduled Release Windows: pre-production environments are only part of the solution; another is the use of scheduled release windows.  Organisations with controls around their IT facilities will have some form of change request* and typically these will have standard metrics for standard, expedited and emergency changes, for example 70-20-10 where no more than 20% of changes may be expedited and no more than 10% may be emergency.  If the Release Manager is notified late about an impending release, then there is a good chance that either an expedited or an emergency change will be required.
However at the start of the delivery phase the Project Manager, Release Manager and development Team Leader can agree that all interim releases will only occur at a specific time on a specific day (eg. 17:00 on a Thursday).  The Release Manager is free then to schedule all the relevant change requests for the upcoming stage, and should a drop be missed due to overrunning, it can be moved to the next release window.  Obviously, there will be times when the developer and Project Manager may want an interim drop, however this should be the exception rather than the norm.

Coming soon: tools for Release Management, Risk managing projects

Release Management in a Nutshell

Release Management is an interesting topic.  It is a subject that has many different interpretations depending on the person and indeed the organisation that is implementing it.  The industry-standard definition (as prescribed by ITIL) of Release Management has the following goals:

• Planning the rollout of the software
• Designing and implementing procedures for the distribution and installation of changes to IT systems
• Effectively communicating and managing expectations of the customer during the planning and rollout of new releases
• Controlling the distribution and installation of changes to IT system

Source: Wikipedia

Looking at each of these in further detail gives some additional facets of Release Management that will contribute to the success of implementations.

Planning

As part of the planning process, it is too easy to focus solely on the project's implementation.  However, this could potential miss out an external project dependency.  While a Project Manager may be tracking direct project dependencies, what about those further down the implementation line? A Release Manager worth their salt will be undertaking this tracking, being aware of all relevant projects and their respective statuses.

Procedures

Procedures for implementing releases should be relatively straightforward.  Ideally, the procedures should be:

• Repeatable: if you have a system in its operational life, you want the release procedures to repeatable so that the implementation team become familiar and proficient with them.
• Segregated: strictly speaking, segregation is not necessary in a non-regulated environment but it is extremely good practice (i.e. as good as mandatory) that your implementation team are not your development team.  Why? Imagine the scenario: a project is implementing for the first time, as part of the check-outs, an issue is identified and one of the implementation team (who is one of the developers) thinks to themselves "I can fix this" and makes the requisite changes.  Unless the developer is disciplined, there is the risk the changes are not reflected in the source code control tool where the release was published from.  Do this too many times, and the production, test and development environments will diverge, exposing the organisation to significant risk.  Implementation teams should be drawn either from the production support team or ideally completely independent of the team's management chain.
• Testable: for simple implementations in a mature environment, this is probably not a necessary.  However for complex releases, testing the entire release process will be beneficial.  This may be a "talk through, walk through", where all implementation team members, the Project Manager and the Release Manager will work through each step of the implementation plan or (if the luxury of time and environments is available), then performing a dress rehearsal will verify the implementation steps, giving comfort before the actual "big bang".  Whether a dress rehearsal or a talk through, walk through is used, it is important to document any findings and experiences, while making any changes to the implementation as necessary.  It sounds obvious, but it does get forgotten!

A Release Manager is ultimately responsible for these procedures and may well be asked by Project Managers to help with the implementation plans. 

Communications
Release Management communications can be thought of as in three phases:

• Pre-Implementation: typical examples of pre-implementation communications are:
• Release testing status (especially for releases with a number of integrated projects)
• Implementation plans along with checkpoints and contacts
• Go/no-go decisions
• Implementation: during the release, the implementation teams will need to be keeping in contact with one another, handing over to the next step, etc.  For an implementation spanning a number of hours, checkpoint reports to key stakeholders will give them the warm, comfortable feeling that everything is proceeding smoothly.  If it is not, don't hide it - come clean and let stakeholders know how it is being addressed.
• Post-Implementation: Following a successful release, typical comms would be:
• Release Notes, detailing the changes introduced
• Observations about the release, for example hotfixes that had to be applied to get it working, any implementation team issues, etc
• A "Thank you" to the implementation team.  This is very important if the release has been conducted over unsociable hours - it recognises the efforts of everyone and costs nobody a thing.

Note: this list is not exhaustive. Each of these will be the responsibility of the Release Manager to either produce themselves or ensure is produced; hopefully they are very chatty!  I will go into each of these types of communications in detail later.

Installation

I have touched on installation in the procedures section above.  As before, the installation process should be repeatable, segregated and testable.  Wherever possible, an organisation should use appropriate automated deployment tools - this limits the opportunities for incorrect builds to be deployed or artefacts to be missed.  The Release Manager can be considered to be the custodian of the build and release tools.  His success is linked intrinsically to how well these perform.

Coming soon: putting this into practice and Release Management in an Agile environment