Earlier this week, we discussed the Waterfall methodology and today we’re going to go over another popular methodology in the industry called Agile. Agile is an extremely iterative approach to product development based on the Lean methodology that rapidly delivers a product in small batches.
Many new startups find Agile to be a preferred methodology because Agile relies on a high level of customer involvement and thus the product is much more likely to be in tune with what the market wants when the product finally ships.
Traditionally, large companies with complex products (think Microsoft and their operating system or Nasa and a space rocket) couldn’t launch their software in pieces or else the entire product wouldn’t work properly. These companies had to ship products in a predictive manner by carefully planning through all customer use cases / edge cases.
As development costs went down, smaller teams were able to ship faster and start to outpace industry incumbents with significantly smaller teams. Meanwhile, companies were spending years working and launching products only to realize that customers had already changed their minds about what they needed.
Teams began to focus on adapting to the market by shipping new releases to a product over time in smaller batches and figuring out what the market wanted before investing huge periods of time / resources into creating products that no one wanted.
- Agile can quickly produce a working prototype to immediately show customers for feedback
- Customers can provide input throughout the entire development project
- Since sprints last 1-4 weeks, projects can deliver new features quickly and frequently as well as with levels of predictability
- Unlike Waterfall, which is harder to change up once specifications have been drafted, Agile allows a team to always be optimizing or re-prioritizing a product backlog
- Since the project is broken down into manageable phases, teams can spend a lot of time on development and testing which greatly reduces the chances of unnoticed bugs near release date
- If the estimates for certain features are not accurate, a team will have to add sprints or push features to later sprints which will affect the overall deadline
- A lot of responsibility falls on the scrum owner who is constantly managing the product backlog to make sure sprints are finished in time
- Larger teams may find it harder to employ the more rapid Agile methodology
Popular Agile Methodologies:
Scrum is a popular methodology used by many startups that can be broken down into 4 major components:
Sprint Planning: The product manager will generally maintain a product backlog, which is a prioritized list of items for your team to work on. Near the end of the current sprint, a PM would start working with their team to plan for the following sprint. The PM would pull out sprint candidates (items that the team should consider working on for the next sprint) from the product backlog and spend some time working with appropriate team members to cost how long each candidate might take to implement. This way, during the sprint planning meeting, the team can focus on discussing priorities of each item and how many candidates the team realistically thinks they can complete in the following sprint. Once these sprint candidates have been discussed and finalized, they are moved into the sprint backlog to be allocated to individual team members to work on.
Sprint: Each company may have varying sprint time periods although a common sprint cycle is 2 weeks (where a product release / new update gets shipped live to users at the end of the sprint cycle). In the actual sprint, team members will be assigned sprint candidates to work on and whatever doesn’t get completed in time for release will be considered “slipped” and get re-prioritized for a future sprint or perhaps de-prioritized.
Stand-up Meetings: Stand-up meetings usually happen daily (again, this varies by team) and are a way for the team to check-in with each other. The scrum owner, or the PM, will ask everyone what they did yesterday, what they are doing today, and what roadblocks there are. This lets everyone stay abreast of what’s going on with everyone’s work, hold people accountable for getting work done, and offer help to anyone who is stuck.
Retrospectives: A retrospective is generally a meeting that happens at the end of your sprint cycle where you review what happened during the latest sprint. Your team might discuss agenda items like: what went well, what didn’t go well, what could be improved, and any questions / concerns about the entire process. The PM might be the one taking lead on asking these questions, gathering feedback, and figuring out how to improve the sprint process.
Kanban is also a popular methodology used by many startups that is less stringent than Scrum and is oftentimes used by teams who want to just continuously crank out work without focusing on estimations / deadlines.
Unlike Scrum, Kanban doesn’t run off sprints so there isn’t a need to maintain a sprint backlog. Instead, there is only a product backlog where team members continuously pull tickets out of the backlog to work on.
With Kanban, there is generally a board with 3 columns, To Do, In Progress, and Done. The To Do column would be the prioritized product backlog where team members can pull items off the top of the list to work on. Upon finishing a ticket, the team member would then just pull the next ticket to work on from the top of the list. There might also be certain constraints applied by the team, such as only have a certain amount of items in each column at a given time.
Kanban allows teams to work quickly without the need of heavy process since there aren’t any meetings like sprint planning or stand-up meetings. The lack of this process also means that it’s much harder for teams running on Kanban to estimate when work might get done since your team isn’t timeboxing itself like Scrum teams do.
Join 17,000+ Product People and Get a Free Copy of The PM Handbook and our Weekly Product Reads Newsletter
Subscribe to get:
- A free copy of the PM Handbook (60-page handbook featuring in-depth interviews with product managers at Google, Facebook, Twitter, and more)
- Weekly Product Reads (curated newsletter of weekly top product reads)