Feeds:
Posts
Comments

Archive for May, 2012

About a month ago, I saw a presentation on agile BI with a couple of interesting statements and a disturbing conclusion. The conclusion was, that agile BI is not about delivering faster (or cheaper) but it is about delivering in arbitrarily smaller increments to end users. I will address this conclusion at the end of this post.

One of the interesting statements were that work in progress is a liability, which is actually a pretty good way of illustrating both why we have to deliver in smaller increments, but also exactly why we have to deliver faster.

A definition of work in progress

In business accounting, an asset is something the business owns that has value. The opposite is a liability, something that the business owes to someone else. So the question is, if work in progress is an asset or liability?

Work in progress (WIP) is defined as something that is only partly completed. It is often used in manufacturing to describe the materials, machine- and man hours that have been consumed (invested) to make a product. Until the finished product has left the assembly line or last stage in the manufacturing process, it is considered as work in progress. Commonly this is considered as intermediate inventory. An asset, something the business owns that has value.

In the specific context of DW/BI, consider work in progress as all the work done to analyze, design, develop and test the data warehouse, ETL process, dashboards, reports. In other words everything that is done in between identifying a business requirement and until it has been delivered in a fully functional state to the business.

Dealing with volatile “products”

Although work in progress is traditionally seen as an asset as per above, it is not always the case. In lack of better examples, consider your business requirements as if you were processing or transporting fresh fruit, and then reconsider if this intermediate inventory is still an asset or at least for how long? It should be rather clear to everyone, that it will remain an asset only for a short period of time, after which it no longer has any value.

If you agree that the business is constantly affected by all kinds of internal and external factors, that is directly driving business requirements towards the DW/BI platform, then this is exactly how you should consider your business requirements. Business requirements are volatile and the investment you make to meet the requirements is a liability that you have to minimize.

Why delivering fast is always important

In throughput accounting, you can increase your Return On Investment (ROI) by reducing your investment in inventory (work in progress) and reduce operating expenses. Minimizing the liability of work in progress by simply reducing the investment without looking at the speed of delivery is very unlikely to increase the throughput, which is the really interesting factor in increasing ROI.

Simply focusing on smaller increments without the time to market factor, is like saying that it does not matter when you deliver to the business, as long as it is done in small increments with the smallest possible investment. Try to tell your business that, the next time they stop by with another urgent business requirement. And if the business really does not care when you deliver, you should challenge them if it is even worth doing at all.

Keep in mind, that one of the twelve principles behind the Agile Manifesto is

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Read Full Post »

Today I had an email correspondence with one of my good partners in Belgium about his initial experience with user stories for requirements gathering. He had just finished reading User Stories Applied by Mike Cohn and despite that he was initially skeptic, he has already used user stories a couple of times for smaller things.

I have had similar talks to others, that had to overcome a barrier to change. To some this is just a matter of getting used to something new, to others it actually appears as a frightening wall to overcome. I guess it is quite common to have a certain level of hesitation or resistance, when it comes to doing things in a different way that we have been used to.

This makes me wonder. What drives you towards agile data warehousing despite this initial skepticism, hesitation or perhaps even fear?

Let me know what you think and get the discussion going.

 

Read Full Post »

It has been quite some time I last posted on this blog, one of the reasons being that we have been very busy building our new TX 2012 that was released last week. Also we launched a new support portal a while ago on support.timextender.com that takes place of mainly the how to topics I used to post here. The support portal has a knowledge base, forums a new ticketing system and lots of other stuff.

I am sitting in Toronto Pearson International Airport, on my way home from yet another eventful trip. It concludes the last few weeks of traveling where I have had the pleasure of speaking at the DWH Automation Conference in Belgium on How to achieve rapid return on data warehouse investments, followed by the PASS SQL Rally conference in Dallas, TX where we had a booth on the expo floor and finally here at Microsoft in Toronto, Canada. Microsoft presented their latest and greatest on SQL Server 2012 and I was asked to talk about Data Warehousing – The Kimball Methodology & Evolving Trends, followed by a 1½ days on hand workshop teaching agile requirements gathering, design and implementation to a group of consultants and end users.

I have literally spoken to hundreds of people from IT and business. Developers, analysts, data modelers, report developers, SQL programmers. They are looking towards agile and some have already started. And perhaps more importantly, I have not spoken to a single business person, that does not buy in to the agile message. It is a pleasure to be part of the agile movement, helping to break down the notorious reputation of data warehousing being too complex, expensive and slow to implement.

In Dallas our neighbors on the expo were WhereScape. And although we have very different products and not least strategic focus, we do share the passion for agile DW/BI and we had some very interesting discussions over the resistance most of the major consulting firms have against rapid tools.

We all often hear comments from these firms like “it looks really easy to use, so we doubt it can be used to handle the complexity of our projects”. 

And this leads me to a comment from one of the organizers of the DW Automation conference in Belgium after the conference. He said After another successful DWH Automation event, I keep wondering: how long can "body shops" keep this tide out?!? The tools are ready!

And I could not agree more. We are past the point where we have to discuss if tools like timeXtender can handle the job, regardless of customer size or complexity. And we have a track record to prove it.

The real driver behind the resistance towards both agile as such and rapid tools in particular, seems to be that they are protecting their services business. Most managers in these firms does not seem to like short iterations, as it makes it more difficult to plan their utilization of resources. I guess this must mean that customers are paying the price to satisfy their need for nice, long project iterations.

Comments are of course welcome :-)

Read Full Post »

%d bloggers like this: