Agile Software Development without using Agile

Initial Assessment

Once the iCore consultant started talking to those involved in the existing process, it was clear that the Service Owner and the Development team had become ‘comfortable’ with the way they approached the delivery of enhancements. When challenged to identify ways that the delivery could be accelerated, there were few suggestions.

The current process was quickly documented, and iCore identified areas where it could be improved. This involved making a few changes to the review and approval process and then to the flow of enhancements once they had been approved.

Review and Approval

Users raised enhancement requests through the Request Management system, which the support team assessed to identify an approach and the effort required to develop the change. The Development team maintained a separate spreadsheet with all the details of the requests and their assessments, which was discussed at the Service Board every week by the service owner and key stakeholders.

iCore advised that, as only the requests deemed high priority would go forward for implementation, it made more sense for the requests to be assessed after they had been prioritised, as was the current approach.  This change meant that time was not wasted assessing requests that would either be declined or get a low priority.  This revised approach meant no more than 120 days would be used to develop the enhancements and not administer the process.  In addition, iCore recommended that a more stringent approach be taken during the review to decline enhancements that would get such a low priority that they would never make it into a release, saving even more time.

Development and Release

Once requests had been approved, they were added to the development backlog, and the highest priority was identified for the next release. Each release would include between 5 and 8 enhancements, and it would be scheduled to go into development, testing, and then media management for deployment. Typically, every release would be at least 6 months in duration.

When breaking this timeline down, iCore identified that for each release, the development of the changes would take less than 10% of the duration, with testing and deployment taking the rest of the time.  The time in testing was caused by the fact that the Service Management system was not categorised as mission-critical and so often fell behind the testing schedule if something more critical came in for testing.  The Development team would be responsible for setting up the test environment and building the package to be deployed, but this was included in the development time. For example, the current release (which needed only 8 days to develop) had completed development in December, but it was still awaiting testing in May.

iCore broke the timeline down and approached each team to see if the approach could be made simpler and faster. In the discussions with the Testing team, we asked them how they decided the amount of time and effort they would put into testing a release of this system. Apart from the system’s category, it became clear that it was simply access to resources to produce the test plan and perform the testing.

The deployment needed to be scheduled via the Change Management team, and each release was classed as a Major Change because it required a system restart, typically taking 1 hour. We discussed with the Change Management team why this was classed as a Major Change, given that it has been done many times and is a tried-and-tested procedure. It was simply the fact that the change needed an outage.

Even in development, when we asked why they bundled 8-10 enhancements into a release, knowing it would take 6 months to deploy, they could only say that it was what they always did.

Recommendations

Taking all this information into consideration, we made the following recommendations:

• Only assess the requests once they have been prioritised to proceed
• Targeting a release every month, and to enable this to be more easily scheduled with the operations teams and the users, this should be on the first Thursday of every month
• Only include 1-2 enhancements in a release, which would enable the highest priority enhancements to be deployed faster
• The Service Owner should identify the highest priority enhancement they need the Development team to work on for the forthcoming release, and the backlog should be reviewed to see if the BAU Support team could implement any of the requests as ‘fix on fail’, where the change did not need a system restart
• Given this is a tried and tested procedure, the change should be considered a Standard Change rather than a Major Change, which in turn would mean that the Development team did not need to complete a full release note
• With the release only containing a single enhancement, the Testing team did not need to perform a full integration test, and they should be able to pass the release by observing the Development team performing their testing