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