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.
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. Re-prioritize often. Collaboration over design Continuous testing.
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.