Web application development methodologies and approaches
As soon as you get in touch with a web development company, you enter another universe: a new language, many unknown terms and numerous questions that you need to provide answers to. The first question that a brand-new client of a web agency asks him/herself is “How does it all work?”. That’s a good question: you’d better know the rules before entering a game you want to win.
Today we want to tell you about methodologies for web applications development. The workflow is built differently in every approach, the tools used vary too, as well as the principles and rules that are especially emphasized.
After reading this article you’ll be able to tell the Waterfall from Lean, and Kanban from Scrum, and you will speak the same language as a developer.
Some of these methodologies found application in other areas of business. So, when you finish reading this article, you will know something new and useful for your business too. Who could stop you from using the Kanban approach in your grocery, right?
Typical web development process
Before you get acquainted with the methodologies of web product creation, it’s important to know what stages of development exist.
Consider a typical workflow of an IT company. Let’s take as a basis the situation when a potential client contacts a development team.
Stage 1. Getting to know a client
After the company gets a message from a lead, a sales manager and the lead discuss the needs (or the Scope of Work documentation if the lead already knows what (s)he wants). The sales manager briefs the lead about the desired outcome, the Definition of Done, timeline, budget, essential requirements, and possible bottlenecks. At this stage, the sales manager qualifies the lead and whether it fits the target audience of the company’s services: if a prospect needs a website and a PWA and a particular company builds only mobile apps, it’s definitely better to say farewells to each other.
Stage 2. Discovery and project research
Discovery includes a deep investigation of the lead’s business requirements and the framing of a rough solution.
- What technology stack should be used?
- How an application will be scaled further and does this tech stack address further needs?
- Is there a match between our proposed solutions and the lead’s vision?
- Does this solution fit a budget?
If the rough solution and the budget are accepted, the sales manager passes available documentation and specifications to a lead developer for further, more detailed investigation and estimation. After several iterations, the sales manager and the lead together create a description of the scope of work.
Here the sales manager takes off and the project manager or a lead developer steps in. The lead becomes a client.
Stage 3. Wireframes and prototypes creation
A wireframe is literally a draft or a schema of a future web page. It includes all the blocks that should be placed on the page and gives an impression of a page’s grid. Having the wireframes in makes it possible to provide a more precise estimate and sweat the details of the functionality.
Stage 4. UI design
Once the wireframes are complete, we can move on to the design of a user interface and apply brand colors and elements. A designer works on design assets until final approval. The lead developer controls the design process as the outcome should be realizable within the client’s budget.
Stage 5. Back-end development
In Drupal development which is our focus, initial installation and configuration go first. Then developers set up all necessary settings of modules.
After the pages are built and coded, and front-end developers applied designs, Drupal back-end developers make sure every website page is approved, and the client has gone through demo versions of every feature on the website.
Stage 6. Front-end development
Depending on the project, the front-end and back-end development can go either in parallel or the back-end is followed by the front-end. A front-end developer implements all visual features and makes sure everything is pixel-perfect, and that a website is cross-browser compatible. Be attentive to the front end: its state impacts important website metrics, including Core Web Vitals, and, in the end, it impacts website's Google ranking as well.
Stage 7. Quality assurance
If you’re the client, never ever omit the testing stage. There are no minor issues when it comes to website performance. Believe us, your website’s visitors will notice every teeny-tiny bug.
After the integration test, we move to the functional and UI tests and end up with manual smoke testing.
Stage 8. Launch
The bugs discovered at the QA stage are being fixed, the team finalizes everything and sets the final settings.
Stage 9. Post-launch QA and maintenance
Besides maintenance and support, the development team usually teaches the client how to use a website, manage it and add content, etc.
So, now you know what the process of communication between the client and developers looks like. Let’s get to know the most popular workflow methodologies.
Waterfall (“traditional”)
It is the simplest methodology of the software development workflow and the first Process Model which was introduced in 1970. In the Waterfall methodology, the development process looks like a stream, successively passing phases one by one. But the transition from one phase to another occurs only after the completion of the previous one, in other words, each phase must be complete before the next phase can begin.
The main disadvantage of this model - a change in one of the phases will entail the inevitable change in all subsequent ones. It means that the Waterfall model is good only for short and easy projects.
Lean IT
Lean is based on the unique production system created and used by Toyota (Toyota production system - TPS). Lean is about creating value with fewer losses, and waste. It’s not a methodology or a process: it’s a set of principles.
Lean IT is the usage of lean manufacturing and lean services principles in the development and management of IT products and services.
There are 7 main principles that Lean is based on.
- Eliminating Waste. Here waste is everything that adds no value to a consumer. In particular: excessive functionality; waiting (pause) in the development process; fuzzy requirements; bureaucratization; slow internal communication.
- Amplifying Learning. Short development cycles, early testing, frequent customer feedback.
- Deciding as Late as Possible. The decision should be made not on the basis of assumptions and forecasts, but after the discovery of essential facts.
- Delivering as Fast as Possible. The faster delivery is the faster a client can assess the created value and ask for some changes (if needed). The Lean philosophy followers prefer to do smaller batches of work since it doesn’t involve that many people and can be done quicker.
- Empowering the Team. You can’t consider people solely as a resource. People need more than a list of tasks.
- Building Integrity In. Sending complete information to the customer. Striving for holistic architecture.
- Seeing the Whole. The most important thing in the Lean approach - is to see how parts work as a whole and that all the team members are responsible for the project’s issues. Thus getting rid of a bug caused by a particular person not necessarily will keep the system healthy.
Though Lean is a great philosophy, it doesn’t offer any particular methodology, thus it can only be considered as a complementary part of the Waterfall model or some of the Agile models - read about them below.
Agile
Officially Agile was born in 2001 from the Agile Manifesto to improve productivity in software development, but it’s now expanding into other areas (for example, marketing).
Agile is a structured and iterative approach to project management and product development. On this system of approaches, flexible project management methodologies (Scrum, Kanban, XP, and others) are built.
Agile methodologies are an alternative to Waterfall or traditional sequential development.
In short, Agile is a time-focused philosophy that allows creating a project incrementally, dividing it into small pieces. One of its main benefits is the ability to adapt and change at any step and to supply only relevant products to the market.
There are no exact stages; time is time-boxed into sprints. A sprint is a time allocated for particular tasks and defined deliverables. The tasks’ value is supposed to be defined by a customer, who’s deeply involved in the web development process of a new product. A sprint usually is measured in weeks.
The Agile approach is all about the client’s presence and control (not necessarily physical). The client should be ready to dedicate some time to reviewing sprint outcomes, assessment, and (re)prioritizing. The client can test basic product version before a final release or even put a basic version on the market. That’s a really great approach for the markets where being first means everything. Also, the client can change the project requirements on and off.
Some of the Agile principles:
- Business people and developers must work together daily throughout the project.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Simplicity–the art of maximizing the amount of work not done–is essential.
Alike Lean, Agile is not the methodology, but more of an approach or even philosophy.
Scrum
Scrum is an agile development methodology based on the Agile philosophy.
Scrum initially was developed for managing and developing products. Starting in the 1990s ‘till nowadays Scrum has been used extensively worldwide in different areas of business.
In Scrum, it’s the team that decides how a task should be implemented, the documentation and specification writing is being omitted. The client doesn’t spend time on paperwork, he or she just specifies what should be in outcomes.
The Scrum team is being overseen (not controlled!) by a Scrum Master and a Product Owner (PO). The Scrum Master is a kind of a coach that helps the development team to deliver a high-quality product. The Scrum Master is not allowed to give direct tasks to the Scrum team members. The PO is a client-side representative, who reflects the customer’s vision and prioritizes the “wish list” of the tasks at the beginning of the sprint.
Again, time is boxed into sprints (2-4 weeks). As soon as a sprint is over, a team must present a ready-to-market app/product. The Scrum sprint starts by creating the Sprint backlog: several tasks that the team will turn from an idea into a coded solution.
A Sprint is accompanied by daily Scrum meetings, where all the team members plus the Scrum Master and the PO gather to discuss what has been already done and how they can empower the delivery. Each meeting is limited up to 15 minutes. If the PO can’t take part in a meetup, his/her role usually goes to Scrum Master. But since we have Zoom and loads of chats there’s no problem with communication.
The sprint is ended up with a retrospective: team members, the Scrum Master, and the PO talks about the outcomes, what’d been done and what hadn’t, and how the next sprint can be more successful. And, as already mentioned, the item made during the sprint must be shippable.
Kanban
Kanban (from Japanese: kan - visible, ban - board or card). Like Lean, Kanban was developed by managers of Toyota.
The main idea of Kanban is workflow visualization. It consists of creating a (physical) panel (Kanban board) on which you can visually mark progress. A kanban board may be shared by multiple teams or individuals.
It’s pretty alike Scrum, but with a few differences:
- no roles within a group;
- work isn’t boxed into sprints and being delivered continuously and one task at a time;
- changes can be made anytime while the sprint’s tasks are strictly defined.
Extreme Programming (XP)
XP is believed to be one of the most controversial agile methodologies. It has many things in common with Lean, Kanban and Scrum: allotted time (1-3 weeks), continuous testing (Lean), continuous planning (Scrum), customer involvement, and small releases (Kanban). Some authors consider Scrum to be a subset of XP.
The XP practices are the following:
- Planning Game (instead of short iterations);
- Small Releases;
- Customer Acceptance Tests;
- Simple Design;
- Pair Programming (instead of code reviews in other methods);
- Test-Driven Development;
- Refactoring;
- Continuous Integration (instead of Integration tests in Lean);
- Collective Code Ownership;
- Coding Standards;
- Metaphor;
- Sustainable Pace.
Dynamic Systems Development Method (DSDM)
DSDM framework uses the famous Pareto principle - 80% of the system can be deployed in 20% of the time. It’s oriented toward rapid product delivery. You won’t be surprised to hear that DSDM is all about client and team collaboration, frequent delivery, and integrated testing.
One thing that puts DSDM out of the Lean and Scrum line is that the tasks can be removed from the backlog if they constrain the delivery of more important features.
Conclusion
It was a long read, huh? Yet, there are other Agile workflow methodologies in the IT area like Feature-Driven Development (FDD), the Crystal methodology, and others. The overall advantage of all agile methodologies is the ability to adapt and change at any step (depending on feedback, market conditions, corporate obstacles, etc.).
That’s what the most popular web development techniques look like.
Go for the Waterfall approach if your project is quite simple and short and the requirements are clear.
In any other cases, we’d suggest you choose a team that uses any of the Agile methodologies: they’re flexible, easily changeable, and give both the team and the client enough freedom. There is no best methodology for web development: as you can see every methodology has its own pros and cons.
