The Danger of Pipelining and Time Slicing
As a BI Manager
I want to understand the impact of pipelining the Agile teams workflow
So that I know if it is an approach I wish to use
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.
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.
Other Blogs from this category
As a Product Owner or Developer I want I want to understand the different Agile testing methods So that I can decide which to useIn the word of Agile, there are currently three methods that can be used to improve our testing practices and to assist with enabling...
When talking about testing in a data project we have to first identify that the testing we need to do is similar but different to the testing we do in application development project. One of the useful way to identify these differences is to understand a number of the...
When do BI projects that require new data we know anecdotally that once we have acquired the required data from the System of Records the majority of our time and risk is applying code that transforms and/or augments data. In my terminology I call this "doing bad...
As a Stakeholder or Product Owner
I want to understand where the traditional planning documents fit in the AgilebI process
So that I know when I need to have them created
As a Product Owner or Developer I want I want to understand how to deal with a lack of clear acceptance criteria So that I don't delay delivery Acceptance criteria for a user story is crucial. Without it the development team and product owner...
As a BI Practitioner
I want to understand what AgileBI processes are
So that I know what processes to implement (and what processes not to)