Defining an Agile Methodology for Orthodox Environments

My company designs and develop mobile and web based banking solutions. Our customers (banks for the most part) are highly bureaucratized, orthodox (ie. like to have everything pre-defined and pre-approved) and risk adverse, and therefore change and the disruption of the status quo is not a normal sight within most of them.

Most banking IT departments are used to the good old waterfall development cycle (believe it or not). Additionally, when they purchase a tailor made system (or a highly customizable product based deployment) they prefer to know in advance exactly what the system will do, how will it do it and how long will it take to deploy it (even if they don’t know what they want themselves).

I believe this happens a lot in provider/customer relationships, and not only in the finantial sector.

But during real life software development projects at banks, as it happens on almost all software projects:

• Changes are inevitable
• Users don’t realize what they want until they see the system working
• Developers don’t understand what the user needs until they see the user’s face looking at the actual system

So an agile methodology seems to be in order, right? But how to couple both worlds…

What we decided to do is to take the bureaucratic items that we think are absolutely necessary for our customers to feel at ease and to actually buy our projects, and build the most agile methodology possible with these items as axioms.

These undesired but unavoidable items are:

• Pre-defined initial scope
• Formal customer approval of user stories (or requirements specifications)
• Acceptance testing with a formal approval done by personnel appointed by the customer (be it from the actual customers staff, or sometimes from a third party)
• Documented and pre-approved change requests

We took elements from several agile methodologies and personal experience of our staff, with a lot of influence from Scrum, and defined the following:

• Sprint zero, lasting from 1 to 5 weeks:
  • General look & feel design
  • General HTML template development
  • List of all user stories compiled and prioritized
  • System architecture definition
  • External systems interface design
• Regular sprints lasting 5 to 8 weeks:
  • Write user stories
  • HTML development of relevant pages/widgets
  • Validate user stories and HTML items with the customer
  • Development (up to 2 user stories per developer per sprint)
  • Internal testing and rework
  • Validation testing and rework (with the customer)
  • Testing/pre-production deployment of new version
• Regular sprints after sprint number one should have a lower assignment load per developer than sprint one, to make room for rework/changes from previous sprints and validation testing.
• The assignment of user stories to each sprint is done using the prioritized list and the availability of human and system resources from the customer.

We believe both our customers and our company are benefiting from this method:

• Requirements elicitation and validation is performed progressively and during most of the projects duration, motivating a greater involvement from the customer.
• The customer can “see” a working system very soon (7-10 weeks after project start for the first version, and then a new version every 4-6 weeks).
• Including rework as a natural part of each sprint and the iterative nature of the method smooths the customer/provider relationship. In our experience, using a rigid ciclic methodology implies the use of strict change requests, and those tend to increase the number of hard negotiations and detriment the image of the provider in the eyes of the customer.

I’ll post a follow-up with real life experiences and results of our methodology in action.