Using Agile to Develop with Lowered Risk
This page covers using Agile to develop with lowered risk as compared to the Waterfall method.
What is Agile? It’s an approach to development that allows a project to be broken up into distinctly and autonomously developed sections, in a sequence; the event sequence implying that you can’t have multiple teams concurrently developing multiple dependent tracks for the same project because each step is likely to be dependent on subsequent ones. So Agile is a bit like working with an object database or an object SDK like Java, allowing a task to broken into mutually exclusive parts or black-boxed objects.
The opposite of Agile is called the Waterfall method of development for software, which actually stems from the manufacturing industry such as building a plant to make cars; so just imagine how expensive it is to rearrange the bits and pieces in a Caterpillar tractor factory just after factory’s been built. Software development is much easier to rearrange mid-project or even after it’s all built, as compared to some kind of hugely expensive manufacturing or engineering project. Yes it is!
So Agile was devised and is now being gradually adopted easily by some, and painfully by some of the more traditional types of software engineers. Then again not every software development project can be built using the Agile method but given the advent of object technology it would make sense that many software development projects can be built in simpler to manage sections. So why isn’t everyone using Agile? Tradition? I hope not.
Sometime in the recent past some of the processing associated with data warehousing was renamed to something called business intelligence, and the reason was because data warehousing had become of age to a certain extent in that its ownership and purpose was being highlighted as being one of business oriented. So it is now a recognized fact that the business side rather than the operational side of a company has more of a vested interest in guiding what data warehouses deliver to its customers, which is also the business side of a company (data warehouses are often for internal customers). The reason why is because a data warehouse can be used to forecast future patterns based on past trends and thus what the data warehouse delivers can have a major effect on how the business is run.
The result is that the Waterfall approach of functional specifications defining a software product from start through to completion, is now changed to a financially leaner step-by-step process that is broken down into somewhat autonomous parts, which can be developed one after the other. Also flexibility is built into the process such that the business users can literally changer their minds anywhere during the development process, even in the middle of a sprint, probably driving the developers a little crazy with frustration. Consequently the business users do need to have an understanding that they cannot place unreasonable demands on technical developers such as allowing deadlines to be adjusted as constant changes are made to requirements, never meeting any kind of deadline whatsoever.
In conclusion the Agile approach involves ownership by business users as opposed to software developers, in addition to lots of frequent changes without the need for technical people to be sticklers for sticking to requirements documentation; the idea is to allow for the business users to change their minds during the development process so as to allow for a product that matches business requirements rather than a technical specification that could be out of date the day it’s printed. Also tolerance to code rewrites and a lack of fixed price constrained contracts are important facets of the Agile approach – they would be. The big problem with the Waterfall approach is that it is inflexible as it requires sticking to a specification that runs through a project right from start to finish, and any changes during the process are not only expensive but also even psychologically difficult to deal with – and also very frustrating. In short, the Waterfall approach is really a very traditional and retrogressive approach, and possibly even culturally inappropriate to a field that is by its very nature progressive because it is constantly undergoing enormous change, increasing in capabilities every eighteen months – so why did it take us so long to start using the Agile approach? It should not have.
Comments are currently closed.