Introduction
In the web development world, everything is in a constant state of flux. I believe that embracing change and adapting to the new state of things is paramount. Taking a stance like this can force you to look at big picture questions like “Does our current process work well for our department?”
In this article, I’m going to take a high-level look at a few development methodologies, touch briefly on the differences between web and software development, and review some of the changes we, at Zion & Zion, made ourselves to evolve our web development process.
Note that some of this is highly subjective. The feedback I provide is based on first-hand experience in executing these methodologies and from industry articles I read on the subject matter, bringing myself up to speed on what experts say work for them. However, this article ultimately shares my opinion of how I feel they work for my specific challenges. If I critique an approach you hold dear, please know I’m not trying to be a creep. Without further ado, let’s dive in!
Development Methodologies
Waterfall
The waterfall methodology follows a very strict, linear process and is the most popular, non-agile approach to software development. All requirements must be gathered before any development occurs.
The Good
- Super Fast to Learn: The waterfall model is so particular and regimented, it’s easy for a team who is unfamiliar to quickly adopt it and hit the floor running.
- Enforces Discipline: The phases of the waterfall model have clearly defined beginning and end points, which makes it easy to share status updates with stakeholders and clients. By focusing on requirements and design before writing any code, the team can reduce the risk of missed deadlines or unforeseen complications.
- Enforces a Well-Documented Approach: The waterfall approach relies heavily on documentation for every phase, resulting in better understanding of what the deliverables will be for the project. A side benefit of having such documentation is that there will be a paper trail for any future projects, or if stakeholders need to see more details about a certain phase.
The Bad
- Painful Requirement Phase: One of the first phases in a waterfall project is to talk to clients and stakeholders to identify their requirements. However, it can be difficult to pinpoint exactly what they want this early in the project. Oftentimes, clients don’t know what they want early on, and instead, learn and identify requirements as the project progresses. I’m sure we all can relate to that!
- Slow Delivery: Since so much planning and documentation has to be done upfront in a waterfall project, stakeholders and clients won’t see working prototypes until very late phases in the process.
- Lack of Versatility: If changes need to be made after development has already begun, the ramifications become expensive really quickly. Since its process is so strict, the team cannot go back to a previous phase without starting the process over from the beginning.
Kanban
This agile approach was originally inspired by Toyota back in the 1940s. They modeled their engineering process based off how supermarkets stock their shelves. Supermarkets stock just enough product to meet consumer demand, and because inventory matches consumption patterns, efficiency goes through the roof. This translates to software teams by matching the amount of progress to the team’s capacity.
The Good
- Super Fast to Learn: Because the Kanban methodology is so visual, it makes it incredibly intuitive and easy to learn. You can quickly assess where you are with your immediate tasks as well as the project’s status as a whole.
- Helps You Deliver Features Fast: The entire team is able to help ensure the work is moving quickly and successfully throughout the process. Focusing on continuous delivery helps deliver client updates and feedback as quickly as possible.
- It’s Flexible As Hell: Since there are no set sprints to worry about, you can evolve and react fluidly to changes at any time during the development process.
The Bad
- Incredibly Dependent on the Quality of Your Backlog: If you don’t keep your backlog up to date, you’re highly susceptible to code refactoring since you were working off inaccurate information or delivering out-of-date features. LA-WOMP!
- Planning Concerns: A common complaint with Kanban is that each task, or card, does not have a time estimate associated with it. They are only marked with what phase it’s currently in (backlog, in progress, code review, or completed). Even though you may only have a few checklist items left on your to-do, those items may be difficult to assess from a timeline perspective.
Scrum
Not to be confused with scrubs, which get no love, scrum is the most popular implementation of an agile approach. It employs several roles for the team to adopt and several ceremonies to perform on a regular basis during a project timeline.
It has been said that agile development isn’t just a set of ceremonies. It’s a cultural and technical philosophy. Before you roll your eyes at how pretentious that statement may sound, allow me to explain. The culture of the entire organization must get behind this approach. The powers that be need to acknowledged is that quality is more important than scope or schedule, which as we know, can be a hard pill to swallow for some organizations.
Web Development vs. Software Development
I once heard someone make the comparison between web development and software development with a horse and a tractor; “You can get them to do pretty much the same thing but when one breaks down you can’t really fix them the same way.”
Web development is essentially a branch of software development so, what this bizarre yet strangely accurate comparison points out, is that each branch has its own particular idiosyncrasies, best practices, and caveats regarding design, development, deployment, and maintenance. So, in effect, they may seem the same, but there are core differences that need to be accounted for. Agile methodologies focus on software development in general, but often need to be tweaked depending on your discipline/branch and how your organization does business.
Our Web Process
Speaking of adjusting processes based on how your organization does business, allow me to show you how we have evolved our agency’s website development process to do just that.
This previous approach didn’t allow us to adjust and adapt as we developed the original concept. Oftentimes, things came up during the development process that the original plan didn’t account for, or a better idea presented itself, but we felt compelled to deliver what was originally asked for instead of being flexible enough to adopt that better idea. This left us fighting our own convention. A change was needed and I ain’t too proud to beg for a new process.
What evolved from our previous linear process was a spiral workflow that allowed all departments to have more influence during the entirety of the project. This approach helps everyone stay on the same page during the entire planning phase and allows for adaptations to occur naturally, without fear of being too committed to the decisions that have already been made. It also helps to increase the frequency in which developers can provide feedback. This helps keep the project within scope and head off potential programming hurdles up front.
Internally, the web development department adopted a Kanban-esque approach, which gives us the agility we need to react to changes as often as necessary. The modified waterfall model above illustrates how changes are handled after development has begun. This iterative approach allows for problems to be found, assessed by the relevant departments, and then fixed without having invested a large amount of time into development.
Conclusion
In this ever-changing world of web development, you can easily find yourself assessing your existing process for pitfalls and areas of improvement. I would encourage you to do some research to find out what works for others who have similar challenges. Something they do may inspire you to think of a solution you can then adapt to your own needs. Every agency’s priorities and challenges are unique, so don’t be afraid to put your own spin on how you execute a process. And remember, a little TLC will go a long way.
Resources
Detailed Rundown on Scrum – https://www.atlassian.com/agile/scrum
Detailed Rundown on Kanban – https://www.atlassian.com/agile/kanban
What Agile Means for The Everyday Developer – https://www.atlassian.com/agile/developer