Agile/Scrum, Kanban, & Waterfall



We here at love developing software and delighting customers. Everything else – JavaScript frameworks, Rails vs. Django, NoSQL – are all implementation details in our quest to build spectacular products. As a result of this philosophy, we prefer pragmatism over fundamentalism, which includes how we develop software.

This article will cover each of what we see as the three major methodologies for developing software. Each of them have what we at perceive to be pros and cons. Those pros and cons largely dictated how we approached building

We firmly believe that offers a minimalistic interface to the very best features that each of these methodologies have to offer. That being said, we also recognize's way of doing things might not be for you. Please bear that in mind as you read through our philosophies on software development.



 Agile, of which Scrum is but one implementation, is a software methodology based on iterative and incremental development. Teams are self-organizing and cross-functional. Work is broken up into iterations, called sprints. Programmers meet daily to discuss what they're working on and what's blocking them. These meetings, called standups, in addition to the iterative development cycles, allows teams to quickly incorporate new data and priorities into the development of the product. Hence the name "agile."

The core tenants of Agile are codified in the Manifesto for Agile Software Development.

Fun Fact:'s Django project is named snowbird and the core application is named wasatch because the Manifesto for Agile Software Development was first laid out at the Snowbird ski resort in the Wasatch mountain range in Utah.


  • Short, rapid developments allow teams to switch gears in between sprints.
  • Standups encourage transparency and allow managers to spot delays and other issues in near real-time.
  • Cross-functional teams encourages teamwork.
  • Heavy emphasis is placed on providing value to the user.
  • Points, velocity, and sprints allow for a fantastic framework for estimating the pace of development and delivery dates.


  • Due to the sometimes frenetic pace, and daily standups, Agile/Scrum can be difficult to implement and maintain with distributed teams.
  • The heavy focus on the user and the small, cross-functional teams can sometimes lead to poor documentation, lack of focus on architecture, and other non-functional requirements (e.g. maintenance). It is for this reason that we put stories, tasks, defects, and tests all on equal footing in
  • Scrum asks that all team members eschew their respective specializations (frontend vs. backend, QA, etc.) and work as a single team. While a noble idea, in small startups we've seen this cause a lot of cultural friction.
  • While it's very well suited for iterative development of an established product, it can be difficult to implement and stick with when you're inventing a product from thin air.
  • Sprints are, essentially, batches of work. Often, particularly in small, fast-paced organizations, priorities bubble to the top quickly and can cause disruption in a sprint.




Kanban is a method of developing products with an emphasis on just-in-time delivery while not overloading developers. In recent years it has become a favorite of systems administrators and the DevOps crowd.

Kanban breaks work into types of work (e.g. Desktop Support) and states, or steps, according to the business's workflow. This creates a simple pipeline of work that is being worked on and often allows priorities to be disruptive without causing major issues. This is in opposition to Scrum where disruptive priorities are often held off until the next sprint starts.




  • Manifesting workflow as a pipeline with work states is extremely flexible and keeps the unit of work even smaller than a sprint. This reduces planning overhead and friction that arises when transitioning between sprints.
  • Extremely simple to understand and implement with a few sticky notes and a whiteboard.




  • Doesn't have much of a notion of estimating, velocity, etc., which can sometimes make it hard to estimate delivery dates and pace of development. To be fair, this is largely by design due to the nature of DevOps.
  • Often requires more behavioral change than Scrum.




Waterfall is how COBOL developers created banking software in the 80s. We're not really sure how it works. We're pretty sure it's how the Antikythera mechanism was developed. 


  • None


  • Too many to list.
Have more questions? Submit a request


Article is closed for comments.
Powered by Zendesk