In the Agile world, there’s a strong emphasis on flexibility, collaboration, and the ability to adapt to change. However, some projects may be better suited for Waterfall’s structured approach. For example, if a project needs to comply with strict regulations or standards, Waterfall’s rigid approach with documented deliverables can ensure adherence. 

The Agile philosophy has been incorporated into several software development frameworks, including Kanban, Scrum, Extreme Programming, and Lean. 

• Kanban: With the Kanban framework, teams visualize the software development process with a Kanban board. This board includes “To Do,” “In Progress,” and “Done” columns to help teams visualize the entire development cycle as it unfolds. 

• Scrum: Scrum is one of the most popular Agile frameworks. It centers around short work iterations called sprints that ideally take place over the course of two weeks. The Scrum process involves regular meetings during development, including the sprint planning meeting, daily stand-ups, sprint reviews, and sprint retrospectives. 

• Extreme Programming (XP): The XP framework focuses on delivering quality software, collaborating as a team, and improving the well-being of the software development team. XP involves test-driven deployment, pair programming, and a 40-hour workweek to help prevent developer burnout.  

• Lean: Lean software development is an approach that aims to eliminate waste and maximize value to the customer. This framework also values quality building through pair programming, incremental development, minimizing wait states, and looking for automation opportunities to limit human error. 
• SAFe: The Scaled Agile Framework (aka SAFe) is a set of organizational and workflow patterns designed to implement the Agile philosophy at the enterprise level.

• Crystal: The Crystal Agile framework focuses on people, collaboration, and adaptability over strict processes. There is less focus on formalities, empowering teams to find their own solutions and workflows. Each variation of Crystal caters to different team sizes and project complexities. 

Iterative development in Agile is a process in which sprints and releases are repeated until the final product is achieved. Customer feedback is implemented with each iteration so that the product is continuously improved. 

Incremental development in Agile is an approach in which work is sliced up into smaller pieces, or increments. Each increment is built upon previous versions so that improvements are made bit by bit.

The Agile methodology is well-suited for software development, product design, marketing, and recruiting, to name a few. 

Daily stand-ups allow teams to improve communication, identify roadblocks, share knowledge, and make decisions regarding the tasks at hand. Daily stand-ups also eliminate the need for other time-consuming meetings so developers can stay focused on their work. 

Sprint planning meetings kick off at the beginning of each new sprint. The team gets together to discuss the work they need to complete in the upcoming sprint and how they’ll accomplish their sprint goal. At the end of the meeting, teams should have finalized the sprint goal and the sprint backlog. 

A sprint review meeting takes place at the end of a sprint and acts as a show and tell to demonstrate the product's key features and gather feedback. It’s a chance to discuss what the team accomplished and any changes they need to make. 

A sprint retrospective meeting also occurs after the sprint review meeting but before the start of the next sprint. It’s an opportunity for a team to reflect on what went well and what can be improved in the upcoming sprint. 

Popular Agile tools include: 

• GitHub 

• Jira 

• VersionOne 

• Trello 

• Asana 

• Zoho

• Yodiz

A release candidate is an internal version of a product or software before it goes live. It’s as close as possible to the final release, but further testing may need to be conducted to ensure it meets quality standards and is ready for customers. It’s like the final draft before the big release.   

The following questions will help gauge a candidate’s intermediate knowledge of the Agile methodology. 

Some of the key metrics associated with the Agile methodology include: 

• Velocity: The average amount of work a team completes during a sprint, measured in story points or hours

• Workload distribution: The amount of work assigned to each team member during a sprint 

• Failed deployments: The number of deployments that have failed in a given timeframe 

• Escaped defects: The number of issues found in a release or deployment after production

• Deployment frequency: A measure of how often code is deployed

• Lead time: A measure of how much time passes between task creation and when the work is completed
• Cycle time: A measure of the elapsed time from when work starts on an item until it's ready for delivery

Burn-up charts are used to measure progress and scope creep during a sprint. The y-axis represents the amount of work and is measured in tasks, hours, or story points. The x-axis represents time, typically measured in days. 

The chart shows when work was added or removed during the sprint and allows teams to better forecast the project completion date.

Burn-down charts are used to show how much work remains during a sprint. The x-axis represents the amount of time left to complete the project and the y-axis represents effort. This chart depicts velocity, or the rate at which a team is moving toward the end goal, and can be used to help predict performance.

There are different types of burn-down charts, depending on the kind of project you’re working on. 

• Product burn-down chart: A product burn-down chart shows the story points of all completed sprints, showing the completion of requirements over time. 

• Sprint burn-down chart: A sprint burn-down chart represents the work that’s been completed during a sprint and the amount of work remaining. 

• Release burn-down chart: A release burn-down chart shows the progress of how many features or epics have been completed during the release.

• Defect burn-down chart: A defect burn-down chart tracks the total number of defects that are identified in a sprint and fixed or removed.

Kanban is an Agile framework that helps teams visualize work during the software development lifecycle. Work is represented on Kanban boards, where each column represents a step in your workflow. Underneath these columns, teams add a Kanban card that represents a specific work item. 

Scrum of Scrums, sometimes called SoS, is a scaled Agile technique that helps multiple teams work together to deliver complex products. The technique splits up a large group (more than a dozen members) into smaller units of five to 10 members. 

Each of these smaller teams designates an ambassador that participates in daily Scrum meetings with other ambassadors. Meetings with these ambassadors are called the Scrum of Scrums, and they aim to improve collaboration between teams. 
 

The artifacts of the Scrum process include: 

• Product backlog: Product backlogs are prioritized lists of everything needed for the final product, including features, bug fixes, and non-functional requirements. 

• Sprint backlog: The sprint backlog is a subset of items picked from the product backlog that the team agrees to deliver during the upcoming sprint. These backlog items are selected during sprint planning meetings. 

  Product increment: The product increment is the sum of all of the product backlog items completed during a sprint, as well as the work completed from previous sprints.

Common challenges teams encounter when incorporating the Agile philosophy include: 

• Resistance to change: Many organizations are comfortable with what they’ve always done and can be resistant to adopting a new work approach. Agile adoption requires buy-in from the entire team, which can take time and a shift in culture. 

• New tool requirements: Some teams may need to adopt new technologies, like AI-assisted software development tools, to better track work during the Agile process. This may require getting rid of past tools in favor of new ones, which can introduce the same challenges of cultural adoption as the actual Agile process itself. 
• Investing in the proper training: Ensuring your team understands what Agile is and why you’re adopting it can be an overlooked step. However, it’s crucial your team has a full understanding of Agile in order for it to be properly implemented.

While the length of the Scrum cycle will be determined depending on your team size and the scope of the project, a typical timeframe is between two and four weeks. 

A spike, a concept adopted from Extreme Programming, is a user story that requires more information in order to estimate how long the story will take to finish. Spikes are also referred to as time-boxed investigations because they’re allotted a certain amount of time in each sprint. 

Refactoring is the process of improving the structure of existing code without changing its functionality. 

• Epic: An epic is a large chunk of work that’s separated into smaller tasks called user stories.

• User stories: A user story is a brief, simple explanation of a feature or functionality written from a user's point of view.
• Tasks: A task is a single unit of work broken down from a user story.

Test-driven development (TDD) is a software development approach in which tests are written before the actual code is created. The main goal of TDD is to modify and write new code only when tests fail to help prevent duplicate code. 

A product backlog is a prioritized list of tasks to be done in the future. The list is derived from the product roadmap with the goal of organization and prioritizing upcoming work. 

A sprint backlog is a list of tasks to be completed during a sprint. The worklist is derived from the product backlog with the goal of estimating the workload of the upcoming sprint. 
 

QA adds value to Agile teams by helping solve problems and catch errors early. Through the Agile QA process, developers are able to receive quick feedback so they can fix bugs and errors while the code is still in development. 

A product roadmap outlines the overall vision and direction of a product, highlighting key themes, timelines, and features you plan to deploy. It serves as a guide for decision-making, helping the team align on the product’s long-term goals, priorities, and anticipated timelines. 

The following questions are meant for more senior developers who are well versed in the Agile methodology.

Scrum has three main roles: product owner, Scrum Master, and the development team members.

• Product owner: The product owner is tasked with managing the Scrum backlog, knowing when things should and can be released, and managing stakeholder expectations. 

• Scrum Master: The Scrum Master works as a coach and guide for the development team, ensuring they understand the Scrum framework and its principles, values, and practices.

• Development team members: The development team is a group of individuals who do the hands-on work of completing the tasks in a sprint.

Agile software development prioritizes flexibility, customer collaboration, and working software created during short sprints by self-organizing teams. 

On the other hand, traditional software development methodologies focus on planning and predictability, using longer development phases, organized groups, and comprehensive documentation. 
 

The main difference between Agile and Scrum is that Agile is a software development philosophy built upon a core set of values and principles, whereas Scrum is an Agile methodology teams can use to implement the Agile philosophy into their software development lifecycle. 

The Scaled Agile Framework (aka SAFe®) is a framework for scaling Agile at an enterprise level. SAFe is based on 10 guiding principles, processes, and best practices to help larger teams become more agile. 

The Definition of Done (DoD) is an agreement that guides all developmental activities and states what is required for a piece of work to be considered “done.” The Definition of Ready (DoR) describes the requirements that must be met in order for a story to move from the backlog to development. 

Planning poker is a planning and estimation technique that helps teams estimate product development timeframes and create a plan for the work to be done. 

Here’s the typical process of how planning poker plays out:

• The product manager describes the user story to the group of estimators. 

• The estimators are then given Agile poker cards with a number sequence that represents each person’s estimation of the story points. 

• The estimators reveal their cards at the same time. 

• If a consensus is reached, the team can move on to the next story point.

• If the teams do not have a consensus, the estimators discuss their estimates until an agreement is reached.

User stories are estimated in story points rather than working hours because they’re meant to be a relative estimate. For example, a team may believe a user story estimated at six story points will be about three times as much work as a user story estimated at two points. 

Using user stories rather than working hours is also a quicker and easier process—estimating work in working hours can be a time-consuming, often overly detailed approach.