How Does Scrum Fit Into Agile? An Intro To The Scrum Framework

A lot of confusion comes from understanding the relationship between agile, scrum, and other agile-related frameworks. What most people know is that both have a fast-paced, iterative approach to their day-to-day operations with a focus on process improvement, although the specifics of each tend to get a bit blurry. In this article, I’ll aim to make that relationship a little clearer by providing a detailed side-by-side comparison of the two, and discussing the practical intricacies of both methodologies.

Defining Agile And Scrum

Before we dive into the comparison, we first need to get familiar with the meaning of these terms as well as their underlying philosophy. As we’ll soon get to see, Scrum is a small methodological subset, or framework, of the project management philosophy known as Agile, a theory that prioritizes flexibility and iteration over everything else.

What Is Agile?

As we have already said, Agile is a project management methodology that has a defined set of philosophical principles that encompass all of its frameworks such as Scrum and Kanban, and which guide their practice in a very specific direction.

Four values of Agile as defined in its manifesto are:

1. People First - Agile puts a focus on the people that make up the company rather than the processes or tools that are used. Where other, more traditional, management approaches look at a company structure as composed of defined mandatory procedures, Agile methodology sees people that stand at the root of it all and whose knowledge is what keeps the company going. This value is also very clearly visible in Agile’s utilization of cross-functional teams.
2. Creating Stakeholder Transparency - Instead of making extensive and technical development documentation for its software, Agile tends to use user stories, and short written explanations of a particular user need and how it can be fulfilled. User stories shouldn’t contain any technical jargon or be more complex than necessary as anyone should be able to understand them. Ultimately, they have numerous benefits such as a simplified format that allows transparency for people without technical knowledge such as stakeholders, while also increasing flexibility and improving collaboration.
3. Customer Collaboration - One of the key points in Agile philosophy is the focus on flexible goals that change along with the client’s needs. For that to be possible, the customers need to be constantly aware of new developments in the process and provide their feedback every step of the way, allowing the developers to initially build the software exactly as envisioned by the client, instead of having to update or change a large portion of it once the initial building phase is completed. This is the reason why Agile projects don’t focus on creating rigid and comprehensive contracts, as the scope of work can change at any time based on new insights.
4. Adaptability - Agile teams need to always be prepared to adapt to anything that comes their way by pivoting and shifting the focus based on new conditions. Instead of creating rigid plans that need to be followed step by step, Agile methodology embraces and encourages you to change your critical path when it’s the most optimal thing to do.

As we learn more about Agile, we start to understand that it’s much more of a conceptual framework with some values and principles that very broadly guide the actions of its practitioners, rather than a practical and strictly defined framework that can be followed step-by-step and implemented universally. What it tries to do is much more important than that, as it instills the ideas of organizational flexibility and adaptability in our thinking, leading us to approach even the most classical of management tactics in a completely new way.

What Is Scrum?

Even though it holds the same values as Agile, Scrum is a very practical and systematic framework that isn’t as conceptual but rather contains more specific procedures.

At the most basic level, the work cycle of Scrum can be defined by the following steps:

1. Product Owner determines the developments needed to achieve the Product Goal and orders the work in the Product Backlog
2. The team takes a subset of the Product Backlog and develops it during a Sprint
3. The team and stakeholders examine the results of the Sprint and evaluate if any process improvements need to take place
4. The process is repeated

Of course, this work cycle can be changed and modified in many ways but the core steps listed above need to be respected for the framework to be considered a Scrum. The practical nature of Scrum makes it fairly logical to implement in a wide range of work environments but one should be careful to learn the fundamentals behind Agile philosophy beforehand so that they are aware of the ideas and theories that reside in the background of Scrum. Understanding these core ideas will allow you to understand Scrum much better and help you to implement it in your projects with ease.

Agile vs. Scrum - Conceptual Differences

We have already mentioned the four values that lie at the core of Agile. It’s important to note that Scrum also has what it calls its three pillars, values that are crucial for it to function properly. Those pillars are:

1. Transparency - The entire work process must be visible to all members of the team as well as the stakeholders to enable inspection from all sides.
2. Inspection - Scrum framework encourages constant inspection of tasks and the progress towards the Product Goals. The presence of inspection leads to reduced risk and allows for quick adaptations in instances where a pivot is needed.
3. Adaptation - The final link in this chain, adaptation is the key step that keeps the team practices in check with the Product Goal in any instances of deviation. The adjustments need to be made as soon as possible to minimize deviation so it’s incredibly important that the team members are self-managing to an extent.

As we can see, the pillars of Scrum go perfectly in line with the values of Agile, mostly because they were initially based on them. The only Agile value that we can’t see here is the “People First” value that relates to the company structure being organized around people and not the processes. This part was left out partly because that philosophy is already woven into the Scrum team structure, which we’ll talk about at a later point in this article.

At least when it comes to their theoretical conceptualizations, we can see that Scrum is loyal to it’s root philosophy based in Agile.

Agile And Scrum Software Development Cycle

We’ve already briefly covered the core of the Scrum development cycle and we’ve seen how crucial for it is the concept of constant iteration and improvement of processes. As we’ll soon see, the cycle for Agile is slightly less practical and slightly more conceptual but at its core, it aims to achieve the same goal as the Scrum development cycle.

