Agile Zone is brought to you in partnership with:

I’m a software engineer. I got my first computer when I was 7 and have loved programming ever since. I’ve been developing corporate web applications since 1999, mostly using Java based technologies, but I like to try and explore a little bit of everything interesting going around the web/mobile technology scene. I like hard rock, RPG video games (all flavors), science fiction and fantasy books, and almost all movies (unless they star Sandra Bullock or Hugh Grant). Ricardo is a DZone MVB and is not an employee of DZone and has posted 16 posts at DZone. You can read more from them at their website. View Full User Profile

Defining an Agile Methodology for Orthodox Environments

05.01.2012
| 3988 views |
  • submit to reddit

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.

  • 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 :)

Published at DZone with permission of Ricardo Zuasti, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Paul Russel replied on Sun, 2012/06/10 - 1:34am

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?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.