This article was first published by TDWI (The Data Warehousing Institute) in May 2013 as part of its Ten Mistakes series.  See the original article here if you are a TDWI member.

It’s been said that agile BI is simple but not easy. That is, the concept of working in short iterations, delivering your BI system in small increments, and evolving the solution based on feedback is easy enough for most people to understand. However, as with many things, the devil is in the details.

At its core, agile BI requires a fundamental shift in attitude, mindset, and culture—motivated by the core values and guiding principles outlined in the Agile Manifesto. This mindset shift is supported by a set of concrete practices and disciplines tailored to make up the agile BI methodology that best fits your organization. In my work with dozens of BI teams attempting to “go agile,” I’ve seen lots of mistakes. This Ten Mistakes to Avoid outlines the most common and recurring errors to help you avoid repeating the mistakes of others.

1. Believing agile is just a project management thing.
2. Thinking agile is just a developer thing.
3. Confusing agile with Scrum.
4. Failing to cultivate agile mindsets and attitudes.
5. Using wish-based planning.
6. Over-relying on specialized roles.
7. Limiting customer collaboration.
8. Not embracing adaptive scoping.
9. Measuring the wrong things.
10. Cherry picking agile practices.

MISTAKE ONE: BELIEVING AGILE IS JUST A PROJECT MANAGEMENT THING Agile business intelligence (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, and business partners, as well as project managers. Often, agile transformation is driven by the program management office (PMO), which can create a perception that agile is only for project management. When technical leaders and business partners are uninvolved in the agile transition, an impedance mismatch occurs between BI teams and their project managers. BI team members continue to operate in conventional ways while project managers try to impose agile disciplines and ceremonies on a team that doesn’t understand the fundamentals of agility. Adaptive project management techniques are central to effective agile BI. However, an agile project manager is just one member of a cross-functional team that works most effectively when everyone shares ownership of project planning, tracking, and monitoring. The agile project manager provides support, guidance, and servant leadership for the agile team. In return, team members partner with the project manager to continuously adapt and grow into a high-performing team. Organizations in which agile BI transformation is isolated within the PMO are almost certain to experience a chaotic transition and, at best, mediocre effectiveness. Agile BI requires substantial change, both procedural and cultural. This change must occur equally for all members of the delivery team. Doing so will ensure that everyone is galvanized around a shared set of principles and techniques.

MISTAKE TWO: THINKING AGILE IS JUST A DEVELOPER THING Agile BI is often perceived by management as a process to be imposed upon the BI team. I was dismayed once to hear an IT executive say, “To be more responsive, we need to increase the productivity of our BI group, so we are sending the functional team leads to agile BI training so they can bring agile back to their teams.” This myopic perspective by leaders is surprisingly pervasive. The ill-conceived reasoning goes something like this: BI teams routinely fail to meet business user expectations. Business users have lost faith in the ability of the BI team to deliver anything of value. Something must be wrong with our process, and agile BI sounds like a way to get more done faster. Therefore, our BI teams should become agile. This reasoning is flawed in at least two ways. First, it assumes the BI team is not already working as hard as possible and that there is more productivity to milk out of the team. Second, it assumes that agile is like a magic wand that, when waved over the BI team, will result in greater team capacity. Agile BI is simple to understand but difficult to do well. It requires commitment and cultural change from management, business users, and team members. Moreover, it requires a change in mindset by the customer, management, and technical communities. Isolating responsibility for agile BI to the technical team is a surefire way to experience poor results.

MISTAKE THREE: CONFUSING AGILE WITH SCRUM Scrum is perhaps the most well-known and easily understood of the agile methods. It consists of five simple practices and three defined roles. Practices such as short, time-boxed iterations (sprints) and daily standup meetings (scrums) are easy to introduce. The roles of Scrum master and product owner map easily onto existing roles such as project manager and business analyst. It is so easy to understand Scrum that many have incorrectly perceived it as the very definition of agility. BI leaders who want to experiment with agile can easily introduce Scrum techniques into their teams by reading one of the many books available on the subject. Scrum’s very simplicity has given rise to two common blunders—a tendency to view Scrum as sufficient by itself, and a tendency to re-label “waterfallish” behaviors using Scrum terminology. Scrum practices are solely focused on how to plan and execute a project in short sprints and adapt to feedback. It gives no direction about technical discipline or how developers should work. Many BI teams adopt Scrum but fail to adopt the technical practices required to deliver new production-quality working features every few weeks. Agile BI requires a shift in technical discipline as well as in project management discipline. Although Scrum is beneficial, it must be augmented by other techniques, such as those introduced by Extreme Programming (XP). Many BI leaders have mistakenly adopted the trappings and terminology of Scrum without actually changing the way their team works. Such teams continue to practice big design up front and testing as a manual, 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.”

MISTAKE FOUR: FAILING TO CULTIVATE AGILE MINDSETS AND ATTITUDES The natural tendency in most organizations is to seek prescriptive processes that will be better than current ones. After all, the easiest changes to institute are those that are simply distilled into a set of well-defined steps. It’s much harder to change the way people think and behave. As Fred Brooks noted in The Mythical Man-Month (Addison-Wesley Professional, 1995), there are no silver bullets. This remains true today, and agile methods are no exception. Agile is founded on a set of 4 core values and 12 guiding principles. These do not tell you what to do; they tell you what matters most. They are generally based on the notion that it’s best to evolve systems in adaptive ways to accommodate the inherent uncertainty about what is truly needed. Agile methods such as Scrum and XP introduce beneficial practices that are founded on these values and principles. Agile BI reflects continuous growth and invention of key practices. Conventional mindsets often emphasize fixed-scope projects, substantial up-front planning and design, testing as a finalphase activity, people working in isolation and functional silos, and tracking tasks completed rather than value delivered. Old habits die hard. Because there is not an explicit step or guideline for handling every complex situation that arises, agile BI requires a fundamental shift in our thinking. Effective “agilists” learn to think and behave in adaptive, experimental, and highly collaborative ways, basing tough decisions on a new set of values and principles rather than conventional ones.

MISTAKE FIVE: USING WISH-BASED PLANNING “We must deliver everything on the backlog in six months with the current team. I expect agile to make that possible.” This paraphrase is a variant of statements routinely uttered by BI leaders with unrealistic expectations. 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. Team capacity is a function of team size, skill, and project schedule. A larger, more experienced team has greater capacity than a smaller, less experienced one. Agile BI emphasizes capacity-based planning and creating a sustainable pace. Unfortunately, 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 limits, so they pressure the team to overcommit in an effort to do more. Agile expert Jim Highsmith refers to this tendency as “wish-based planning.” When teams overcommit, their work tends to be hurried and of poor quality. Testing is often cut short and design choices are suboptimal. Teams working within capacity limits tend to produce higher-quality and better solutions. 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 money runs out.

MISTAKE SIX: OVERLY RELYING ON SPECIALIZED ROLES Most modern data warehouse and BI delivery teams consist of a mix of highly specialized skill sets. We see ETL developers, data modelers, SQL developers, data architects, database administrators, testers, and BI developers, among others. Within these classes there is often further specialization, such as Informatica developers, Ab Initio developers, or DataStage developers. Many BI organizations are arranged around these functional specialists. The Informatica developers are in one group, the MicroStrategy developers in another, the Oracle DBAs in yet another, and so forth. Many organizations even have entirely separate quality assurance and business analyst groups that exist outside the BI team and report to different managers. Moreover, many organizations have a data warehousing group that is entirely separate from the business intelligence group. This high degree of functional specialization and separation is anathema to agile BI. Agile BI emphasizes cross-functional teams and favors generalists over specialists. Agile BI calls for continuous interaction (face-to-face whenever possible) between team members so that synchronization is implicit and “throw-it-overthe- wall” behaviors are eliminated. This does not imply that deep expertise in particular skills is undesirable. Effective BI still calls for this broad spectrum of talent. However, effective agile BI leaders cultivate environments in which knowledge is shared and skills are transferred. It is not uncommon for an ETL expert to also do some BI application development or some data modeling. This helps avoid bottlenecks that occur when the sole specialist in a particular area is unavailable.

MISTAKE SEVEN: LIMITING CUSTOMER 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 collaboration is an essential differentiator between projects that delight business users and those that receive lackluster response. Excuses for why customer collaboration is short-circuited include: “Users are too busy to be involved,” “Users are geographically distributed,” “Users don’t understand agile development,” “Our business analyst represents the users,” and “We don’t want users to see work in progress.” In fact, effective customer collaboration is difficult. Relationships with business partners can be tenuous. It is hard to coordinate schedules for frequent interactions. It’s sometimes difficult to get buy-in, and it’s easy to lose that buy-in if we waste customers’ time. Designating the business analyst as a proxy voice of customers is much simpler, but is a terrible mistake. Business analysts may understand the business but are not members of the user community and cannot adequately represent those users without their involvement. 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. They delight in knowing that they played a small role in the project’s success. Proper customer collaboration is difficult, but well worth the effort.

MISTAKE EIGHT: NOT EMBRACING ADAPTIVE SCOPING One of the hardest adjustments required by agile BI involves acknowledging that project scope is not sacrosanct. Conventional project management relies on up-front scope definition and estimating to derive the schedule and budget. This is based on the invalid assumption that up-front scope is correct and complete, which is never the case. BI users often don’t know what they want, and they won’t until they begin to see working BI features to which they can react. Agile BI emphasizes adaptive scoping within the boundaries of a generalized project vision. The product backlog is a living document to which requirements may be added, changed, removed, and reprioritized at any time during the project. The team’s job is to select the next most important items and deliver production-quality working BI features in every iteration. When time and budget run out, the team will have delivered the most important working features from the backlog even if not the entire backlog. Items remaining on the backlog are not a sign of failure to deliver total scope. Rather, they are either (a) justification for funding additional development or (b) an acknowledgement of work not done because it is not truly needed. Realizing that scope can be truly flexible and adaptive is one of the most disruptive mindset changes required by agile BI. Many BI leaders continue to maintain conventional attitudes about requirements management, using terms such as “change control,” “scope creep,” and “requirements freeze”—a big mistake in an environment that embraces change like agile BI.

MISTAKE NINE: MEASURING THE WRONG THINGS Velocity is valuable for a 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 use 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. This is one example of a broader class of agile BI mistakes that involve measuring the wrong things. Conventional project management measures (such as tasks completed on time, variance between actual and estimated task time, and alignment to original plan) often have undesirable side effects. Moreover, these measures fail to measure what really matters on any BI project—the delivery of maximum value and the creation of high-quality results. 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. Metrics that validate quality, such as test coverage and technical debt analysis, are more meaningful than taskcompletion metrics and work breakdown monitoring. Remember, you get what you measure.

MISTAKE TEN: CHERRY-PICKING AGILE PRACTICES Scrum only has five prescribed practices and three roles. Nonetheless, it’s surprising how many agile BI teams cherry-pick the simpler practices or even redefine the practices to suit them. This mistake is so prevalent that it has become known as “Scrum … but,” as in, “We do Scrum, but having a daily Scrum meeting is onerous, so we just do one per week,” or “We do Scrum, but twoweek sprints are too short, so our sprints are eight weeks long.” Scrum must be augmented with sound technical practices to be an effective method. Techniques such as test automation and continuous integration are essential to effective agile BI, yet few agile BI teams undertake these disciplines. Agile BI also calls for a shift in management and leadership discipline. These leadership behaviors are all agile management disciplines:

• Enabling teams to be self-organizing and self-managing
• Creating cross-functional, co-located teams
• Cultivating a culture of project transparency without penalties
• Rewarding early experimentation and failure

All of these, and other agile practices and disciplines, are important components of an effective agile culture. It is important to be rigorous when adopting agile BI. When only the easy practices are adopted and the harder ones are either abandoned or marginalized, the result is a confusing blend of conventional discipline and lightweight agile methodology. This mistake often results in (at best) mediocre success in applying agility to data warehousing and business intelligence.