Release sprints

To get our code to production what is left to do is to turn the “potentially” releasable product into a releasable product. To do this a number of activities are required: Which ones and how much effort they require varies greatly between types of organisation. 
 
The fastest way to perform rollout activities is to do them within the development team and to automate as much of the process as possible. While I envy and respect teams that are mature in terms of test and deployment automation and operate in an organisational context that allows them to easily move code from environment to environment I find that this is very often not possible within larger organisations. 
 
Often, among other activities, someone outside the team has to be instructed as to how to deploy code, other parts of the organisation have to be informed about the changes (eg. end users, operations and maintenance teams, etc), and manual regression testing has to be performed. 
 
For the kind of large organisations Mike Cohn refers to in his description of a bank with COBOL code and no automated regression testing or large organisations new to Scrum and Agile I, too, find this is best done within a so-called release sprint.
 

When the red bus hits: Agile when things go wrong

There’s a saying in software development “If someone gets hit by the red bus … “ which roughly translates to that if you lose a project team member or two you still want to be able to get the work done and finish the project. 
 
Normally, red busses are rare: The realistic worst case scenario is one or two team members out with the flu or someone quitting their job. A good team can normally recover from such disruptions. 
 
But red busses can be bigger and more damaging and wipe out large parts of a team: This usually happens if a new CEO, new management or a new government revokes funding, recession hits or an organisation just plain runs out of money. 
 
In this case one of two things normally happen:

  1. The project goes on with fewer team members
  2. The project gets canned or put on hold

 

Waterfall

This is bad news for everyone but has a devastating effect if your project runs any flavour of the waterfall methodology:

When not to run Agile

People keep asking me whether I’d run all projects using an agile framework such as Scrum. 
 
When I answer “of course not” they often not only expect but gently try to steer me towards an answer that excludes certain type of projects: “You certainly wouldn’t use it for a mission critical system, would you? Or a compliance project? Or an infrastructure project? “
 
Actually, yes! I have used Scrum for business critical systems at a major mobile phone manufacturer, have implemented mission critical systems for a publicly owned European Rail Cargo company, a friend of mine has successfully delivered a compliance project and another one has even developed fighter jet control systems for a European Air Force using scrum. 
 
It’s not about the type of project. It’s not even about the size of your project. It’s about whether you’re willing and able to create a setup that allows agile projects to succeed. To me the rather vague terms of organisational and cultural readiness can be narrowed down to a list of primary show stoppers: 
 
I’d NOT run agile if …