1. Waterfall vs. Agile: What project management methodology should your startup choose?
We’re living in the era of the startup. Every day we’re witnessing the baby steps of innovation, teams coming together to bring bright new ideas from the rough drafts of ideation to the eventual daily-life improvements of their consumers.
Got a brilliant, game changing idea yourself? Wonderful! Ideas are great! The only thing better than having a great idea is knowing how to implement it. Ideas mean nothing if there’s no process to take it from a cocktail napkin to a finished product.
So, where do we start? Well, there are a number of different methodologies suited to different needs of different organizations. Not every methodology works for every team. It’s all about finding the right balance of what works for you, your team, and, most importantly, getting the job done. We’re going to break down what we know, and from there, you decide how you’re going to get organized.
Waterfall is probably the oldest methodology to implement your idea. It’s very straightforward with a simple flow that follows as such: idea description -> implementation -> testing -> maintenance.
Easy, right? More than that, there are a lot of advantages to this flow:
- You know what the product is like at the end.
- This model is simple and easy to understand and use.
- In this model huge phases are processed and completed one by one, one at a time, and the phases do not overlap.
- It’s easy for a technical team to do time estimates and create the architecture of the product.
- You, as a product owner, can easily predict the cap of the project based on all of that.
But this methodology is almost never used nowadays. Why? Because it’s not flexible at all!
If and when you have a startup idea, the odds that you’re completely sure of what will work and what won’t are laughably slim. With the way waterfall is structured, you’re not able to make any changes during the development. So implementing any new feature will take the same time to market as the whole project.
Not only that, but you can’t test or edit any new feature until the whole project is done. Want to add or change something? It’s best that you go through the whole waterfall again, from top to bottom. So the risk factor here grows, and if you’re not sure about any part of your project—either in the beginning or as you go—you can’t test it before that phase of the project or the project as a whole is fully completed.
And when you’re going to work to improve the project as continuously as you’ll need to, you’ll be spending an unnecessary amount of time creating docs just to stay organized.
Really the only case when you should use waterfall is when the product requirements are stable and fully known, and the technology is understood. It’s not something you should avoid altogether, but it’s best fit for short projects with a relatively small scope of ambition.
So waterfall approach doesn’t serve well in most cases. So what does? Agile development for the win!
So what is Agile development? Well, Wikipedia positions it as such: “Agile software development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.”
In other words—and in stark contrast to waterfall—you can change the requirements throughout the development. Not only that, but all of the development is done and measured in small, time-based cycles called iterations. This is a process; it’s carefully organized, step-by-step, improving the product all while minimizing the risk in each iteration.
Agile methodology has a pretty straightforward manifesto (written by four developers at Snowbird Ski Resort :), and here it is:
- Individuals and Interactions over processes and tools
- Working Software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to Change over following a plan
That’s pretty much it.
One of the main differences between agile software development methods and waterfall is the approach to quality and testing. In the waterfall model, there is always a separate testing phase after a build phase; however, in agile software development, testing is completed in the same iteration as programming.
Because testing is done in every iteration (which develops a small piece of the software) you can frequently use those new pieces of software and validate the value.
2. Аgile Project Management Methodologies: Kanban vs. Scrum
Okay, so if we’ve agreed that agile development provides the necessary flexible to edit, revise, and refine our software development processes that waterfall simply doesn’t, we need to determine what school of thought is the most practical to stay organized.
There are several agile project management methodologies, but the most popular are Scrum and Kanban.
There’s a lot to unpack here. Kanban gives you more freedom, while scrum is much more strict. But we’re not going to take the deep dive into the finer details here, we just want to explain what each is and what the major differences are.
So the Kanban approach is basically splitting up all of the work into the small tasks (i. e. issue, bug, feature), organizing them into different cards, prioritizing them accordingly, and moving them through the one workflow like, “to do -> in progress -> done.” It’s up to you to choose what types of cards to categorize the tasks into and what would be the flow.
Here are a few examples:
The Simplest Variation
Something a Bit More Complex
More of a tactile organizer? Literally take it to the board!
It’s generally recommended that you limit the cards in the middle sections (like, maybe not put more than two tasks in “In Progress” section). This helps you better prioritize and deliver tasks.
For example, you have two tasks in the “In Progress” column (task1 and task2), but you want to get task3 done because you think it’s critical. Well, because a developer can’t work on three tasks at a time, you can’t have the first two delivered in time if you’re going to want the third one delivered before them. That’s what the limit’s for. If you think that task3 is more important than task2, just move task2 back to the “To Do” column.
Ultimately, the point of Kanban is moving tasks though the flow one by one and deliver them to the final section of your workflow.
Scrum is a methodology where you split all the work into tasks and the team delivers a bunch of them through equal time periods called sprints. Usually, one sprint is 1-4 weeks long depending on the project’s complexity. It’s a pretty strict methodology with predefined project roles and protocols.
Again, we don’t want to go too deep into the details, so the main idea of Scrum is you have a multitask team (i. e. designer, dev team, system administrator, QA engineer etc.) that brings a designated value to the project every sprint (like delivering a bunch of tasks or a particular user feature to the production). These sprints are then broken down into different protocols or ceremonies, the most important of which are Grooming & Planning, Standup, and Retrospective.
Grooming & Planning is when you and the team decide what tasks to put into the next sprint. This is where you essentially plan the value you’ll realistically add to the project during the iteration.Want to add tasks to the sprint in the middle of the sprint? Don’t do it! It is definitely not recommended. Why? You can not achieve your goals of the sprint. The main idea is you plan the sprint goal and everyone agreed that achieving this goal is the most important thing for the project during this time interval. Putting new tasks just adds the risk to achieving the goal idea.
Next ceremony is the daily Standup where the team spends some time every day sharing the status (“Here’s what I did yesterday, here’s what I’m doing now, what I plan to accomplish by tomorrow, and here are some of the obstacles I have encountered along the way”). Why’s it called a Standup? Scrum comes from the Latin word Standus which means—just kidding. But seriously, it’s called a standup because it’s actually better to do it standing because nobody on your team wants to stand for too long, so this actually helps your team keep focus on the discussion at hand. You get straight to the point without wasting time; more talk about the project, less talk about the weather.
Another important ceremony of Scrum is the Retrospective where the team takes time at the end of the sprint to discuss the previous sprint, what was accomplished, what still needs time, and what obstacles you encountered along the way. It’s important to talk about what’s happened so you can improve the process for the next sprint. Nobody wants to face the same obstacles week in and week out, so everyone discusses any and all problems they had during the last sprint to prevent them from happening in the next.
And that’s pretty much it. There’s a lot more to break down when it comes to the hierarchy of roles (Scrum master vs. product owner vs. team members), but we’ve covered the basics here. With Scrum you plan your work in equal time intervals, deliver on agreed upon value each interval, and improve the process continuously.
Okay, so we’ve got Kanban and Scrum. They’re both effective in their own right, but the main difference is that Kanban is task by task and flexible, while Srum is sprint by sprint and strict.
Here’s a little table breaking it down into a little more detail:
Roles & Responsibilities
No pre-defined roles for a team. Although there may still be a Project Manager, the team is encouraged to collaborate when any one person becomes overwhelmed.
Each team member has a predefined role, where the Scrum master dictates timelines, Product owner defines goals and objectives, and team members execute the work.
Products and processes are delivered continuously on an as-needed basis.
Deliverables are determined by sprints, or set periods of time in which a set of work must be completed and delivered.
Delegation and Prioritization
Uses a “pull system,” or a systematic workflow that allows team members to only “pull” new tasks once the previous task is complete.
Also uses a “pull system,” however, an entire batch is pulled for each iteration.
Modifications / Changes
Flexible. Allows changes to be made to a project mid-stream.
Changes during the sprint are strongly discouraged.
Measurement of Productivity
Measures production using “cycle time,” or the amount of time it takes to complete one full piece of a project from beginning to end.
Measures production using velocity through sprints.
3. What to Choose for Your Project
We’ve thrown out a good bit of info here. You’ve got your waterfall and your agile development. You’ve got your Kanban, and you’ve got your Scrum. So how do you decide where to go from here?
First of all, you shouldn’t choose a waterfall methodology if your project is complicated (which is pretty much any project harder than a business card). Not sure how big the scope of the project is? You might find it helpful to use a Stacey Matrix to understand the project’s complexity.
That a little too complicated to make a determination? You can shuffle things around into an easier one:
So if you have uncertainty with the requirements or technologies—or both!—you should look for as much flexibility as possible with agile development. Moreover, if you know your project or any phase of it is going to be chaotic, first of all, just go ahead and categorize it as complex from the beginning or don’t start it at all. It’s too risky otherwise, and, in any case, you should be planning for an MVP only at first.
Now, what to choose for the complicated or complex project (which most startups are)?
Our experiences have taught us that you shouldn’t even choose in most cases. We don’t know any team that uses pure, unadulterated Scrum that doesn’t stray from a single rule in the book. On the other hand, when the scope of your product grows while using Kanban, you might find it necessary to borrow more and more Scrum rules to better organize the work and improve the processes continuously.
What’s most important when it comes to deciding is to understand the framework and overarching guiding elements of both and then take and choose the best from both worlds. Start with Kanban to make it simple, and take whatever you need from Scrum when necessary.
Work it out. Trust the process. Be agile!