Agile Development in Web Projects
Current practice in web development often does not tap the full potential of today’s technology. While results are sometimes achieved (through more technology than anybody possibly needs), the development process itself is not state-of-the-art. Many times the process is extremely time and cost consuming - for both contractors and decision makers as well as other stakeholders.
Though much time is spent on the process, many legitimate desires and requirements remain unfulfilled. Or even worse: By the time the result of countless meetings and work hours finally goes to production, it is already outdated techologically or it falls short of the requirements of visitors and clients.
Most modern Content Management Systems offer the opportunity to completely redesign the development and relaunch of websites. Worksteps that were formerly more or less descrete from one another can be combined or even left out.
With more integration and quicker response to (internal and external) change, less time is being needed. Web developers are referring to this new working mode as „agile development“ - a technique that corresponds to the „Rapid Prototyping“ which has been around for some time in the manufacturing industry and proved to be successful.
Reach your goal in 11 steps and x rounds?
To date, the construction process of web pages was basically as follows:
- The client / concept provider thinks about the goals and target groups of the intended website and develops
- ideas about possible content and functionality, that translate to
- a content structure or navigation. On this basis the web company asks a
- graphics designer to provide a number of static sketches (Photoshop images) for the design part while
- system architects and programmers start to sketch diagrams of the site‘s organization and functionality. There is little coordination between these activities. The results are then
- presentend to the client. Subsequently they are discussed and modified and more often than not
- presented (g modified) a second time. When this is done, the web company goes ahead with the
- programming and implementation using a Content Management System, while the client starts to
- gather possible contents – in case he does not choose to outsource this activity as well. The results of all the work are then
- compiled in a first prototype that constitutes the input to another cycle of
- presentation, discussion and (most of the time) modification.
Many cycles of presentation and modfication may take place until the product is finally released. Meanwhile, a change of conditions or responsibilities on the side of the purchaser might lead to new stakeholders with new ideas entering the game. The challenge lies in the fact that the different worksteps of client and contractor are running independently from one another and are only coordinated when a „presentation“ or „milestone“ is scheduled, which can substantially slow down things.
The whole process brings to mind the times when managers considered it below their dignity to touch a computer. They had a secretay or assistant to deal with emails, print the important parts, put them into a mail folder and present them to the boss who would wait one or two days before he dictated an answer that the secretary had to transfer back into the mail system.
3. Methodology and benefits of agile development
With „agile development“ there is no need for paperwork and sketching. From the start the main development steps are made on the same basis that will host the web presence later on. Problems are identified early in the process, alternatives can be found before much time and money are wasted in dead end streets.
With agile development stakeholders can see at an early stage both how it looks and how it feels.
Navigation paths are not only purported via flowcharts or wireframes but can be simulated on a broader scale anytime the need arises. Even complex forms and functionalities are at your fingertips (though they are technically simulations). Questions or objections can be answered right away in meetings that can also take the form of a tele-cooperation. You change some parameters and a few seconds later you see the impact of a proposed change and you can discuss if it makes sense or not.
In practice, only the team can survive
The first prerequisite for success when using this methodology is an open-minded collaboration of all involved parties. Ideally they don’t just form separate teams that work in separate units and meet only to discuss intermediary results. In this setting, bad surprises are inevitable. Instead, all parties collaborate as closely as possible, so they can exchange deliverables immediately and respond to questions and challenges immediately, before they evolve into real problems.
Is kind of cooperation relies on mutual respect for the personalities and competencies of those involved. Agile work is always interdisciplinary work and it is based on the expertise of all participants.
Web developers hate to discuss with a graphic artist who insists on his graphical designs even though he‘s been told about the serious technical downsides and cost inefficiencies. The graphics designer feels offended by the technician who seems to be obstructing his work.
Later on in the development process the copywriter insists on double spaced headlines and texts that are way too long - not quite the way designers and technicians had planned it in the first place. And if things turn out really bad, the marketing department intervenes and says they imagined all this differently. All that stress can be avoided.
You can only undersand it if you see the real thing
Content is king in web projects. Presentation follows content and usage. It makes no difference whether you try to sell shoes, solicit donations, inform citizens or deliver professional content. A web offering is always a content-based service offering. If your service is better than other services, you have got the competitive edge.
You can only offer the best service, if you meet - or exceed - customers expectations in terms of content, design and technology. CMS systems have greatly facilitated agile, interdiciplinary work. Content and navigation structures can quickly be transferred to different systems. They can be moved or recategorized if the need arises. Templates control both HTML code output and design. These templates are developed by the front end developer and the graphics designer.
I have stopped sketching Photoshop images a long time ago. Instead, I start coding my designs immediately. This approach saves time because one step is eliminated. And if eventually some element has to be blue instead of red - no problem, thanks to CSS preprocessors it’s just a matter of seconds to implement the change.
After the preliminary considerations are complete and a general idea has taken shape, you build a basic structure within the system. This structure will serve as a work platform for all people involved. The copywriter inserts text, the front end developer - in close consultation with the designer - deals with the HTML/CSS code while back end developers care for data base applications etc. in the background. The team watches the application grow and take shape. If anything doesn’t fit together, they can respond quickly because everyone can see what the others are doing. Potential usability shortcomings are also identified early in the process.
There is another advantage to start working on the content as soon as possible: Back end developers and system administrators learn how to design optimal and low-maintenance processes for later continuous operation. The shorter time span between completion of the techological basis and the going-live of the website is another advantage.
From the beginning there is at least a basic set of contents available. Later on, when the web site is live, these contents can always be extended. In large projects there is even the possibility to include the first visitor’s responses in the further work.
Agile development relies on close cooperation all involved parties. This cooperation facilitates the project acceptance, too, which is another advantage of this approach. Generally, people know more about the project state and the trust that is built by working together reduces the risk of bad surprises arising shortly before the going-live.