Managing to complete an AgileBI build in three elapsed weeks is very very difficult. And by a build I mean from gathering requirements all the way through to delivering data and content that could be released to production if desired (i.e Done Done).

It takes an Agile Team a while to reach the maturity to be able to consistently complete all the tasks required in the three week window. For the first 3 to 6 sprints the are highly likely to not complete some stories and not quite make Done Done at the end of the sprint.

One of the dangers in a new Agile Team, or when you have an inexperienced or ineffective Scrum Master is that they will fall back to a typical Waterfall style of process. This also tends to happen if the Scrum Master is still trying to operate in the two week sprints they were successfully using in standard web app deliveries , rather than three weeks sprints that are more suited to AgileBI delivery.

This will result in them recommending a process that I call Pipelining. Pipelining is when you split the Agile Team into sub teams and have them all focus on a different part of the development process in isolation.

Typically you will have one part of the team focus on capturing requirements, another part of the team focus on development of Data, and the last part focus on content development and testing. So the data development team are one sprint behind the requirements team, and the testing team two sprints behind.

This approach introduces a lot of problems.

Timeslicing

Handover

Isolation

Backlog

Change Restriction

One of the many benefits of an Agile approach is the ability to decide to change what you are going to do next, before the next Sprint starts. This flexibility is one of the reasons we no longer have to do the big guess upfront. Priorities in an organisation always change, as the organisation changes and so the ability to change the next focus for the Agile Team when required is invaluable.

However if your pipelining it is much harder to change what the team are doing next. In theory you should still be able to change what the requirements team are doing next at anytime right? But in my experience for some reason human nature is such that the Agile Team is seen as a slow moving beast now that everything is a minimum of 3 sprints and closely coupled to a certain order (and that is assuming they delivery everything required in the first round).

Not to mention you now have to wait for 3 sprints (typically 6 weeks in a pipelining approach) before you can start to validate the value of the change.