So here is a summarization of the key characteristics of Agile BI. This is simply a high level glimpse at the key project traits that are the mark of agility; not an exhaustive list of practices. Moreover, Agile BI is a development style not a prescriptive methodology that tells you precisely what you must do and how you must do it. The dynamics of each project within each organization require practices that can be tailored appropriately to the environment. Remember, the primary objective is a high quality, high value, working BI system. These characteristics simply serve that goal:

Iterative, Incremental, Evolutionary – First and foremost Agile Business Intelligence is an iterative, incremental, and evolutionary style of development. We work in short iterations that are generally 1-3 weeks long, and never more than 4 weeks. We build the system in small increments or “chunks” of user-valued functionality. And we evolve the working system by adapting to frequent user feedback. Agile development is like driving around in an unfamiliar city. You want to avoid going very far without some validation that you are on the right course. Short iterations with frequent user reviews help us ensure that we are never very far off course in our development.

Feature Driven Development – The goal of each development iteration is the production of user-valued features. While you and I may appreciate the difficulty of complex data architectures, elegant data models, efficient ETL scripts, etc. users generally couldn’t care less about these things. What users of BI systems care about is the presentation of, and access to information that either helps them solve a business problem or make better business decisions. Every iteration must produce at least one new user-valued feature in spite of the fact that user features are just the tip of the architectural iceberg that is a BI system.

Production Quality – Each newly developed feature must be fully tested and debugged during the development iteration. Agile development is not about building hollow prototypes, it is about incrementally evolving to the right solution with the best architectural underpinnings. We do this by integrating testing and QA early and continuously into the development process. Developers must plan for and include rigorous testing into their development process. A user feature is considered “done” when it passes all of the acceptance tests we can dream up, and it is “done, done”[1] when the user community reviews and accepts it as complete.

Barely Sufficient Processes – Traditional styles of BI development are rife with a high degree of ceremony. I’ve worked on many projects that involved elaborate stage gate meetings between stages of development such the transition from requirements analysis to design. These gates are almost always accompanied by a formal document that must be “signed off” as part of the gating process. In spite of this ceremony many BI projects struggle or founder. Agile BI emphasizes a sufficient amount of ceremony to meet the practical needs of the project (and future generations) but nothing more. If a data dictionary is deemed important for use by future developers, then perhaps a digital image of a whiteboard table, or a simple Excel workbook would suffice. Since our primary objective is the production of high quality, high value, working systems; we must be able to minimize the amount of ceremony required for other activities. 

Automation, Automation, Automation – The only way to be truly agile is to automate as many routine processes as possible. Test automation is perhaps the most critical. If you must test your features and system manually, then guess how often you’re likely to rerun your tests? Test automation enables you to frequently re-validate that everything is still working as expected. Build automation enables you to frequently build a version of your complete working BI system in a demo or pre-production environment. This helps establish continuous confidence that you are never more than a few hours or days away from putting a new version into production. Agile BI teams seek to automate any process that is done more than once. The more you can automate, the more you can focus on developing user features.

Collaboration – Too often in traditional projects the development team solely bears the burden of ensuring that timelines are met, complete scope is delivered, budgets are managed, and quality is ensured. Agile business intelligence acknowledges that there is a broader project community that shares responsibility for project success. The project community includes the sub-communities of users, business owners, stakeholders, executive sponsors, technical experts, project managers, etc. Frequent collaboration between the technical and user communities is critical to success. Daily collaboration within the technical community is also critical. In fact, establishing a collaborative team workspace is an essential ingredient in successful agile projects.

Self-Organizing / Self- Managing Teams – Hire the best people, give them the tools and support they need, then stand aside and allow them to be successful. There is a key shift in agile project management style compared to traditional project management. The agile project manager’s role is to enable the team to work their magic; and to facilitate a high degree of collaboration with users and other members of the project community. The agile project team decides how much work it can complete during an iteration, and then holds itself accountable to honor those commitments. The agile style is not a substitute for having the right people on the team.

---

[1] Josh Kerievsky describes a feature as “Done” when it is of shippable quality, passes all tests, and developers are proud of their work. That feature is “Done, done!” when the user accepts it as meeting the capability requirements.

4 Responses to “Here’s What Agile BI Is”