The steps in the Agile development cycle are:

1. Concept - In this stage, the Product Owner will work with the clients to create the first sketch of the project and determine its scope and requirements. The concept phase also requires budgeting considerations and the assessment of feasibility.
2. Initiation - Once the initial concept is defined, the developers start work on the basic product that contains all the necessary functionalities and design features that were defined in the concept. The product shouldn’t be polished and detailed as it will almost certainly be updated in the future.
3. Iteration - The Product Owner and the clients review the product and suggest any updates that could be made. The developers subsequently apply those changes and the iteration process repeats itself until the clients are satisfied with the final product.
4. Launch - During this phase, the product is tested by the quality assurance team to determine if there are any deficiencies or errors. This is also the phase where user training is conducted.
5. Upkeep - The released product will still need to be kept up to date and any bugs that are found will need to be resolved. The development team will continue to provide ongoing support until the product is withdrawn.
6. Termination - In case of termination, the team will notify the users of the upcoming retirement and, if there are any alternatives, they’ll migrate the remaining users to that platform. The developers will then conduct the end-of-life activities before shutting down the app.

As we can see, there are some incredible similarities between the development cycles of these two methodologies. What we can also notice is that the Scrum development cycle looks like a zoomed-in image of the first four steps of the Agile cycle. This is because Scrum is a framework used for the iteration of new developments and as such doesn’t take into account the later stages of product upkeep and termination.

Agile Team Structure vs Scrum Team Structure

Agile allows for a couple of different types of team structure which all apply to Scrum as well. The type of structure will depend on numerous factors such as the goals of the project, costs, and worker expertise, making it harder to predict which structure will work for which project.

The types of team structure applicable for both Agile are:

1. Specialist - In this team structure, the team members have a very specific set of skills and are experts in their field. Every worker in this structure is responsible for their niche and the tasks that fall under their area. Examples of this structure are programmers or data scientists.
2. Generalist - The opposite of the specialist team structure, the generalist team aims to have workers that are knowledgeable in a large number of different fields, without being too deep in a particular one. These structures are versatile and allow the team to shift quickly from task to task. This is mostly beneficial for areas such as sales where transitioning from selling one product to another is not a complex procedure.
3. Hybrid - This is the most widely utilized team structure that allows for both flexibility and specialization. The hybrid system works by employing a subset of workers that are generalists and a subset that are specialists. The specialists usually create the product and the generalists work to connect different areas that are worked on by the specialists.
4. Parallel - A team structure where the team changes tasks for every new iteration. For example, a team can do development for a single sprint, and for the next sprint, they alternate and work on QA testing. The advantage of this structure is that the team members are familiar with all aspects of the process but it can also be hard on the workers as they need to adapt to constant changes.

These four team structures are applicable to the develipment team within Scrum, however, aside from the developers, the Scrum team also needs to contain Managers, Product Owners, and a Scrum Master.

Key Team Member Roles In Agile And Scrum

In addition to team structure, another important aspect of Agile methodology, as well as Scrum, are the predefined roles that make up a team. The roles, similar to everything else in Agile, are extremely flexible with their responsibilities and processes, but the core functionality of the role is almost always present in practice. These broader roles transition into much more specific positions when it comes to Scrum and they can’t be modified to as large of an extent.

Here are some of the key roles in Agile and Scrum team structure:

• Team Lead - The team lead holds a managerial position and is responsible for team coordination. They delegate tasks, set up workflows, and hold meetings to achieve maximum team efficiency. In Scrum, the team lead is called the Scrum Master and they are responsible for managing Sprints.
• Product Owner - Product Owners mediate between the client and the team and their main job is to ensure that the client’s demands are being met. The Product Owner in Scrum works with the team to create the Product Backlog which will be slowly incremented in specific sprints.
• Team Member - A broad term that can relate to workers in a lot of different fields. They are the backbone of an Agile team and run the everyday operations needed to meet the client’s demands. In Scrum, team members are usually developers.
• Stakeholder - Stakeholders are people such as end-users, investors, or executives. They are not directly involved in the process but have a say in the process and the results of the project.

Which Agile Framework Should I Choose?

With so many different Agile frameworks existing out there, we will focus on a couple of main ones and explain the situations in which they work best. The most popular Agile ones are:

1. Kanban - The best framework for continuous workflows like support or services. Kanban allows for tasks of different sizes and importance to be simultaneously guided through the workflow, leaving a lot of room for flexible prioritization.
2. Scrum - It functions best in situations where a collaborative team works on a long-term project where the requirements for the results can constantly change and the process can be constantly improved. An example would be projects that aim to create software, web pages, or an end product.
3. Extreme Programming - Best to use when you’re running a system that’s expected to change often, leaving room for constant feedback and a lot of flexibility.
4. Dynamic Systems Development Method (DSDM) - An approach similar to Scrum in its methods but more suited for a project context where you have tighter scope control needs.

Choosing which Agile framework to use ultimately depends on your specific business and you shouldn’t be afraid to try some of them out. The best way to find a management methodology that works for you is to test it out yourself!