We’re going to talk about the traditional waterfall approach in detail and contrast that and compare that with the agile and scrum approaches and really dive in deep from that perspective. Let’s think about the way that tools work in our BI methodologies and how we have deliver things historically. We go through these different phases, and we have to build different components of the solution.
If we think about the people and the processes that the traditional waterfall methods entail, what we end up doing is creating a lot of our requirements either in Word or Excel and doing a lot of data entry, and then we go to the analyst. In the analysis phase we may do the same thing, and so we do a lot of redundant work. We do a lot of Excel work and do our maps, and we build it to a data modeling tool and rekey again.
There is a lot of interpretation and discussion and paper passing back and forth and as we begin to deploy the solution through the different phases and build the different components. What we have is a lot of non-value added labor, and it’s very inefficient, and it’s very time consuming and it’s a very error problem.So the idea is can we do something different? As I was saying in the old way we do a lot of Word and Excel and PowerPoint, and it costs a lot of money to design and manage these documents.
| #1 Ranking: Read how InetSoft was rated #1 for user adoption in G2's user survey-based index |
|
Read More |
Can we create an automated, online, governed set of processes within the agile framework, and the answer is certainly we can. And we are going to show you talk about the agile framework and the methods. We’ll show you how that could be coupled with technology to really eliminate a lot of the manual non-value added work. So in terms of the theory behind this, and we’re going to get into the practice of it. Before we begin I want to make a distinction between scrum and agile and how I choose to use the terms. Scrum to me is a set of project management techniques, and agile is a development life cycle.
The development lifecycle we’re going to talk about has things called value chains. We’re going to talk about methods integration and story generation for the components we have to build. The focus of the rest of this presentation is around the agile part of the equation, not necessarily the project management part of the equation.
I believe there are two different perspectives in terms of the any application, certainly a BI warehousing application, the executive perspective of the project and the development or lifecycle perspective. In the agile/scrum world the executive perspective where we create a release backlog mean that there are the large sets of releases centered around business themes or goal statements in terms of what the businesses try to accomplish.
And from the project perspective we create what’s called the product backlog which are articulated in the forms of stories or questions, and then we have the delivery backlog which are the story features or the chapters, and these are what we give to the development team to produce the actual set of deliverables.
In the executive method we use business goal objectives. We use a technique called facts qualifier matrices where we begin to get the business to define measures and things of interest and then begin to define them along dimensional lines such as geography, time, customer, et cetera.
And we also need a somewhat good estimating model at the beginning of any project lifecycle to allow the business to understand what the costs are going to be. That’s really one of the challenges we have is trying to come up with a good estimate of the work before the work begins, and what we’ve been able to do is grade some estimating methods and the tools that get us within plus or minus 5% in the justification phase.
If we set the goals, the business goal objective and do the facts qualifier matrix work correctly, we can get actually a very reasonable estimate as opposed to telling the business plus or minus 40 or 50% which causes all kinds of problems because the business goals gets funding and then often times if the budget really is plus 50 or 60%, and even though we try to account for that in our estimate with that plus or minus, that just simply goes away. That warning is forgotten, and all the emotions begin to creep in.