If you decided to order website development from the IT company, then you will have to face the fact that sometimes you will contact with developers. It means that you will communicate with people from another area of work, delve into the work process, control and test their results.
IT companies don’t work basing on the one principle, there are different approaches to work with projects. And we want to tell you about software development methodologies for web applications. The differences are due to the fact of how the workflow is built, which tools are used, what principles and rules are emphasized.
Recently, some of these methodologies found the application in another area of business. So, when you finish reading this article, you will know something new and useful for your business too.
Typical 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 the development team.
Stage 1. Getting to know a client
After the company gets a message from a client that he or she wants to work with the developers' team, a project manager (PM from here) and a client’s representative discuss the client’s needs (or the specifications if clients already know what they want).
Stage 2. Discovery and project research
Discovery means that the development team only investigates client’s business requirements and decide for themselves whether they can really solve a client’s problem. An outcome is getting to know a client's goal, business specifics, and initial requests.
If everything is good and the development team can help the client, the PM passes the tech documentation and specifications to the Lead Developer, makes the project aims and requirements clear.
Afterward, the Lead Developer does the report to the PM, who, in his/her turn, discusses all the features and details with the client.
Stage 3. Wireframes and prototypes creation
Following is the work on the wireframes and prototypes in collaboration with the client and the team’s designer.
Stage 4. Design
Working on design comps until final approval. The company carefully asks for all the details about the impression a client’s project should create.
Stage 5. Development
Initial installation and configuration go first. Then developers set up all necessary settings of modules. They make sure every website page was approved, and the client has gone through demo versions of every feature on the website. It was a little hint from the development side to the client: check and test all the options. There are no minor ones when it comes to website usage. Believe us, your website’s visitors will notice every teeny-tiny bug.
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.
Stage 6. Quality assurance
Remember the hint from stage 5? Never ever omit the testing stage. After the integration test, we move to the functional and UI tests and end up with manual tests.
Stage 7. Post-launch QA and maintenance
Besides maintenance and support, the dev-team usually teaches the client how to use a website, manage it and add content, etc.
So, now you know how the process of communication between the client and the developers looks like. Let’s start to meet with workflow methodologies.
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.
V Simple and easy to understand and use
V Works well for smaller projects where requirements are very well understood
X Poor model for long and ongoing projects
X High amounts of risk and uncertainty
X The model doesn’t cater for requirements changing during the development cycle
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, 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.
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.
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 not consider people solely as a resource. People need more than a list of tasks.
Building Integrity In
Send complete information to the customer. Strive for holistic architecture.
Seeing the Whole
The most important thing in the Lean approach - to see how parts work as the 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.
V Lean central Idea - give the consumer a higher benefit by using smaller resources
V Lean main goal - creating maximum customer value by eliminating wastes
V Lean value - service capability meets customer expectations
V Lean waste - an activity that consumes resources but doesn’t create (doesn’t add) values
Officially Agile was born in 2001 from the Agile Manifesto to improve productivity in software development, but it’s now expanding into other areas (f.ex. 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 development process. A sprint usually is measured in weeks.
The Agile approach is all about customer’s presence and controlling (not necessarily physical). The customer should be ready to dedicate some time to reviewing sprint outcomes, assessment and (re)prioritizing. A client can test the 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, a client can change the project requirements on and off.
Some of the Agile principle:
- People and cooperation are more important than processes and tools
- The working product is more important than documentation
- Collaboration with a customer is more important than negotiating the terms of the contract
- Readiness for change is more important than following the original plan
V An agile company is very flexible quickly adapts to changes, iterates less while implementing faster, and is able to seize new opportunities as they appear
V High level of interaction between project team members
X The very high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation
X Risk of endless product changes
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 the 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 prioritize 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 from 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 role usually goes to Scrum Master. But since we have Skype 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 talk on 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.
V Timeboxed iterations prescribed
V Items must be broken down so they can be completed within 1 sprint
V A Scrum board is reset between each sprint
V Optimal Scrum team size is 3-9 members
Kanban (from Japanese: kan-visible, ban-board or card). Same as 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 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.
All in all, Kanban is built on three ideas:
V Visualization of the workflow
V Limiting the amount of the work in progress for the sake of efficiency
V The tasks from the backlog go strictly one after another
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, small releases (Kanban). Some authors consider Scrum is the subset of XP.
The XP practices are the following:
V Planning Game (instead of short iterations);
V Small Releases;
V Customer Acceptance Tests;
V Simple Design;
V Pair Programming (instead of code reviews in other methods);
V Test-Driven Development;
V Continuous Integration (instead of Integration tests in Lean);
V Collective Code Ownership;
V Coding Standards;
V Sustainable Pace.
Also, there are other agile workflow methodologies in the IT area: Crystal, Dynamic Systems Development Method (DSDM), Feature-Driven Development (FDD) and other. 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.).
Now we want to show you how ADCI Solutions starts to work with new projects. Let’s check our company’s approach.
ADCI Solutions’ team strives for delivering the best product for each client. That’s why we compose a brand-new project team every time we start a project. We try to be as flexible as possible for each new project. Our agile methodology experience comprises 11 years of successful work.
A Sales Manager conducts the first negotiations with a potential client. After this stage, the Sales Manager and developers start the discovery of a client’s business to understand how many resources will be needed for this project. There is a careful selection of employees based on their current workload and job specifications.
A project team usually consists of a team lead, back-end, front-end developers, and a web designer if needed. We believe that back-end, front-end, and web design work should be strictly divided between the team members. Each developer reports on the workflow process to the Team Lead (who takes a role of a Project Manager here), whose main responsibility is distributing the tasks and making sure the work is being done on a schedule. The Team Lead is the one in charge of communicating with a client. The Team Lead, in his/her turn, provides the client with information about the project and gives the client's feedback to the team.
We use Skype, BaseCamp, Redmine to interact with remote clients. Over 11 years of our work, we have carried out over 280 projects from remote clients from beginnings to end, so be sure, this work 100 percent is adjusted here.
That’s what the most popular development frameworks look like.
Go for the Waterfall approach if your project is quite simple and short and requirements are clear.
In any other case, 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 isn’t the best or worst agile methodology for web development, how you can see every methodology has own pros and cons.