This content originally appeared in TDWI. TDWI members can see the original here.
With so many teams “going agile,” it’s important for your BI team to keep a few things in mind that will help your agile transformation go more smoothly. This series, “10 Mistakes to Avoid In an Agile BI Transformation”, will show you how to prevent the most common pitfalls I’ve encountered in my experience as an Agile Coach.
We in the data industry have been trained and staffed for years based on specific skill sets that support specific steps in a waterfall-based approach to delivering projects. For example, it’s not uncommon for an ETL developer who uses Informatica to always work on project tasks that only require Informatica development and never work on anything else. A data modeler might only ever work on data model development and enhancement using a specialized tool such as eRwin. Our traditional project management approach was to staff these individuals on multiple projects at the same time so the person is “100 percent utilized.”
However, remember that a top agile priority should be early and continuous delivery of valuable BI results. In order to achieve this, agile BI teams must be willing to value delivery (speed and quality) over “utilization.” The fastest way to deliver a piece of value is to ensure all skills and minds needed at any step in the delivery process are available and ready to contribute without delay.
To keep a small team 100 percent dedicated to moving a single project forward, most agile teams will focus on developing multiple skills that each person can use beyond her or his primary area of expertise. When an ETL developer also has skills in analysis and testing, there will be little time when that person’s skills aren’t needed.
One thing that’s different between working on various tasks within a single project and working on one type of complex task across multiple projects is the latter can incur serious productivity costs. Imagine you have a primary skill in ETL development, and you’ve also been involved with the analysis leading to what needs to be developed in the ETL. Within that analysis you and your team develop testing goals and test cases that describe the behavior of the resulting BI feature. It’s not a hard switch to move from analyst and test planner to developer; you already know the topic well. Compare that to the effort it takes to be fully engaged in ETL development in Project A and then have to stop that and fix a bug found on Project B. As you will see in the next mistake, that big switch can be expensive in terms of effective productivity.