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
- 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.
http://twitter.com/agilescout Peter Saddington
Interesting about the sprint 0… would be curious as to more details around that… considering the hybrid approach, what was the ‘value’ of the 5 week sprint 0?
http://ricardozuasti.com/ Ricardo Zuasti
From our experience the value items sprint 0 brings to the project is:
* Define the technology and architectural base for the system, specially interfaces: we deploy virtual banking solutions, which need to interact with almost all back-end systems a bank has, which usually involves several different software vendors and technologies. Therefore “setting the tone” of how inter-system communications will work and what the global system architecture will be is a very important risk reducing factor and usually takes several days/weeks (considering the usually high number of parties involved).
* Appease the customers mind by enumerating the systems requirements: it may seem of low value to the software development side of the project, but as I mentioned in the article our customers are usually very “nervous” until they know exactly what the system will do and when will they get each feature (even if this list and schedule changes completely later on by mutual accord)
* Finally, from our provider “side”, having a general look&feel and template prototypes is a real bump in the development that greatly reduces the variance of subsequent sprints development time (specially the first ones in the project).
We are applying our latest revision of the methodology to new projects so in a few months I’ll have fresh empiric data to share :)
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)