In part 1 of 4, we will review the key differences between Agile
and Waterfall methodologies. In later installments we will look at modifying
Agile for BI, converting a team to use agile methods, and a brief intro to some
Agile Data Modeling concepts.
Why Agile? The short answer is money. You can start to see
return on investment sooner. Businesses won’t dole out millions of dollars and
wait several years to get a product (if they are lucky). The business
environment may have taken a dramatic shift in that time. Getting working
software to the business consumers in a timely manner is now required. Think of
it as the Minimum Viable Product
Let’s define the key concepts of each:
1. Construction projects run this way
2. Easy to measure against
3. Know estimated cost up front
4. Safe standard to follow
1.1. Individuals and interactions over processes and tools
1.2. Working software over comprehensive documentation
1.3. Customer collaboration over contract negotiation
1.4. Responding to change over following a plan
2. 80-20 Specifications. Start coding when 80% of the requirements are understood. Collocation will fill in the rest with only 20% effort.
3. Integrated QA
Now we can compare them at a high level.
Easy to measure against.
Know estimated cost up front.
Safe standard to follow.
Resources are often interchangeable.
Relies on initial Requirements.
Testing is left until the end.
Hard to change direction.
Rewards over optimism. Price to Win
Allows for changes.
Collaboration over design
Harder to predict timeline and budget.
Needs a strong team.
Needs significant time from business during project.
Now, some critics will say that Agile is great for
transactional systems; but, BI/Data Integration projects are too complex for
Agile. While out-of-the-box Agile does not lend itself ideally to BI, we will
discuss a few adaptations for BI/DI projects to make it work in part 2.
Labels: Agile, AgileBI