5 Common Mistakes in Agile BI Adoption

•  
• Misconception About Agility

Agile BI is much more than a project management technique. Creating a truly agile BI organization requires the involvement of leaders, developers, testers, architects, business analysts, stakeholders, business partners, as well as project managers. Agile BI requires substantial change equally for all members of delivery team, both procedural and cultural. This will ensure that the team is galvanized around a shared set of principles and techniques.Agile is not a magic wand that when waved over the BI team, will result in greater team capacity. Compartmentalizing responsibility for agile BI to the technical team is a sure-fire way to experience poor results.Scrum is perhaps the most well-known and easily understood of the agile methods. Many incorrectly perceive it as the very definition of agility. Many teams continue with Big Design Up Front (BDUF) instead of Just Enough Design Up Front (JEDUF) and testing as manual and final phase activity. They fail to deliver value every few weeks or seek feedback from business customers. This mistake is so common it has become known as “scrummerfall.”

• Creating a Comprehensive Design Up-Front

You do not need to create a comprehensive, detailed model up front. You only need a high-level vision at the beginning of the project and the details can be identified on a just-in-time (JIT) basis via model storming. There are several reasons for this.First, like it or not, the requirements are going to change throughout the project.Second, by waiting to analyze the details JIT, you have much more domain knowledge than if you had done so at the beginning of a project.Each sprint should be treated as a thin slice across the DW/BI landscape that delivers value to the customer. For agile DW/BI, the working software that adds value is a combination of queryable database schemas, ETL processes and BI reports/dashboards. The minimum set of valuable working software that can be delivered per iteration is a star schema, the ETL processes that populates it and a BI tool or application configured to access it.

• Wish-Based Planning

Agile BI is not a technique for getting more done faster with fewer people. Rather, it is a technique for maximizing value (by focusing on the most important things first) within the team’s limited capacity.Many leaders wish their team’s capacity were greater in order to meet all the demands of the business. These leaders have difficulty accepting these limitations, so they pressure the team to overcommit. Agile expert, Jim Highsmith, refers to this tendency as “wish-based planning.” Agile BI emphasizes value-based prioritization and adaptive scoping. This enables a team to build as much as possible within capacity limits. Even when they are unable to deliver 100 percent of the scope, they will have delivered the maximum value before time and budget runs out.

• Limiting End Users Collaboration

“Customer collaboration over contract negotiation” is one of the core values expressed in the Agile Manifesto and one of the first sacrificed by many agile BI teams.True customer or end user collaboration is an essential differentiator between projects that delight business users and those that receive lackluster response. When end users are engaged early in the project and their time is treasured, they become enthused by having their voices heard on a regular basis. They become an extension of the BI team, helping to shape the evolving product. They develop a sense of ownership in the outcome and become project champions with other members of the user community. Proper customer collaboration is difficult, but well worth the effort.

• Focusing on the Wrong Metrics

Velocity is a valuable tool self-managing team to assess its own performance and plan within its capacity. Velocity is a measure of how many story points an agile BI team delivers and users accept in each sprint.Unfortunately, management often misuses velocity as a measure of team productivity. Worse yet, some managers even attempt to allocate velocity to individuals to track each team member’s performance. When managers focus on velocity as a performance metric, agile BI teams respond by reducing testing, cutting design corners, and opting for speed over quality, all of which have undesirable consequences in the name of increased velocity.Agile BI emphasizes the importance of measuring the outputs of self-organizing teams rather than the ways those outputs are produced. Tools that monitor value delivered, such as burn-up charts, are more effective than performance measures such as velocity.

Focus should be on metrics that validate quality, such as test coverage and technical debt analysis, as these are more meaningful than task-completion metrics and work breakdown monitoring.