Don’t Go Chasing Waterfall [Methodologies], Stick to Agile

There are a number of differences between the traditional waterfall approach to project management and agile project management? In a number of ways, Agile is much more efficient that waterfall. But does that mean it will work for your next project? Learn more about agile in this post.

salt and pepa waterfalls agile

Don’t go chasing waterfall [methodologies] please stick to the scrums and the sprints that you’re used to.

Agile: Where Product is Delivered to the Customer in Small, Regular Increments

As Project Managers, we have many options when it comes to what methodology to use in our projects. Agile, Lean and Waterfall are all popular choices and each has its place in the realm of project management for both web and software development. Many agencies combine a hybrid of these methodologies to address specific project needs vs. being purely agile or waterfall. We’ll focus on Agile Development and the benefits of using this method for custom development projects.

Agile aims to provide iterative and frequent small releases throughout the project, allowing team members and customers to examine and review the progress throughout the life of a project.

The goal; to ensure a healthy project and client relationship for the duration of development and beyond.

First, a Quick Glance at some Terms

agile programming

Now, we all know that stakeholders don’t really want to ruin our lives as Project Managers. A full understanding of the process goes a long way in maintaining a healthy client relationship and ensuring everyone is on board with set expectations.

Scrum: Keep it Short and Don’t be Late!

scrum agile

Repeat after me, “Our team will scrum at exactly 8:42 every morning and end at exactly 8:57.”

The scrum is not just a meeting where the team members don’t sit down, but they do stand up for the entirety of the huddle. The scrum is an important, if not vital process of agile. The goal of using this light framework is to maximize the project team’s efforts and make the most out of the time available to create a pure and productive environment.

Standing helps the team maintain focus, and supports the notion that the scrum is to be kept short and sweet. It’s meant to be fifteen minutes maximum (Source), more than enough time for short statements that achieve the goal of keeping everyone held accountable and moving forward. One way to keep the focus on the team member who is speaking is to throw a ball around. When the scrum ball gets tossed to you, it’s your turn.

There are three questions that are asked in every scrum:

  • What did you do yesterday?
  • What will you do today?
  • What impediments are holding you back from accomplishing your goals?

That is it. No small talk or discussing the weekend or lunch agenda. No long winded answers. Get to the point of your daily plan and then move on to the next question or toss the ball to the next team member. An impediment can be professional, personal or non-existant.

There are a few rules of the daily huddle or scrum that should be followed without exception:

  • Scrum always starts on time, so don’t wait on late team members. If they are habitually late, eventually they’ll get the idea.
  • Don’t overshare or ramble about tasks or issues. If a larger issue is uncovered, sidebar it and follow-up with another meeting to specifically address that issue.
  • Don’t interrupt team members, whoever has the ball has the floor. Period.
  • Don’t introduce new ideas during scrum. New ideas should be introduced in meetings.
  • Scrum is NOT a meeting, don’t treat it as one.

Sprint Ahead, 2 Weeks at a Time

A sprint is a set period of time during which specific tasks are to be completed and made ready for review by the end of the sprint. Sprints can be identified as 1 week, 2 week or even 3 weeks. Ideally, for most projects, a sprint is 2 weeks.

During a sprint, the development team builds and tests a part of the product until the team and client accept it as being tested, functional and accepted as a shippable product and a completed part of the MVP. When one sprint ends, the next sprint begins. The teams will deliver iterations at the end of each sprint until the product is tested and completed.


Avoiding Technical Debt with Agile

technical debt agile refactoring

When changes are made during agile development, refactoring should happen in tandem to keep technical debt down to a bare minimum.

Technical debt is simply extra development work that arises when code that is easy to implement quickly is used vs. applying the best overall solution during each iteration. It’s always better to take the time to clean up “code cruft” during programming iterations instead of waiting until the end of the project after many changes and iterations have occurred. Long term, taking the time up front to program a product with the cleanest and most effective solution is far less expensive than paying back the technical debt at the end of any project regardless of its size or scope.

Because Agile is developed in iterations, it’s far easier to avoid technical debt using this methodology than in Waterfall, where the product is presented to the client after most of the development work takes place.


Well Formed User Stories

A user story is description of features or a feature from an end-user perspective. The user story describes the type of user, what they want and why. It helps to create a simplified description of a requirement.

An example of a user story template:

As a ________, I want _______, so that ________

User stories help to refine the answers to these questions:

  • As a, (who is the user? who are we building this product for?)
  • I want, (what are we building and what is the goal?)
  • so that (what is the value we will bring to the user?)

This is a good guideline when beginning a user story. You will answer questions that will ultimately help define the product and what its purpose is.


Increase Engagement and Satisfaction

The ultimate goal is more attainable through agile development; increased customer satisfaction through shared understanding, faster feedback and clear management of expectations.Customer satisfaction can only be attained by creating the best ship ready product possible and maintaining a good relationship as we journey down the development path together. Some basic reasons why Agile is a better methodology for healthy projects:

  • Speed and agility
  • Clearer management of expectations
  • Transparency
  • Controls costs
  • Minimize risk of project failure
  • Flexibility to change (change becomes a positive part of project flow)
  • Faster feedback
  • High-quality final product
  • Identify problems early on
  • Team commitment and accountability
  • Focus

A Little Agile Trivia

Who invented scrum? Well, some believe that Jeff Sutherland, John Scumniotales, and Jeff McKenna invented Scrum back in 1993 and others who think Hirotaka Takeuchi and Ikujiro Nonaka as invented Scrum in 1986.

dr jeff sutherland agile scrum

To confuse things more, when Jeff Sutherland created his version of the scrum process in 1993, he borrowed the term “scrum” from an analogy presented in a 1986 study by Takeuchi and Nonaka, which was published in the Harvard Business Review. Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formation used by Rugby teams in that article, influencing Sutherland.

Want to Learn more about Agile?

There are many conferences across the country addressing Agile Methodologies, such as Keep Austin where Ron Quartel spoke at Agile 2017.
agile methodologies
Click here for a list of other Agile Conferences and Events happening in 2017.


If you are looking for a professional web design company don’t hesitate to call TheeDigital at 919-341-8901 or click here to schedule a consultation with one of our web experts today.

Sign Up for Newsletters

Be the first to receive the latest industry news and exclusive invitations to TheeDigital events.

  • This field is for validation purposes and should be left unchanged.