Agile versus Waterfall Project Management (and what it means for you!)

The Basics of Agile for Junior Developers

In Module 5 of the curriculum at the Flatiron School, you’re tasked with independently coming up with a project idea, planning it, and then executing it — in other words, you get to be a product owner, a project manager, and a software developer all at the same time! Even as a former project manager, this was an intimidating task for me — being one is a full time job!

So what are those three roles, and why the heck am I talking about them in a blog on Agile for new software developers?

Product owners, at a high level, are the voice of the customer when it comes to developing an offering, be it an app, a website, or a service. Your product owner will look at things from the perspective of the user (and the customer, who can be two different people!), offering feedback to the project manager on what can be improved, helping to prioritize work and define an MVP, and interacting with the development team on a regular basis to generally help the team understand what would really make a user or customer say “Wow!”. The product owner is also responsible for ensuring that a set of user stories for the product exists — they’ll leverage the expertise of team members to help write personas, and then put into words what those personas will hope to achieve using your product.

Project managers are a more familiar species — project managers, having worked with the product owner to determine what functionalities are high priority, low priority, or nice-to-haves, will work with the development team to build out a backlog of Goals, Epics, PBIs (Product Backlog Items), and Tasks. These are just terms we use to help characterize and understand the size and nature of the work that we’re being asked to do as developers. The terms can change from team to team, but in general:

• A Goal is the overarching aim of the team (to build a world class social networking site, or dating app, or network management tool, etc.). Goals are usually the responsibility of an entire team, or several teams.
• An Epic is a cohesive, complete body of work (e.g., to enable messaging, to build our MVP, etc.). Epics are usually owned by one team, or sometimes two. Generally, project leadership only wants to hear about progress at the Epic level. Epics usually take more than one sprint to complete.
• A PBI, Product (or Project) Backlog Item, is a chunk of an Epic, and usually embodies one of the larger pieces of work required to execute on an Epic. Usually a PBI will be owned by a few members of a team. A PBI can generally be achieved in a single sprint.
• A Task is a subdivision of a PBI, or a single piece of work that needs to be completed before the PBI can be marked complete. A Task will usually be the responsibility of an individual. Each Task can be assigned a number of points, which are then aggregated all the way up through the hierarchy (a PBI’s level of effort is the sum of its Tasks’ points, an Epic’s level of effort is the sum of its PBIs’ points, etc.)

There’s a bit more Agile terminology flying around here! Let’s break it down a little more:

• In Agile, a sprint is a time period, generally no more than two weeks, where the team will commit to a certain amount of work getting done, and work exclusively on those items. This helps the team focus and deliver on items that the product manager has identified as high priority, and makes it easier to change gears between sprints than it would be on a day-to-day basis.
• Points are how Agile project managers understand how long the team thinks an effort will take — to avoid making unrealistic commitments, points do not reflect the number of hours an effort will take. On teams that I’ve worked on in the past, the generally agreed upon spec was that, for one person:
• A 1 point item can be completed in the time it takes to drink a cup of coffee
• A 2 point item can be completed in a half day
• A 3 point item can be completed in a day
• A 5 point item can be completed in 2–3 days
• An 8 point item can be completed in a week
• These values will vary by team, though! Make sure you understand what kind of effort you’re committing to during your planning sessions.

In short, it all boils down to this: at the start of a project, the product owner will work with the development team, through the project manager, to build user stories that meet the business requirements. The project manager will then work with the dev team to build a backlog of work. They’ll then sit down for a planning meeting, where the team will attempt to roughly estimate the level of effort each piece will take, often using points to represent. (Planning poker is a great exercise for this!)

During a sprint, as a junior developer, you’ll take on a certain number of points of effort — at the very start, you’ll probably be asked to take on a lower number of points than many of the other devs, so that you’re sure you can hit the target that sprint and not hold the team up. You’ll notice, though, that each member of the team will take on different numbers of points, and that the numbers will change a little from week to week — if someone is taking time off, or they’re working in a space that’s unfamiliar, they might opt to take fewer points.

This gives the project manager a snapshot of what the team is capable of, and is one way that a team can be appreciated for achieving a body of work — the project manager will have a rough number of points that the team can accomplish in a sprint, and will use that as a guide to understanding how much work the team should take on each sprint. Extrapolating this will give the entire organization an understanding of how long the work will take to complete, which is amazing! If we know that our backlog is 800 points, and the team’s burndown rate is 50 points per week, then we can guess (roughly) that the project will take 16 sprints, or 32 weeks. If that’s not acceptable to the business, then they know they need to hire more developers to hit the deadline.

A burndown is the rate at which a team will finish points of work, and the project manager can use this rate to make sure that the team is on track throughout the sprint.

But what makes this Agile?

One of the biggest advantages Agile offers over Waterfall methodologies is that, because the work in Agile is built in ‘bundles’ rather than dependencies, it’s much easier to change gears and adjust when priorities change. It also allows the team to quickly release an MVP, and then add features or make changes based on user feedback, as opposed to waterfall, which defines an end product and then builds a roadmap to get there — in waterfall methodologies, the first usable example of the product might not come until the last 10% of its development time! This meant that many critical decisions had already been made by the time users had a change to offer any feedback.

As a junior developer in an Agile environment, you’ll be asked to understand what your capabilities are, calibrate what points you can take on, and help the team estimate how long pieces of work will take. In return, you’ll get to focus on one major piece of work at a time, have the freedom to be flexible, and not be given more work than you can handle!