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.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


five + = 12



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close