Agile Web Development For Major Projects
Needs analysis > planning > development > integration > testing > deployment > maintenance
Usually each stage of the development is handled by a separate different team- it’s characterized by distinctive stages in development and repeated handovers, hence the importance of tools and documentations to standardize the specs across all stages.
Think of it as the chains of conveyor belt in manufacturing. Specialization is key to this methodology, where time and skills play a critical role in getting the project done effectively.
It is however, plagued by some flaws:
- It is not possible to identify all the requirements in the early stage. A client could not possibly identify all his preferences in the ‘needs analysis’ stage, furthermore web consultants couldn’t possibly educate everything about effective web design in a definitive period of time
- Agreeing to a specification early on sometimes is a combination of lucky guess and desperation. Developers eager to get the project going will give the green-light to enable them to test the concept. Failure later on to make it practically work may jeopardize some or all of aspect of the project.
To mitigate the above, web developers provide strict terms and agreements to their clients in order to make the waterfall flow smoothly. Things like “3 revisions to design comp”, “2 edits monthly for website maintenance”, and “additional dollars for each additional page”.
There are problems. If it takes several attempts for a client to come out with a very good web copy (let’s say the tagline for example), but couldn’t afford it because changing it in the ‘deployment’ stage will incur additional cost, than we have to settle down with a website that’s profitable for the developer and crappy for the client. If the tagline doesn’t work, it will be a cost-efficient project with a less-effective copy. Not an impressive addition to our portfolio.
If user input is crucial, than we shall not limit the number of revisions, or the period for planning, or set the deadline for finalizing site structure, or the last date to decide which photo goes on the header. If the user is giving the input, chances are they’re the expert in their business and not everything they suggests are aesthetically-driven. They may be suggesting things that work for their businesses, and limiting their input will be bad for the website.
Enter agile methodology.
Iterative and incremental, that’s how Agile methodology in software development (in this case, a web design) works. It means release early, release often. It means deploying the website while still expecting more user input. It means changes are for the good.
Needs Analysis > Develop > Deploy > Analysis > Develop > Deploy …….
In short, release early, release often.
A picture on the wall might look differently than when you see it listed on eBay. Completing the live website first may give a very good perspective of what’s working and what’s not, so don’t wait for the clients to give all the necessary decisions before commencing the project. Give them live website to tinker with.
This approach, however, is not meant for small websites and mini projects. Agile methodology has its own demand:
- Businesses and developers should work hand-in-hand, side by side to make it work. Frequent face-to-face communication is a must to make the approach sensible.
- Developers should free themselves from exclusive tools to get the job done, or the time it takes for learning the tools will render the method pointless. (you’re not agile when you have to learn chopping using 11 sets of knife)
- Be prepared for spending more development hours and money. Contracts are regularly flexible and can be indefinite.
It is a rage when it was conceived, but if we implement it blindly in every web project, the affordability of setting up a web presence may be changing. And it’s for the worse.