eXtreme IT – Agile Methods

Bungy3s I was reading a competitor’s brochure the other day and then showed to Jim and we both agreed.  Really great stuff.

In their definition of eXtreme IT they are really referring to Agile development methods of which we are big proponents.  It didn’t go into great detail, but it did define the framework.  I looked for it online to see if I could link it, but could not find it, but had me think about how I would want to define the approach as we go after it.


  1. Simplicity
  2. Speed
  3. Flexibilty

Guiding Principles

  1. Get the Product to the user ASAP – whether data/application or other and then work together on continuos improvement and completion
  2. Change is part of the reality so embrace it.  If we are working in smaller intervals, we are not having to redo or change too much and if so, that is OK becase we clearly learned something we did not know then.
  3. Bridge the Gap – Everyone is working together in cross functional small and self sufficient teams.  Refer to both coffee conversations with Mark and Mike .
  4. Incremental Working Value is the goal, as defined by the project charter.  This must be sustainable and regular.
  5. KISS – The simple solution is often best.  We are not throwing away the conformance to standards or technology best practices, but we need to get to the value fast.
  6. Early and continuous development of working software
  7. Welcome changing requirements
  8. Communication – above all we need communication.  Face to Face, Audio, Video, Email, Collaboration tools.  All of these are crucial to our success.  So let me give you an example.

A client wants to move a Data Structure from a legacy Data Mart onto their Enterprise Data Warehouse.
This can be broken into some simple steps that follow and leverage our agile methods.  At Project X we call this our eXcelerate Data methodology.

  1. Take the existing Data structure and Move it into your target into a staging/working data store area
  2. Now move all the data you currently have in the existing structure
  3. In Parallel analyse/develop and test:
    – New ETL or better yet ELT to keep the beast fed (or modify the existing)
    – Views to support the Business Intelligence users/applications (or drop the existing SQL aggregates or views right into the structure).
  4. You now have a great deliverable to the business but not to IT
  5. Now we do the proper modeling, normalization and other items behind the views to increase performance and bring this into proper architecture and governance expectations.

What have we done?

  1. Allowed a framework to start delivering value to the business sooner than later
  2. Reduced the stress of the team who now have more time to do this as an iterative process of normalization
  3. Changed perception of business and worked with them to meet their needs
  4. Pissed off architecture and modelers in the short term, but actually given more time to see how the end use is going to shape up and focus on that.

Leave a Reply

captcha *