Long gone are the years when to have or not a BI Solution (or Decision Support System) was yet an option. A company who choose not to analyze its data today won’t grow beyond a certain point. It has no tomorrow.

To have working BI initiatives is not easy, let alone simple. A sucessfull BI project depends on a lot of factors and to lead one is not a job for the faint of heart. Business Intelligence projects are experience- and knowledge-intensives. Even the customer must control a degree of education to reap the benefits.

A best selling book does not come from anyone armed with a word processor. A new software is not born out of the hands of its final user just because he/she has a point-and-click Java IDE within reach. Business Intelligence Solutions does not either. The whole big world is a complex place with less and less room for amateurs. Go educated or go extinct!

The Agile Manifesto

This was a milestone for the Information Technology Industry. The Agile Manifest broke the shackles tying projects to ever-late schedules in doomed iniatives, and opened up a road of unprecedent success. As a developer and manager I have embraced the A.M. and adopted Scrum as the means to implement AM. I ended using them both to do everything I do, including Teaching and building Business Intelligence projects.

Recently I became aware that, influenced by the A.M., I have brought some of those principles under a BI light, and I am sharing my insights here.

Agile Business Intelligence Manifesto

The highest priority is to help the customer to answer his questions through early and continuous delivery of quality data and tools for its exploration.

Changing requirements are a must because only so data exploration can shape new hypothesys and drive an increase in knowledge.

Deliver working advances on data platforms frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Take part in the customer’s problem: To help the customer answer his questions is to help him formulate them by employing specialized knowledge on tools and techniques.

A customer answering its questions is the primary measure of progress, so he can make new questions.

Conclusion

This list does not stand on itself, but rather extends the Agile Manifesto. It also does not take care of effective delivering the results, which should be achieved by using Scrum and a special, iterative technique for BI projects, soon to be posted here.

Personally I don’t agree that Agile BI is only about tools. It sounds like too little, leaving a lot outside, begining with the very customer.

I didn’t invent the above principles, I more like found them spontaneously sprouted and began guiding my work whilst studying and applying the A.M., Scrum and some other methodologies and strategies to my daily job. The statements I posted above are in fact the Agile Manifest adapted to BI needs as per my point of view. I missed a list like that a lot and as until now nobody made a movent toward them, I did. So, here is my proposal.

What is your opinion?


To my English speaking fellows a note: In Portuguese the generic third person is the male form – he/him/his etc. So when we say “he” as the meaning of “anyone” we also refers to women as well. So, I am not confortable with using “one” or “he/she” when refering to an unknown person, what led me to using “he/him” above in the place of a generic “customer”. Please! I have a lot of intelligent women as friends besides my own wife, and I would never downplay the importance of them! I just wanted to sweep the ethnical differences aside so not to taint the discussion or raise any wrong criticism. Right criticism is welcomed <grin>.

6 comentários sobre “A.B.I.M.

  1. The original agile manifesto was (and still is) a manifest on the changes needed to achieve better results in the software industry. The 4 sentences show a new path by providing new paradigms (or values).In your manifesto, I don’t see the changes that you want to promote.

    Since I’m in the industry, I’ve seen a lot of team struggling to deliver some BI solutions in a non-agile way. But if you ask them, they will agree with your sentences. Take a look to your first sentence, who’ll disagree with this? Your sentence is stressing the priority but I think it’d have more value and weight if you stress the “release early and often” part of this sentence (and in this case it’d mean the same than the third).

    More, I’d say that sometimes you go on the opposite of the original manifesto. Indeed, the first original sentence is “Individuals and interactions over Processes and tools” but your 4th sentences says (IMO) the opposite by promoting “employing specialized knowledge on tools and techniques”. This feeling is also reinforced by what you say about Scrum. Scrum is a nice and effective toolset but it doesn’t apply to all the situations available on Earth. Being agile is also adapting your methodology according to your environment and your stakeholders.

    All in all I’d prefer something like :

    * Release early and often over a process of delivering huge releases at a low frequency
    * Customer answering his questions as a key indicator of the project’s success over follow-up of a planning
    * Dealing with change requests and refactorisation over static requirements and building work-around on top of an initial solution.
    * Adapting tools to the customers’ needs and knowledge over providing the same tools everywhere.

    That’s my two cents :-)

    1. Thanks a lot, Cedric! That is the kind of opinion I was seeking to get. I understand and I agree with your comments: Really, sometimes it sounds repetitive, and in others seems to go in the opposite direction.

      Here is what I intended to lay out with that sentences:

      – The changes I want to prommote: Being to a lot of BI projects, all of them seem doomed from the begining because they seek and end of the project. BI projects has no end, so the right start would be “now we enter an endless journey seeking knowledge.” That, I think, is the biggest change I want to prommote;
      – First and third sentence look alike: You are right. With the first sentence I wanted to make the open data exploration vs. finished reporting products (be it ad hoc or a priori – it is not this kind of difference) paradigm clearer. In another words: The point is not to finish the project (because there is no “end”) but to be by the side of the customer, cattering to his needs – which came often under the form of more data needed (or the same data, reorganized.) Did I manage to get this point clearer?
      – With the first sentence conveying the importance of answering to customer more than walking the project to an end, the third sentence nows stands on it own more clearer, I hope. “If you are going to answer the customer”, I meant, “let it be sooner rather than later”;
      – On the fourth sentence seemingly work counter-sense the original AM, yeah, I agree. Reading it again through your eyes I can see it. I meant other thing: You know BI is a land (or an ocean) of buzzwords, lean mean baddass tools and techiques. Most of the time, I feel the customer gets draged (or rather sucked) by it into a senseless discussion in the likes of ROLAP vs. MOLAP vs. HOLAP or 3NF vs. Dimensional Modeling and so on. I wanted to lay out the roles: Customers be customers and experts be experts – let the experts choose the tools and techniques, and the customer declare the question answered or not. So it is not that I meant to valuate tools over people (or even the opposite, which I am partisan of), but to respect the knowledge the BI specialist has. I was trying to address the urge customer somethimes have over the team to use this tool instead of that one. I have to rethink it – It might be there is no need for the 4th statement;
      – I plea guilt of being a total sucker for Scrum, so your remarking on my bias I’d solve world hunger with scrum reflects the reallity. I have to work it out better, thanks. In fact I have come up with a draft of an agile cycle to develop multidimensional BI solutions (as OLAP) that might be a better and more clearer fit here. From that cycle there might grown a specific-BI set of project techniques.

      Your conclusion is in fact the form the AM is in today. As I want to make it more usefull for BI, maybe I am looking for it in the wrong place. I still feel it is important to distinguish betweem “answers” and “funcionalities” (as the former one goes away as soon as it is found, and the later stays and eventually evolves into more sophisticated ones.) I believe this is a corner stone to make BI more agile – to understand we are dealing with different mind sets and different forms of needs.

      Thank you very much for you unvaluable contributions, Cedric!

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s