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.

Read Mistake #5: Task Switching

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.

Scrum, one popular agile framework, defines a neat role, the product owner, who represents the customers. The product owner is responsible for identifying and prioritizing the BI features the organization needs most and must be available daily to support the team by answering questions and providing feedback on results. BI teams think this sounds great! However, many BI teams ask a BI analyst to fill this role because it most closely aligns with the work he or she has been doing all along.

There are two common problems with this. First, a BI analyst usually does not have sufficient authority to prioritize the BI team’s work (i.e., authority from the customers to decide whose request is delivered first). Second, when the BI team supports many areas of the organization (as is common with data-focused teams), a single BI analyst may not have the knowledge or bandwidth to properly represent each of those areas in detail.

You can avoid this mistake by focusing on product ownership as a need to be met, not a role to fill with a single individual. Ask your customers to tell you how they will prioritize BI work and how they will communicate the priorities to your team. You may need to help them devise a process for this, but make sure you are facilitating the creation of an approach they will own—not something they have to comply with. From there, strong BI analysts can support the various areas of the organization by providing the delivery team with sufficient information to get started working on the top
priority items.

Read Mistake #4: Retaining Skill-Based Silos and Multi-Project Staffing

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.

Business intelligence (BI) teams are increasingly embracing agile approaches. The 2017 TDWI BI/DW Teams, Skills, and Budgets Report reflected that 79 percent of teams are now using agile for their development work, a significant increase from the 33 percent a similar report indicated in 2016. With so many teams “going agile,” it’s important for BI teams to keep a few things in mind that will help your agile transformation go more smoothly.

In this upcoming series of blog posts, I will the adress the primary problems I’ve seen in BI agile transformations. Fortunately, agile approaches provide solutions that prevent you from making these mistakes.

In fact, many of these mistakes come from teams only adapting part of the agile mindset because some agile practices appear counterintuitive based on our previous experience. Every habit we have, good or bad, serves a purpose. Some habits were created because they served a good purpose at the time, but now the world demands something different of us. We need to adapt our habits to a new way of working.

According to the 2016 TDWI BI Benchmark Report, “Once again, the use of agile development methodologies reached new heights of popularity in this survey, rising from 29 percent in 2015 to 33 percent [in 2016].”

Read Mistake #1: Assuming a New Software Tool Makes You Agile