Agile development has been applied to software development projects for quite some time. In a white paper that was first published by Robert Holler in the May 2006 issue of Better Software Magazine, entitled "Five Myths of Agile Development," Mr. Holler addressed the following myths with respect to software development projects.

1. Agile Development is Undisciplined
2. Agile Teams Do Not Plan
3. Agile Development is Not Predictable
4. Agile Development Does Not Scale
5. Agile Development is Just Another Fad

In the past couple of years, we've begun to apply agile methods to business intelligence and data warehousing (BI/DW) projects.  Without a doubt, I've heard many of the same things addressed in Holler's white paper said about Agile BI from a number of sources.  Interestingly, when speaking with folks who are both familiar and unfamiliar with Agile BI, yet another set of misconceptions has arisen.  As a contributing architect in the development of Agile BI methods, I've compiled a list of Agile BI myths. As I sit here writing this blog post I'm not sure if I'll end up with ten, twelve or fifteen.  I encourage you to post your "Myths" here on my blog so we can discuss their validity. Who knows what I'll hear next!  At least for now, my list includes:

1. Agile BI is radical and new
2. There is no need to produce documentation when using Agile BI methods
3. Agile BI methods do not support sound BI/DW architecture principles
4. Agile BI displaces the software development lifecycle (SDLC) in its entirety
5. Agile software development methods can be applied without modification to BI/DW projects
6. When working as a part of an agile BI/DW team, anyone can work on anything, without consideration for roles and skills
7. Agile BI only works for small teams
8. Improvement in team velocity is all that matters
9. Agile BI methods only work well with seasoned, highly talented and experienced team members
10. All BI/DW tasks can start simultaneously because waterfall methods are no longer used
11. The BI/DW team must be collocated in order for agile methods to be successful
12. There is little to no correlation between story point estimating and project management estimating and budgeting

Look for future posts as I dispel each of these myths as we head down "The Path to Agility."

As we begin our dialogue on business and IT agility, I've always found it best to first set the proper context.  In my article, "A Business Context for Agile BI,"  my goal was to set the table for the macro view of Agile BI.  The next context that's important to understand is the foundation of agile methods.  While there are many flavors of agile, most of what I will be writing about is based on the Scrum method.  Having said that, I had a choice to make - should I first attempt to explain Agile/Scrum or should I assume that you are already familiar with it?  Hmm, what to do?  What I've decided is take the middle ground and point you to several great references in order for you learn more about the foundational concepts.  This way, credit is given where due and I can turn my attention to the nuances of the methodology and its application to BI/DW delivery.  In other words, you now have a homework assignment.

Without a doubt, the authors of the Agile Manifesto and the Scrum Alliance get credit for bringing us agile methods and principles in the first place.  Read the Agile Manifesto's 12 Principles of Agile Software as the starting point.  After that, take a tour of the Scrum Alliance web site as it's chock full of great information about Agile/Scrum and includes lots of great articles and where to go for training and how to become a Certified Scrum Master.  As you read through the information on these sites, keep in mind that they were developed specifically for software development projects.

Next, turn your attention to Ralph Hughes' book, Agile Data Warehousing to get a primer on Agile/Scrum and XP as it pertains to building data warehouses.  Hint: If you want to get the crib notes version of Agile/Scrum, read chapter 2.  From there, you can learn more about foundation concepts such as user stories, story points, burn down charts and other key components of Agile/Scrum.

Lastly, I'd encourage you to read Larissa Moss and Shaku Atre's book, Business Intelligence Roadmap.  In particular, Chapter 0, Guide to Development Steps, provides a great overview of the entire software development lifecycle (SDLC) in the context of BI/DW projects.   Why is this important to understand?  Because Agile/Scrum does not displace the entire SDLC, it augments and enhances parts of it.

After doing your homework assignment you should have a better understanding of the basics of Agile/Scrum and the BI/DW SDLC.  So what makes the contents of this channel different?  In a nutshell, the contents of this channel will morph the foundational concepts into a practitioner's view of the world, at times adopting the principles outright, and at other times, challenging them at their core.

As I'm planning writing several articles that explain Agile/Scrum within the broader SDLC (as defined by Moss and Atre) as well as methods for properly estimating projects beginning at Step 1 (Justification) and segueing those estimates into sprint cycles, I hope you'll take the time to get acquainted with the basics.  In doing so, we can start our journey on 'The Path to Agility.'