Monthly Archives: January 2011

Agile practice in n tier “dependent” architecture


I am sitting in the office on the last day of the sprint, making sure we drop the “testable deliverable” and am making all the crime I can do in the name of Agile –if you have experience with a manager who thinks he knows all about agile after attending “Agile Training”, you will easily understand how we reached here.
Now if we are stressed how am I getting time to write blog –Ok let me cover what went wrong:

We have three group in development –Backend layer, UI layer and Midtier. Each group “Owns” the code, so if any issue arises in “other’s” code there is no way but to wait for that team to resolve –and am doing exactly that. We are not adhering to following agile practices

  1. There should not be any knowledge islands
  2. If there is any dependency due to resource constraints, (For example we have only on DB guy), dependencies should be well documented and
    communicated.
  3. Programming by interface: if all the layers adhere to the agreed interface and there is “Mocked Testing” to validate this, there should not be any
    integration surprises —ok at least in theory ;).
  4. Continuous Integration : Yes we do not have CI across different tiers. All tiers handle there CI but due to huge installation time for back end tier, any Integration has to be postponed till the end of sprint –it’s just not possible to update the back end tier with each of their update 

And thus, for me greatest pain is point 4 and am getting to write this piece because guys from DB layer are updating the server and I cannot do anything but sit and wait 
What is the solution/workaround:

  1. Documentation, Documentation and Documentation to make sure:
    • There are no last minute changes in back end contract on last day (As that is the pain area for us)
    • To validate the agreed upon contract
    • To resolve dependency when a person with “specific” knowledge is not around
    • Last but not, to avoid any finger pointing in a stressed situation when something goes wrong
  2. Mocks and stubs
  3. Simulate CI for the layer for which it’s not possible to update regularly
  4. Utilize status meetings to propagate or receive any changes at any of the tier as early as possible in the sprint