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
Advertisements

About ChandanPandey

Try to come up with a good design as by product of good coding practices

Posted on January 4, 2011, in Agile and tagged . Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: