Recently I was in a conversation where a PM declared “Agile’s just waterfall really fast – we can do that no problem!” Uh oh.
Like (most) everything, delivery methodologies are subject to fashion and trend, and Agile/Scrum/Kanban and the like are en vouge. Collective, I’ll refer to these highly cyclic methodologies as “iterative” or (little a) agile development. My interest being BI, I’ll take a little time discussing how these iterative delivery methods impact your BI delivery processes.
Generally, iterative development does a number of things to your teams. When operating effectively, it (among other things):
- Brings your users much closer to the development process.
- Multiplies the number of builds/deployments you do by a factor of LOTS (probably 10-20).
- Multiplies the number of tests (esp. regressions) required.
- Makes juggling project tasks more complex by putting many more “balls” in the air.
- Eliminates the formality (and safety) of predefined scope and quality gates.
A successful move to iterative development means planning for each of these, often in radically different ways that your current processes. If your plan is just “do it more often/faster”, look out! For instance, the cost of regression testing for quarterly releases is manageable using manually scripted test cases. QA has weeks to execute the tests, report defects, and retest. On a two-week cycle, this is either impossible or at least impossibly expensive. So, you either a) stop/severely limit regression testing or b) automate.