Agile Project Management

The history of Agile

Agile as a project management approach was introduced to the world in 2001 in the United States. At a ski resort in the Wasatch mountains of Utah, 17 self-proclaimed organizational anarchists came together and combined several lightweight processes to create what we know today as the Agile Manifesto. The creators of Agile intended it to be a set of values and principles that would improve upon and transform existing software development processes, but companies in various industries quickly saw the value of Agile, too. Soon, Agile was adopted across all fields. 

Agile values and principles

In the last video, you explored the Agile Manifesto—the guiding force behind all Agile teams—in-depth. You learned that Agile is a highly collaborative approach suited for very complex and competitive projects. In this reading, we’ll briefly explore the four values and 12 principles of the Agile Manifesto. 

The Agile values refer to the following four statements: 

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Agile experts see these values as important underpinnings of the highest performing teams, and every team member should strive to live by these values to apply the full benefits of Agile.

The same is true for the 12 principles, which are at the core of every Agile project:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” 

• Whether you are working to create a product for your company or for a customer, chances are that someone is awaiting its delivery. If that delivery is delayed, the result is that the customer, user, or organization is left waiting for that added value to their lives and workflows. Agile emphasizes that delivering value to users early and often creates a steady value stream, increasing you and your customer’s success. This will build trust and confidence through continuous feedback as well as early business value realization.

“Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” 

• When working in Agile, it’s important to be agile. That means being able to move swiftly, shifting direction whenever necessary. That also means that you and your team are constantly scanning your environment to make sure necessary changes are factored into the plans. Acknowledging and embracing that your plans may change (once, twice, or several times) ensures that you and your customers are maximizing your success.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” 

• Delivering your product in small, frequent increments is important because it allows time and regular opportunities for stakeholders—including customers—to give feedback on its progress. This ensures that the team never spends too much time going down the wrong path.

“Business people and developers must work together daily throughout the project.” 

• Removing barriers between developers and people focused on the business side of the project, builds trust and understanding and ensures that the developers, or those building the solution, are in tune with the needs of the users. 

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” 

• A successful Agile team includes team members that not only trust each other to get the work done but are also trusted by their sponsors and executives to get the work done. Teams build better solutions when they are empowered and motivated to deliver difficult projects.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

• There isn’t anything quite like face-to-face communication. Face-to-face communication allows us to catch certain cues, body language, and facial expressions that are sometimes lost when using forms of communication like email, chat, or the phone. However, we can’t always be face-to-face. Establishing effective communication norms—no matter the format—is essential to effective teams. 

“Working software is the primary measure of progress.” 

• In Agile teams, the main way to demonstrate meaningful completion of work is to show a working piece of the solution. In software teams, that might mean a functional piece of software. In non-software teams, that might mean a critical portion of the solution that is ready to be demonstrated to users or their representatives in order to collect feedback. This is in contrast to traditional or Waterfall projects, where the completion of project documents could be used to measure progress. In Agile project management, it is not enough to say that the team is 80% done with an activity if there is no working, demonstrable artifact available to review.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” 

• Maintaining a steady but careful pace will prevent errors along the way. Also, you never want your team to feel overworked or overwhelmed. On the flip side, a team that is underutilized may become bored and lose the creative spark to innovate. The Agile ideal is to achieve a steady pace of effort for the team that avoids overtime and burnout.

“Continuous attention to technical excellence and good design enhances agility.” 

• This principle conveys that just because the team is working fast doesn’t mean they sacrifice quality. By emphasizing quality and design throughout the project development phase, the agility, efficiency, and speed of the team will be increased. When a team delivers a well-built solution, they can quickly respond to user feedback and new information. However, if the product is low quality, implementing changes can become problematic, complex, and slow down the entire team. 

“Simplicity—the art of maximizing the amount of work not done—is essential.” 

• The team should avoid implementing extra features into the solution that weren’t explicitly requested by the user or product owner. This includes removing procedures that are no longer necessary, and reducing unnecessary documentation. 

“The best architectures, requirements, and designs emerge from self-organizing teams.” 

• Team members should be able to get their work done by designing their own work processes and practices, without a manager dictating how they operate. Team members should also feel empowered to speak up with questions, concerns, or feedback.

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” 

• In Agile, it is important to acknowledge that learning from successes and failures is continuous. No team is perfect. There will be mistakes, challenges, trials, and triumphs. Teams should reflect on all of these different aspects of their activities so that they can make necessary adjustments. 

For additional information, read more on the 12 principles here.

In this reading, you will learn to define the characteristics of Scrum as we review what makes Scrum different from other frameworks.

Although Scrum was first used to describe Agile content in 1986 in the Harvard Business Review, the term originates from the internationally loved sport, rugby. In rugby, a “scrum” involves players huddling closely together with their heads down while trying to gain possession of the ball. Then, the players work together in order to achieve their shared goal: to get the ball across the line and score!

The original Harvard Business Review paper, written by Hirotaka Takeuchi and Ikujiro Nonaka and titled The New New Product Development Game, introduces Scrum in the chapter “Moving the Scrum downfield.” Throughout the paper, the authors continue to point out which characteristics of a team help to move the Scrum downfield. Those are: 

• Built-in instability: In the Scrum world, teams are given the freedom to achieve important outcomes with “challenging requirements.” Takeuchi and Nonaka explain that this gives teams “an element of tension” necessary to “carry out a project of strategic importance to the company.” 

• Self-organizing teams: Scrum Teams were intended to operate like their own start-up, with a unique order that lacks true hierarchy. These teams are considered self-organizing when they exhibit autonomy, continuous growth, and collaboration.  

• Overlapping development phases: Individuals on a Scrum Team must “work toward synchronizing their pace to meet deadlines.” At some point throughout the process, each individual’s pace starts to overlap with others, and eventually, a collective pace is formed within the team.

• Multi-learning: Scrum is a framework that relies heavily on trial and error. Scrum Team members also aim to stay up-to-date with changing market conditions and can then respond quickly to those conditions. 

• Subtle control: As we mentioned, Scrum Teams are self-organizing and operate like a start-up, but that doesn’t mean there is no structure at all. By creating checkpoints throughout the project to analyze team interactions and progress, Scrum Teams maintain control without hindering creativity. 

• Organizational transfer of learning: On Scrum Teams, everyone is encouraged to learn skills that may be new to them as they support other team members. 

The authors’ main point was that “each element, by itself, does not bring about speed and flexibility. But taken as a whole, the characteristics can produce a powerful new set of dynamics that will make a difference.” Though these concepts were first introduced in 1986, they still remain remarkably true for Scrum Teams today.

Because of their flexible approach, Spotify—a music streaming company with millions of listeners—is known in the Agile project management field for setting the standard pretty high. In this reading, you will learn about the Spotify model and the importance of being flexible when scaling an Agile team. 

Spotify has been able to do what so many other companies dream of doing, and they’ve done it as their team size scaled. How did they do it? Agile coaches Henrik Kniberg and Anders Ivarsson have instilled an overall approach of the constant blending of methods and adapting as time goes on. 

The Spotify model

The Spotify model encourages innovation, collaboration, and productivity while maintaining autonomy, quality, and necessary communication. It does so by using a unique organization system that features Squads, Tribes, Chapters, and Guilds.

At Spotify, teams are broken down into what they call Squads. A Squad is like a Scrum Team and is supposed to feel like its own start-up within the company. Squads are self-organizing and collocated. They work together to achieve a long-term mission. At Spotify, a Squad may be in charge of a task such as improving the app’s usability for Android, improving the Spotify radio experience, or providing payment solutions. Just like a Scrum Team, the Squad doesn't have a formal leader, but they do have a Product Owner. Product Owners collaborate with one another to maintain a roadmap to track Spotify’s progress as a whole. Each team also has access to an Agile coach to encourage continuous improvements. Tribes are collections of squads that work in a specific area and are meant to have less than 100 people. Chapters are small groups of people across a tribe that have similar skills and work in the same general

competency area. Guilds are the largest group, comprised of people across the organization who want to share

knowledge, tools, code, and practices.

Be inspired by the Spotify model, but don’t emulate it

Each team requires differences in their workflow and systems. It is never a good idea to try to copy and paste an exact model to your team just because it worked for another team. In fact, some people have tried copying Spotify’s model and found that it was not a suitable model for their team at all. 

Key takeaways 

• You must always be able to adapt based on your team’s preferences and goals. The Spotify team started in Squads, but as they scaled, they added new types of groups within the organization—without disrupting the existing Squads. They continued to do so until they found the perfect balance of collaboration and ownership. 

• Always examine the needs of your project and organization. What works for Spotify may not be an exact fit for your team. If you are on a team that needs scaling, be inspired by this model, but use the aspects that work best for your organization. 

• Don’t be afraid of trial and error. If you try something and it doesn’t feel quite right, you can easily adjust.

• You should never consider yourself done improving. There are always changes that can be made for the better. 

The Scrum Guide defines Scrum as “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” This reading will review the Scrum pillars and values and then provide links to the Scrum Guide and further reading about Scrum. 

Pillars and values 

To recap, every person on a Scrum team subscribes to the three pillars and the five values of Scrum. 

The three pillars of Scrum are: 

• Transparency 

• Inspection

Adaptation 

The five values of Scrum are: 

• Courage 

• Commitment 

• Focus

• Openness 

• Respect 

In order for a team to succeed, it is incredibly important that every team member follow these core pillars and values.

Scrum only has a few rules and practices that are easy to follow. It is also easy to understand. However, Scrum can be challenging to master because mastery depends on being able to embody, live, and promote the pillars and values of Scrum. 

Helpful links 

Take a deeper look at the framework in the Scrum Guide. For further reading about Scrum, check out Scrum.org. 

Each Scrum Team member plays a vital role in the project’s success. In order to help a project get to the finish line, you will need to understand what each of these roles entail. In this reading, you will learn how the responsibilities of the Scrum Master, Product Owner, and Development Team differ from one another.

The Scrum Master

One key responsibility of the Scrum Master is to help the team understand and follow Scrum theory. More specifically, according to the Scrum Guide, “The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the Organization. The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.” The Scrum Master makes sure that important meetings occur, like the Daily Scrum. In the same way that a coach would be aware of the game clock, the Scrum Master is tasked with making sure that the meeting is kept within the appropriate timebox. A timebox is a Scrum concept that refers to the estimated duration for an event.

The Scrum Master acts as a coach to the Scrum Team—they encourage the team to build the product in the time frame. They also support the team by creating a collaborative environment so the project’s goals are achieved. The Scrum Master’s duties include: 

• Coaching the team members in self-management and cross-functionality

• Helping the Scrum Team focus on creating high-value Increments that meet the Definition of Done (an agreed upon set of items that must be completed before a project or user story can be considered complete)

• Causing the removal of impediments to the Scrum Team’s progress

• Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox (a Scrum concept that refers to the estimated duration for an event)

Scrum Master vs. project manager 

The role of the Scrum Master is sometimes confused with the role of the project manager. While the two roles share related skills and qualities, they are very different roles.

A Scrum Master is responsible for helping the team understand Scrum theory and practice. They ensure Scrum events take place and help the team focus on delivering value by removing impediments. But unlike a traditional project manager, they do not take on the management of changes in scope or priorities. Additionally, Scrum Masters do not maintain traditional project artifacts like Gantt charts.  

The Product Owner

According to the Scrum Guide, “The Product Owner is responsible for maximizing the value of the product resulting from work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.” Product Owners maximize the value of the product by representing and expressing the voice of the customer throughout the project duration. A product isn’t useful to its customers if that product doesn’t fulfill their expectations and meet their needs. The Product Owner’s duties include:

• Developing and explicitly communicating the Product Goal

• Creating and clearly communicating Product Backlog items (The Product Backlog contains all of the features, requirements, and activities associated with deliverables to achieve the goal of the project.)

• Ensuring that the Product Backlog is transparent, visible, and understood

Product Owner vs. project manager

In traditional project management, scope management is the primary responsibility of the project manager. But in Scrum, the definition and management of product scope falls to the Product Owner. Conversely, the Product Owner isn’t responsible for team performance—they aren’t considered to be a manager. The project manager leads the project team to meet the project’s objectives and oversees tasks and progress.

There are also similarities between the Product Owner and project manager roles. For instance, both roles are tasked with stakeholder management. This means they both must practice and facilitate effective communication among team members and stakeholders.

Additionally, in many companies—including Google—the definition of product or solution scope is the responsibility of a separate role called a product manager. So, it is important when joining any new company to discover how that company approaches the area of product definition, requirements development, and user research to understand what they consider to be the domain of the project manager. 

The Development Team

The Development Team, also referred to as Developers, is made up of the people who do the work to build the product. According to the Scrum Guide, Developers are “the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.” Their responsibilities include: 

• Creating a plan for the Sprint, the Sprint Backlog (the set of Product Backlog items that are selected to be completed during the upcoming Sprint)

• Instilling quality by adhering to a Definition of Done

• Adapting their plan each day toward the Sprint Goal

• Holding each other accountable as professionals

• Executing sprints by designing, building, and testing Product Backlog items in increments

An important aspect of the Development Team that is worth highlighting is that they are cross-functional, meaning that you will have team members who are specialists in different disciplines. In a software team, that might mean having a web developer, a database developer, and a user experience specialist. In a marketing team, that might mean having writers, editors, search engine optimization specialists, and business analysts. 

The roles working together

The Scrum roles fit together, and each brings their unique qualities, skills, and responsibilities jointly to lead to successful Scrum projects. It is crucial for everyone on the team to understand their role and how they work together to deliver value to their users and customers. When the team has this shared understanding, they can better support each other during the practices of Scrum. 

Necessary traits for each role 

Overall, you will want people on your team who are interested in constant collaboration and improvement. More specifically, it is great to have team members who value feedback, bring energy and fun to the team, and can admit and learn from their mistakes. Let’s look at what traits each team member should exhibit:

The Product Owner should be able to confidently provide the team with general direction, requirements, and objectives for the project but will allow the team to determine how to accomplish these goals. Your team will want a Product Owner who promotes the product vision and prioritizes the product backlog to maximize the value for the customer. In order to deliver on this, the Product Owner should be organized and have strong communication skills.

The Scrum Master should have strong leadership skills that enable them to be efficient facilitators and negotiators who know how to resolve conflict. Your team will want a Scrum Master who aims to effectively coach the Development Team, facilitate events, and eliminate distractions that may impede the team’s progress. 

When it comes to the Development Team, you will want individuals who remain focused on completing deliverables and producing a superior final product. Since the team is self-organizing and cross-functional, you will want people who are eager to work together and not afraid to compromise for the greater good of the product. 

User stories are short, simple descriptions of a deliverable told from the perspective of the user. Creating user stories helps the team develop a solution that is always centered around the user’s needs and overall experience. 

You also learned that epics are a collection of user stories. Think of the concept of user stories in terms of books or films. A story is one single narrative, while an epic is a set of several related, independent stories. Each story tells a specific chronicle, while an epic gives a high-level view of the overall arc. 

User stories

The driving factor behind every Scrum project is putting the customer first. User stories are a key component of ensuring that customers are satisfied with the product. A team writes a user story from the perspective of the user. Not only do user stories provide insight into what goals the user wants to achieve, but they enable collaboration, inspire creative solutions, and create momentum by giving the team a small win when the stories are developed. 

When writing user stories, you will need to include the following elements: 

• User persona. What is your user like? What is their relation to the project? What goals do they have? 

• Definition of Done. This refers to an agreed upon set of items that must be completed before a user story can be considered complete. 

• Tasks. What are the key activities needed to complete the user story?

• Any feedback already provided. If you are adding features to an existing product and you have already received feedback from customers on a past iteration, make sure to consider this feedback.  

I.N.V.E.S.T. 

Recall from the video that your user stories should meet the I.N.V.E.S.T. criteria: 

• Independent: The story’s completion is not dependent on another story.

• Negotiable: There is room for discussion about this item.

• Valuable: Completing the user story has to deliver value. 

• Estimable: The Definition of Done must be clear so that the team can give each user story an estimate. 

• Small: Each user story needs to be able to fit within a planned Sprint.

• Testable: A test can be conducted to check that it meets the criteria.

Let’s imagine you are working on a project for a local library. The library hopes to launch a website so that customers can read reviews before they check out books from the branch. The typical template for a user story looks like this: As a <user role>, I want this <action> so that I can get this <value>. Therefore, an example user story for this situation might read: As an avid reader, I want to be able to read reviews before I check out a book from my local branch so that I know I am getting a book I am interested in.

Epics

An epic’s purpose is to help manage related user stories. In this post, Mike Cohn, the inventor of the term “epic” as it relates to Scrum, describes epic as a “very large user story”—one that could not be delivered within a single iteration and may need to be split into smaller stories. The team should discuss together and reach a shared view of how to write and capture their user stories and epics. Keep in mind, epics are just larger user stories that are there to help organize the project. 

Let’s imagine you are creating user stories and epics based on the previous example. User stories may include customers wanting to read reviews of books on the website or wanting to add books to their cart. These user stories could fall into the “website creation” epic. 

Another user story could be that customers want to walk into the library and easily find the non-fiction section. This would fall under the “organization of the physical space” epic.

So rather than those various user stories appearing in a list together, they are organized into sections, or epics.

Testing 1234

It’s important to note that while the Product Owner can write user stories and epics, a Developer can also write them as long as the Product Owner remains accountable for the Product Backlog item.

Key takeaway

Epics allow you to keep track of large, loosely-defined ideas, while user stories are a much smaller unit of work, inspired directly from the end user or customer. Both user stories and epics help teams ensure they are delivering value to the customer.

There are all kinds of techniques to use when estimating effort in an Agile way. Effective relative effort estimation leads to successful and predictable sprint outcomes, which leads to a successful project overall. Generally speaking, the main steps to Agile estimation are the same, even if the specific approach varies. Some examples of Agile estimation techniques are: 

• Planning Poker™

• Dot Voting

• The Bucket System

• Large/Uncertain/Small

• Ordering Method

• Affinity Mapping

Planning Poker™

This particular method is well-known and commonly used when Scrum teams have to make effort estimates for a small number of items (under 10). Planning Poker is consensus-based, meaning that everyone has to agree on the number chosen. In this technique, each individual has a deck of cards with numbers from the Fibonacci sequence on them. The Fibonacci sequence is where a number is the sum of the last two numbers (e.g., 0, 1, 1, 2, 3, 5, 8, 13, and so on). 

Sometimes, Planning Poker decks also include cards with coffee cups and question marks on them. The question mark card means that the person doesn’t understand what is being discussed or doesn’t have enough information to draw a conclusion. The coffee cup card means that the person needs a break.

The Planning Poker strategy is used in Sprint Planning meetings. As each Product Backlog item/user story is discussed, each team member lays a card face down on the table. Then, everyone turns their card over at the same time and the team discusses the estimates, particularly when they are far apart from one another. By first hiding the estimates, the group avoids any bias that is presented when numbers are said aloud. Sometimes, when hearing numbers aloud, people react to that estimate or the estimator themselves, and it changes what their initial thought may have been. In Planning Poker, teams can easily avoid that bias.

Dot Voting 

Dot Voting, like Planning Poker, is also good for sprints with a low number of Sprint Backlog items. In Dot Voting, each team member starts with small dot stickers, color-coded by the estimated effort required (e.g., S=green, M=blue, L=orange, XL=red). The items or user stories are written out on pieces of paper placed around a table or put up on the wall. Then, team members walk around the table and add their colored stickers to the items. 

The Bucket System

The Bucket System is helpful for backlogs with many items since it can be done very quickly. In fact, a couple hundred items can be estimated in just one hour with the Bucket System. The Bucket System is an effective strategy for sizing items because it explores each item in terms of pre-determined "buckets" of complexity. Keep in mind that these buckets are metaphorical; this strategy doesn't require the use of actual buckets, and instead uses sticky notes or note cards as buckets.

In this technique, the team starts by setting up a line of note cards down the center of the table, each marked with a number representing a level of effort. Then, the team writes each item or user story on a card. Each person draws and reads a random item,  then places it somewhere along the line of numbered note cards. There is no need to discuss further with the team. If a person draws an item that they do not understand, then they can offer it to someone else to place. Additionally, if a person finds an item that they think does not fit where it was placed, they can discuss it with the team until a consensus about a more accurate placement is reached. Team members should spend no more than 120 seconds on each item.  

Large/Uncertain/Small 

Large/Uncertain/Small is another quick method of rough estimation. It is great for product backlogs that have several similar or comparable items. 

This is the same general idea as the Bucket System, but instead of several buckets, you only use three categories: large, uncertain, and small. Starting with the simpler, more obvious user stories, the team places the items in one of the categories. Then, the team discusses and places more complex items until each is assigned to a category.

Ordering Method

The Ordering Method is ideal for projects with a smaller team and a large number of Product Backlog items. First, a scale is prepared and items are randomly placed ranging from low to high. Then, one at a time, each team member either moves any item one spot lower or higher on the scale or passes their turn. This continues until team members no longer want to move any items. 

Affinity Mapping

Affinity Mapping is useful for teams that have more than 20 items in their Product Backlog. 

A best practice is to conduct this technique using sticky notes placed onto a wall, whiteboard, or table. Each sticky note features a different user story or item. Using sticky notes allows the team to move user stories around in order to group them by similar theme, group, and pattern. The team begins by placing one sticky note on the board. Then, the team takes the next sticky note and discusses whether it is similar to the first item. Based on the team’s assessment, the second sticky note is placed in the first group or into its own group. 

After all of the items are grouped (there should be anywhere from 3–10 groups total), the team gives a name to each group that represents the general theme of the items. Then, the groups are prioritized by importance so that the team knows which items to tackle first. 

Characteristics of effective estimation

Regardless of which technique your team chooses, there are several important characteristics the techniques share that lead to effective estimation:

• Avoids gathering false precision of estimates. In Scrum, assigning rough estimates results in more accuracy across the project. Therefore, if the team focuses on identifying relative estimates—rather than a team having a lengthy debate about whether a task will take seven or 10 days of work—the team saves time and avoids potentially missing deadlines.

• Avoids anchoring bias. Many of these techniques (e.g., Planning Poker) keep the initial estimate private, which allows team members to form an independent opinion on the estimate before sharing their thoughts with the team. This prevents a known phenomenon called anchoring bias, where individuals find themselves compelled to put forth estimates similar to others in the room to avoid embarrassment. 

• Promotes inclusivity. These group estimation techniques not only lead to better estimates but also help the team develop trust and cohesiveness.

• Leads to effort discovery. Estimating in these dynamic ways can help the team uncover strategies to get items completed which might otherwise not have been revealed.

Key takeaway

There are several strategies to enlist when it comes to estimating effort and ordering your Product Backlog. Any one of these techniques are useful. Choosing a particular strategy is just a matter of what your team prefers. 

Relative estimation means to compare the effort estimated for completing a backlog item to the effort estimated for another backlog item. Doing this instead of trying to determine exactly how long a task will take allows your comparisons and estimates to be more accurate relative to one another.

T-shirt sizes

At first, T-shirt sizes may seem like a somewhat unusual way to measure an item or user story. But when you think about assigning estimations to items based on sizes (e.g., XS, S, M, L, XL, XXL), it is actually very helpful and easy. Some of the benefits to using this technique are that it is quick, well understood by Agile experts, and a good introduction for teams who are just learning relative estimation.

So what does the process of assigning T-shirt sizes entail? There are several specific techniques a team can try, but each generally follows these steps. The team: 

• Agrees on the chosen scale and metrics to be used.

• Identifies at least one anchor backlog item. That item will be assigned a T-shirt size. Some teams will choose two anchor items—one at the top of the range and one at the bottom of the range.

• Sorts through the remaining backlog items and agrees on T-shirt sizes for each of them. 

Story points

Using story points as the estimate unit is a little more advanced than T-shirt sizes, but it is essentially the same concept. This method is good for experienced teams. When using story points, teams usually use the Fibonacci sequence. As a reminder, this sequence comes from adding the two previous numbers in the sequence together. For example, 1 + 2 = 3 and 2 + 3 = 5. The important thing to notice about this sequence is that, as the list continues on, the numbers spread further apart from each other. Because of this, story points provide more accuracy and specificity than T-shirt sizes. 

So what does the process of assigning story points entail? There are several specific techniques a team can try, but the basic steps are the same as with T-shirt sizes. The team: 

• Agrees on the permitted points values. Some teams cap the size at a certain number, like 21. Some teams decide to jump from 21 to 100 as the next larger value. This is a team decision.

• Identifies at least one anchor backlog item and agrees to assign it a points value. Some teams will choose two anchor items, one at the top of the range and one at the bottom of the range.

• Sorts through the remaining backlog items as a team, agrees on an estimate for each item, and captures it in the backlog management system. 

Best practices

Some best practices, regardless of the technique you use, include:

• Asking the Product Owner questions about the user story or item to ensure that there is enough information to estimate it.

• Discussing divergent estimates from various team members so that everyone has a chance to understand how to implement the item.

• Agreeing on the final T-shirt sizes or points value and capturing it in the system.

• If certain items fall into the larger T-shirt size or story points value range, discussing whether it makes sense to break them down into smaller pieces before moving on.

Key takeaway

Either of these effort estimation units are effective at estimating your items and user stories. As a team, it is important to spend the appropriate amount of time deciding which is better for you. If you are a less experienced team, try starting out with T-shirt sizes, but more advanced teams should feel free to use either method.

As a recap, please read this overview of the Sprint taken directly from the 2020 Scrum Guide:

The Sprint

Sprints are the heartbeat of Scrum, where ideas are turned into value.

They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.

All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, happen within Sprints.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;

• Quality does not decrease;

• The Product Backlog is refined as needed; and,

• Scope may be clarified and renegotiated with the Product Owner as more is learned.

Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month. When a Sprint’s horizon is too long the Sprint Goal may become invalid, complexity may rise, and risk may increase. Shorter Sprints can be employed to generate more learning cycles and limit risk of cost and effort to a smaller time frame. Each Sprint may be considered a short project.

Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

Product Increment is what is produced after a given Sprint and is considered releasable. The Scrum Guide states that “An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.”

Potentially releasable product increment

Potentially releasable (or shippable) Product Increment is a handy way for teams to think about the desired result of a Sprint. The goal for every Sprint is to result in a completed, tested, ready-to-ship addition to the product or solution. This doesn’t mean the product will actually ship to customers—that is why they use the word “potentially.” Consider, for example, building an application for finding and adopting pets. Three features on the product backlog could be: 

1. Presenting information about available pets

2. Rating potential matches based on adopters

3. Allowing user to contact the adoption center

It doesn’t make sense to ship any one of those features in isolation, but finishing a potentially releasable Product Increment is helpful because it enables the team to see one feature in its entirety rather than to work on bits and pieces of all three features with none of them actually completed. With a potentially releasable Product Increment, you will create a complete, working, tested implementation of one feature in a single sprint.

Having a potentially releasable Increment also allows the team to get early feedback on the product, ensure that the work is high quality, and have the opportunity to respond to change. You should always focus on a potentially releasable product increment as your sprint goal.

Definition of Done

A related term is the Definition of Done. The Definition of Done is a formal description of the state of the potentially releasable Product Increment and what it means when it meets the quality measures required for the product. It is the team’s agreed-upon requirements for any backlog item that is considered “done.” In software projects, teams often decide that “done” means the software has been completed, reviewed, and has passed testing. In a non-software project, a Definition of Done may be a document including a legal review with approval or a formalized closeout report. The important part of figuring out your team’s Definition of Done is to have an explicit, shared understanding of what being “done” entails.

But how do you know when a solution is shippable or releasable? In a Scrum Team, it is ultimately the decision of the Product Owner to ensure there is value before releasing an item. To determine this, they may consider a few things: 

1. Is the increment complete? 

2. Will it bring value and does it meet quality measures? Has it been well-tested? 

3. Is it usable by the end user? Can we use their direct or indirect feedback to improve future versions of the product?

Comparing Releasable Product Increment to Minimum Viable Product

As you learned in the previous video, a minimum viable product (MVP) is a version of a product with just enough features to satisfy early customers. Eric Ries, an entrepreneur and author, coined the term in this guide and defined an MVP as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” In other words, gathering insights from an MVP enables quicker feedback from users than developing a full-featured product that may not be 100% tested or secure. Some examples of an MVP could be a landing page for your website or a “buy now” button that doesn't do anything other than register that someone has clicked it. 

A minimum viable product is a package of features that may take several sprints to develop, but every sprint’s goal is to produce a product increment. To differentiate between a potentially releasable increment and a MVP, let’s take our example of the online pet adoption app and the three features we discussed previously. We noted that each of these features on their own wasn’t a useful release of the solution. However, the Product Owner may decide that the MVP for this user experience is to implement these three requirements for cats only. By reducing the scope of the MVP, the Product Owner is able to release the solution into the marketplace and collect feedback from the users who wish to adopt cats. This feedback will be valuable not only for the cat adoption process but for any type of pet adoption in future iterations of the product. 

Key takeaway

So can a releasable increment be an MVP? Yes!  Does it always have to be an MVP? Not necessarily. A Scrum Master or Product Owner is always making sure that the team is building potentially releasable increments of the solution or product. Then, the Product Owner uses those product increments and business insights to determine what will make up a valuable and viable release of the product to their customers. This is based on both user value delivered and the ability to gather feedback that will continuously improve the product.

Retrospectives are an integral aspect of project management, especially true when it comes to working in Scrum. As we mentioned in the previous video, retrospectives are one of the five Sprint events in Scrum. In this reading, you will learn some best practices to implement and pitfalls to avoid when conducting Sprint Retrospectives. 

Sprint Retrospectives

As a refresher, retrospectives are workshops or meetings that give project teams time to reflect on a project and brainstorm potential future improvements. In the Scrum framework, Sprint Retrospectives occur at the end of each Sprint, which is usually every one-to-four weeks. 

Sprint Retrospectives are a key practice that supports the Scrum theory and values. They are a critical moment to inspect and adapt to the outcomes produced within the Sprint timebox. Retrospectives occur much more often in Scrum than in traditional project management,  so it is important to consider some best practices and pitfalls to avoid to help make them engaging and productive for the entire team.

Pitfalls

Avoid too many gimmicks. 

• There are many fun games and exercises that can be used by a Scrum Master when facilitating a Sprint Retrospective. However, not all teams enjoy this style. Consider using these exercises only occasionally or when the team asks for new ways of doing retrospectives.

Try not to only focus on the negative. 

• Not only is it necessary for the team to recognize what’s not working well, it is also important to highlight where they exceeded expectations. This ensures that the team both avoids failures and repeats successes as well.

Avoid changing processes after each retrospective. 

• It is okay to keep a new process in place for a few Sprints before deciding whether it was useful or not. You can always make note of opportunities for change, but try to wait a few Sprints before implementing new changes.

Best practices

Ask open-ended, probing questions. 

• Ask questions that require thoughtful discussion rather than a yes-or-no answer. For example, ask, “How could we have better achieved our Sprint Goal?” rather than “Did we achieve the Sprint Goal?””

Consider diverse styles of communication and participation. 

• Make it easy for all team members to contribute their ideas and feedback. For example, not everyone feels comfortable speaking up in a large group. Try things like starting the retrospective with silent reflection by journaling or putting the team into pairs before starting a larger group conversation.

• Cover the many aspects of the Sprint when conducting a retrospective.

1. The productivity and efficiency of the team

2. The scope and understanding of the definition of done

3. Communication and interactions within the team

4. Stakeholder communication

5. Progress towards more long-range release plans

Consider reflecting periodically on Scrum theory and values by asking specific questions. 

• For example, ask, “How could the team become more transparent?” or “How did we abide by our Scrum values in this Sprint?”

Velocity is defined as “The measure of how many points the team burns down in a given Sprint on average.” Velocity measures the amount of work a single team can be expected to complete during an iteration. When we refer to story points, we are referring to a unit of measurement that expresses the estimated effort required to implement that Product Backlog item. These story points are calibrated and decided on by the team.

Calculating velocity

As described in the video and readings, estimating effort can be done in a variety of units. Most often in Agile teams, story points or T-shirt sizes are used to estimate effort. If you use T-shirt sizes, your team will map those sizes to a numeric value for the purpose of calculating a team velocity. 

When your team begins running Sprints or iterations, they won’t be able to accurately determine velocity because they will have no historical basis on which to calculate an average number of points completed in a Sprint. In their very first Sprint, your team will make a rough guess as to how many items they can complete just to get started. Once a few Sprints have been completed, your team will have a good measure of their velocity, and they will use that number to determine which items to include in their Sprint Backlog. This should be easy to do if your team has a properly prioritized and estimated backlog to work from. As you will recall from the videos, this process is called backlog refinement.

Using velocity for good 

When interpreting velocity, it is important to keep a few things in mind. You may feel inclined to share velocity with members outside of your team or to use velocity as a performance or comparison metric. You may also feel inclined to use it to determine a projected delivery date. However, some Agile experts warn against these practices. Let’s discuss why. 

Velocity can be helpful for individuals outside of the Scrum team, but when sharing it with non-team members, be very careful. Since velocity is different for every team, a stakeholder may not have enough context to interpret it. Be sure to share relevant supporting materials to help add context. A good example of this is sharing the velocity with a corresponding date range and visualization that indicates trends over time. There may be dips and spikes in velocity that draw insights and encourage improvements in future projects. 

It is natural for individuals to want to quantify performance through data, but it can be detrimental for a team to feel that kind of pressure within their Sprints. There may be executives, sponsors, or stakeholders that want to use velocity as a performance metric, but this will only hurt the team by encouraging tactics like intimidation. If the team is worried about their velocity making it seem like they are underperforming, the team’s culture can become harmed as a result. 

If you are leading a few different Scrum teams, you may be tempted to compare the two teams’ productivity based on their velocity. You may have the impulse to check which teams are completing the most story points per iteration. However, the weight of different story points is subjective because they are created by the team. One team may consider a story to be five points, but another team might consider it to be closer to three points. Therefore, judging productivity solely on velocity isn’t accurate or fair. Additionally, velocity is not a measure of value. One team’s velocity might differ from another team’s, but this variability is fine as long as both teams are delivering value to your stakeholders.

Using velocity to estimate the delivery date of a project spanning numerous Sprints can be tricky. Velocity can be used as a pressure point by external stakeholders who want to set a date for their product launch. Velocity can also create false expectations and a harshly competitive culture when the team doesn’t hit the estimated dates. Projecting deliverable dates is harmful because it can take a team several Sprints to really understand what they are capable of delivering in each iteration. Also, if you map out too many dates in advance, you aren’t able to account for the changes and issues that will arise. Therefore, make sure you are being careful not to use the estimated delivery dates as commitments. 

Go to next ite

Roadmaps are an important part of any long-running project. In this reading, we will summarize the benefits of and best practices for developing a product roadmap, as well as highlight some of the pitfalls you might encounter. 

You may see different types of roadmaps as you continue your project management career. Each team or company may interpret the roadmap slightly differently. Here are some of the various types:

• Project roadmap

• Product roadmap

• Value roadmap

• Lean roadmap

• Agile roadmap

Roadmaps are often represented visually and many try to fit the roadmap on one page so that reviewers can notice the big picture of the product timeline.

The benefits of developing and maintaining a product roadmap are numerous:

• Clarifying the sequence of deliverables 

• Showing teams how their efforts relate to the north-star vision. In other words, their ultimate goal. 

• Showing stakeholders the incremental value that will be achieved over the course of the project (rather than reviewing it as one big delivery at the end)

• Helping stakeholders roughly understand the layout of the work behind the deliverable

There are also some pitfalls around roadmaps to avoid:

• Letting stakeholders think the roadmap is set and unchangeable. This may cause stakeholders to impede teams’ ability to adapt in response to new information, as well as put a lot of pressure on teams to achieve deadlines no matter what it takes.

• Spending too much time fine-tuning delivery dates versus keeping them rough and improving specificity as the dates get closer

• Putting all the work into creating the roadmap rather than producing the deliverables 

Here are some best practices to help you get the most from your roadmaps:

• Make it highly noticeable to the team and refer to it frequently.

• Clearly indicate the highest priority items.

• If possible, clearly indicate the highest value items.

• Make it visible to your wider stakeholder group so that they can use it for their planning. 

• Conduct regular reviews of the roadmap with sponsors, stakeholders, and the team to ensure that it is still providing the blueprint for the project.

To learn more about some best practices for building product roadmaps, check out this article: Product Roadmap First Principles

Key takeaway

Roadmaps are important for any well-managed project, but they are especially useful to Agile teams. Having a shared roadmap about what the team is delivering over a longer time period is an important way to connect the work that the team does on the sprints with the broader vision for the project. This helps the team stay motivated through the rough patches and leads to a great sense of accomplishment as roadmap deliverables are achieved.

Agile dedicates one of its four values to “Responding to change over following a plan.” This reading aims to clarify some important considerations when implementing a change to the release plan.

The best way to think about changing your plan is to break it down into three stages:

1. Identifying a needed change 

2. Deciding to make the change

3. Implementing the change

Step 1: Identifying a needed change 

First, how do you know if your plan needs to be changed? Here are some aspects of your project that may be candidates for change: scope, time, and costs (or resources). As we previously learned, these are called the “triple constraint,” and they provide a great framework for evaluating change in Agile and traditional projects.

• In Agile, scope refers to the contents of the product roadmap, the items in the Product Backlog, the intended deliverables of the project, and the intended users or customers. This is the “what” of the project.

• Time refers to the elements of time or layout of the deliverables over a period of time. This could include the product roadmap timeline, release schedule, or even the Sprint duration. This is the “when” of the project.

• Costs or resources refer to the makeup of the Development Team, project managers, and product owners, and other “business people” as well as the equipment available to create the deliverable. This is the “how” of the project.

Agile projects are open to change in any of these three areas, and a needed change could be identified by any project stakeholders, including the Product Owner, Project Manager, Scrum Master, or the Development Team themselves. Sources of identified changes could include:

• Customer feedback on early prototypes results in new features and some deleted features (scope change)

• Sprint Retrospective identifies an area of understaffing (cost or resource change)

• Critical project dependencies or deliverable dates have shifted, resulting in a change to the project roadmap (schedule or time change)

Step 2: Deciding to make the change

Next, how do you decide to actually make the change? There are many decision-making models available to reference. Here are the basic steps involved in most of these models:

• Identify the “decider.” It is best to have a single person—generally the Product Owner or a senior stakeholder—in the role of decider to ensure consistency and accountability. 

• Develop and share what factors are important to the decision, and gather supporting data that will help the decider make the decision.

• Openly discuss the benefits and costs of the decision. Identify areas of uncertainty and capture assumptions.

• Document the decision.

Step 3: Implementing the change

Once changes are approved, it is important to do several things:

Document the change and decision-making process. 

• Include meeting notes, pros/cons lists, assumptions, and data that went into making the decision to change the project.

Capture the change in any affected artifacts. 

• Update any roadmaps, Product Backlogs, staffing plans, and integration dates, and include a reference to the source of the change so that stakeholders can refer back to it. Consider using revision labels or dates on affected documents like “version 1.2” or “updated on December 20th” so that the team can clearly recognize that the document has changed.

Share the change with all affected stakeholders. 

• You can do this through many types of forums: in person at meetings, in documentation and meeting notes, and through email announcements. 

Monitor the change for a certain amount of time. 

• This ensures that the team is supportive and aware of the change.

If the change was not approved during the decision stage, you should still document the information and logic used to make the decision. You may even consider putting a change on hold while you wait for more information to make the decision with higher confidence.

In this reading, we will learn about the influencer change framework developed by Joseph Grenny, Kerry Patterson, David Maxfield, Ron McMillan, and Al Switzler in the book INFLUENCER: The New Science of Leading Change, which explores the power of influence in facilitating organizational change. 

What does it mean to be an influencer? 

These days, when we hear the word influencer, some might think of social media stardom. But being an influencer is bigger than getting “likes”—it is about someone’s ability to lead and influence others to change their behaviors, hearts, and minds to produce meaningful, sustainable results. As a project manager, you will be asked to lead efforts that require this level of change, and applying this model can lead to a big impact.

To influence is different than to persuade. Persuasion is short-term, while influence is lasting. In order to have real influence, you need others to trust you, consider you an authority, and have confidence in your decisions. As a project manager in Agile projects, you may use influence to facilitate organizational change or to get a team to try a new tool, process, or technology. When facilitating organizational change, influence is the difference between temporary changes in behavior and deep change in culture and values.

Three keys to influence 

The three keys to influence, as researched by the authors of this model, are to clarify measurable results, find vital behaviors, and use the six sources of influence. Let’s break each of these down.

Clarify measurable results

You can’t influence others to change until you know what you want, why you want it, and when you want it. You may recall that effective results are specific, measurable, achievable, relevant, and time-bound (S.M.A.R.T). When setting goals for a project, remember to ask yourself what the “why” entails. Are the results specific and measurable? Is it what you intended? Is it time-bound? Also, make sure the measures are visible and transparent to the entire team throughout the change.

Find vital behaviors 

A vital behavior is the action an individual takes at a pivotal moment in the context of the change they are seeking. For example, if a member of the Development Team is seeking to increase involvement of the Product Owner throughout the development process, they might exhibit a vital behavior when they have just finished mocking up a new feature. Instead of just continuing on to the next item on their to-do list, they might send an email to the Product Owner to review their work and provide feedback. By choosing to include or exclude their Product Owner at a pivotal moment, the developer is taking a small action to enact the change they want to create.

As we have discussed, real change happens when you can change the behaviors of others. Whether you are changing the minds of your team, stakeholders, or customers, it is important to track their current behavior patterns and understand the behaviors you need them to adopt in order to make the change you are seeking. 

To determine vital behaviors, you might consult experts, scan the best and most-cited articles and research, or perform a culture assessment by identifying norms and customs within the team. When identifying the behaviors, evaluate which behaviors are constructive to the change you wish to promote and notice examples of those who succeed where most others fail.

Use the six sources of influence

The authors of INFLUENCER: The New Science of Leading Change studied companies and individuals who were successful or unsuccessful with implementing change, and they identified six sources or factors that were correlated with successful change. When determining how to influence your target audience to create change, you should consider using all of these sources to increase your chances of success. You may even consider prioritizing these based on your knowledge of your audience. For example, some target audiences may be most swayed by financial incentives, while others may be more incentivized by social justice impacts. 

Here are the six sources uncovered by the authors in their research, including a sample idea of how you can use these examples in your work in tandem with our Product Owner involvement scenario (described earlier):  

Personal motivation: Are the individuals motivated internally to engage in the new behavior? Can you help them “love what they hate”? 

Example: Ensure the Product Owner is timely, appreciative, and effective while giving their feedback. 

Personal ability: Are the individuals capable of performing the behavior? Do they have the ability, knowledge, and skills to “do what they can't”?

Example: Ensure that the developer knows how to use the available demo tools and can easily send a quick video of the new feature in their email to the Product Owner. 

Social motivation: Are there social contacts or networks encouraging or discouraging this new behavior? 

Example: Have the Development Team members remind each other in the Daily Scrum to email the Product Owner before they finalize the work.

Social ability: Does the team have resources within their social network to help them carry out the new behaviors?

Example: Give the Development Team a tool to track all of their demos to the Product Owner during the Sprint. 

Structural motivation: Are there rewards or incentives that they will receive if they perform the new behaviors? 

Example: Provide a coffee gift card Sprint award that the Product Owner gets to award after each Sprint.

Structural ability: Are there environmental factors at play that either deter or support the new behavior? Can you make the incorrect behavior harder to do than the correct behavior?

6. Example: Add a rule to the content management system that pre-populates the name of the Product Owner in the reviewer list. 

Key takeaway

These three keys to influence make up the influencer change framework and will improve your chances of success with a change. Clarify measurable results, find vital behaviors, and leverage six sources of influence in tandem to lead an organization, team, or an individual to experience positive change. 

To learn more, we suggest reading the book INFLUENCER: The New Science of Leading Change or the article The Influencer Change Framework–The Power to Change Anything, which summarizes the book. 

In this reading, we will further explore the work of a coach and how it differs from that of a manager. 

Both managing and coaching play important roles in project management. The difference in each approach is in communication. Management is about giving direction, while coaching is about teaching. Some situations will call for coaching, and others will call for management. As a project manager, it is important that you understand when each skill set is necessary for success. 

Managing

So far, we have focused on the responsibilities of project managers. We know that project managers are tasked with delivering a project objective and solving problems as they arise. Project managers keep team members organized and on track. They streamline communication and give directions. This is very indicative of a traditional management approach. At its core, managing requires overseeing the work of others and can include: 

• Onboarding and orienting new employees

• Conducting meetings

• Delegating tasks and assignments

• Monitoring progress and performance against those tasks

• Making high-level decisions

In Agile project management, however, teams are designed to be self-managing. A self-managing team has the autonomy to choose how best to accomplish their work, rather than being directed by others from the top down. Agile team members should also feel empowered and equipped to problem-solve on their own.

Even so, there are some cases where the decisive action of a manager is required. Examples include if there is an emergency that needs immediate action, if you are behind on a deadline, or if a client has very specific needs and you are the most familiar with them. In a results-driven project with little room for error, someone needs to step in and take the lead. That is where a managing approach comes in. 

Coaching 

Although managing seems inherent to project management, coaching is also an important part of the project management role. 

Coaching is a two-way communication style aimed at influencing and developing team members’ skills, motivation, and judgment. Coaching empowers team members to arrive at solutions on their own by teaching them critical thinking and decision-making skills. This is achieved through offering feedback and providing opportunities for professional development. When challenges arise, coaches will offer guidance, then get out of the way. Coaches don’t jump in during times of crisis in a way that a manager would. Coaches ask questions to help team members arrive at conclusions on their own.  

Coaches trust that their team members can make smart decisions, and trust can go a long way. When team members feel trusted, workplace satisfaction increases, and the quality of work improves.

It is appropriate to use a coaching approach when a team member already has experience working on similar projects and is working on growing new competencies or is trying a new approach for the first time. Coaching is about building confidence and capabilities so that individuals can continuously grow and improve. There are a few principles to keep in mind when coaching: 

1. Motivate: Coaches motivate team members to take action. They point out the value in others’ work and instill within them a sense of pride in what they do. 

2. Support: Coaches are an accessible resource for their team to come to when they experience problems or if they have an idea they want their feedback on. 

3. Encourage and appreciate: When someone on their team is struggling with a heavy workload, a coach will acknowledge and validate the weight of their efforts and assure them that they are capable of handling the challenges ahead.

Coaching is appropriate in many circumstances, especially when you need to build up the confidence of an individual or a team. The most effective leaders strike a healthy balance between managing and coaching based on the needs of the situation, individual, and project they are leading. Examples of where coaching would be helpful include when a team member is branching out into using a new technology or discipline that will turbocharge their career opportunities, when an individual’s behavior is having unintended consequences on the team dynamics that are not readily visible, or if a team is recovering from a setback.

Here’s a scenario where a project manager or Scrum Master should step in to coach a team: Imagine a Scrum team has failed to launch a product that meets the customer needs Sprint after Sprint. The Product Owner continues to communicate to the team that the features are not quite right, and they need to rework the product in the next Sprint or release. The team feels deflated, and they are showing signs of burnout because they keep working on the same three features. Here is a perfect opportunity to do some coaching with the whole team. Consider bringing them together for a working session and cycle through all three principles of coaching:

1. Motivation: Ask the team to brainstorm positive reasons why the customer is providing this feedback and why it matters to create an excellent end product.  

2. Support: Work with the team to capture ideas on how to streamline the customer feedback process, such as a design Sprint with the customer in attendance.

3. Encourage and appreciate: Set up an event where the team celebrates the work they have accomplished so far, and make the event fun and inclusive for all team members.

Key takeaway 

Managing and coaching are distinct leadership approaches that each yield different results, and both styles require effective communication. A managing style typically utilizes one-way communication to assign tasks and give directives. Coaching relies on open communication in both directions to help develop an employee’s or team’s skills, so they can become self-sufficient. Some team members and company cultures will naturally favor one style over another, but both are necessary leadership skills. As an Agile project manager or Scrum Master, you will use both styles. That said, in Agile and Scrum, a coaching style is usually the best initial option since it will increase the capabilities of the team, leading to more agility over time. 

When deciding which approach to use, ask yourself:  

1. What is the desired outcome? 

2. What is the skill level of the team member who has encountered a problem? 

3. What does the situation need now to reach the desired outcomes?

For further reading on coaching with Scrum values, check out this blog post from Scrum.org. 

In this reading, we will explore five frameworks that scale the Agile approach to address the needs of large initiatives or solutions: Scaled Agile Framework (SAFe), Scrum of Scrums, Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), and the Spotify Model.

Scaled Agile Framework (SAFe)

The most popular scaled framework is the Scaled Agile Framework or SAFe. SAFe is a Lean-Agile scaling framework that draws heavily on concepts from Kanban, Scrum, Extreme Programming (XP), DevOps, and Design Thinking methodologies. SAFe puts the goal of delivering value above all else—the first principle of SAFe is “take an economic view.” The framework organizes all work and teams into “Agile Release Trains” based on value streams; for example, sales. The SAFe framework is mature and provides detailed guidance on all elements of using SAFe, but some elements are more critical than others. Be sure to check back to the Agile principles and values in the manifesto to be sure you are preserving agility. 

SAFe, like most Agile practices, is founded on a set of core values:

• Alignment: Synchronize the planning and execution of SAFe activities at all levels of the organization. 

• Built-in Quality: Build quality into all stages of solution development. 

• Transparency: Make execution activities visible at all levels to build trust among teams and across the organization. 

• Program Execution: Focus on working systems and business outcomes. 

• Leadership: Model the values and principles of SAFe. 

Read this article to learn more about the core values of SAfe.

Scrum of Scrums

Scrum of Scrums is a technique for integrating the work of multiple, smaller Scrum teams working on the same project or solution. Coordination among teams is critical to ensuring the deliverables from each team can be integrated into one larger, cohesive deliverable. 

Scrum of Scrums involves the following elements:

• A group of at least 12 or more people divided into Scrum Teams of five to ten people each 

• Scrum of Scrums meetings, which are held once a week, twice a week, or daily. These meetings follow the same format as a Daily Scrum meeting but focus on the Scrum team. In these meetings, you’ll discuss questions like: “What did the team do yesterday? What problems occurred, if any, that are negatively affecting your team? What does your team want to accomplish before we meet again? Is your team blocked from moving forward on any tasks?”

• A Scrum Master or designated “ambassador” for each team that participates in the Scrum of Scrums meetings and a Scrum of Scrums Master who focuses on the overall Scrum process across multiple teams 

• Sprint Planning, Sprint Review, and Sprint Retrospective meetings 

Beyond these very basic guidelines, there is no official framework or methodology to implement Scrum of Scrums. Scrum of Scrums assumes that teams have a good working understanding of Scrum and are able to apply the scaling principles to how they work. Building on this knowledge, they design and iterate their own approach to coordinate multiple teams working on the same product. 

Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) is a framework that aims to maximize the Scrum team’s ability to deliver value and reduce waste in larger organizations. LeSS grew out of more than 600 experiments that expanded the practice of Scrum to larger groups. 

LeSS includes ten principles for applying the value, elements, and overall purpose of Scrum across an organization. These principles were designed to create more customer- and collaboration-focused teams. LeSS teams prioritize learning, transparency, and customer needs. The ten LeSS principles are:

1. Large-scale Scrum is Scrum: Apply the values and principles of Scrum to a larger team. 

2. Empirical process control: Inspect, adapt, and learn from experience to improve processes. 

3. Transparency: Ensure clarity and accessibility across a project. 

4. More with less: Create only necessary processes, roles, artifacts, and waste when scaling. 

5. Whole-product focus: Think holistically about the product, making sure that all the parts serve the whole.

6. Customer-centric: Keep the customer’s needs and values at the heart of your process.

7. Continuous improvement towards perfection: Improve the product—and your process—during every single Sprint. 

8. Systems thinking: Think about the system as a whole; Don’t get lost in the details. 

9. Lean thinking: Seek continuous improvement, aim for perfection, and respect people.

10. Queuing theory: Embrace the Lean principles of “flow,’ manage queue size,” and “minimize multitasking” to keep delivering value. 

The LeSS toolkit provides two frameworks—one for up to about 50 people (called Basic LeSS) and one for 50–6000+ people (called LeSS Huge). More information on the LeSS frameworks can be found at less.works.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) is a hybrid approach that combines the strategies from various Agile frameworks, including Kanban, LeSS, Lean Development, Extreme Programming, Agile Modeling, and more. DAD guides people through the process-related decisions that frameworks like SAFe and Scrum of Scrums leave open. DAD helps you develop a scaled Agile strategy based on context and desired outcomes. 

DAD is organized into four “layers”:

1. Foundations discusses the principles, guidelines, Agile concepts, roles and team structure definitions, and Way of Working (WoW).

2. Disciplined DevOps ensures that solutions are delivered to customers effectively and safely, with data and security management always at the forefront.

3. Value Streams ensures that solutions are aligned with the organization's business strategy, connecting customers, sales, and portfolio management to the framework.

4. Disciplined Agile Enterprise (DAE) connects the industry marketplace with corporate governance and larger enterprise activities.

Project managers wishing to implement DAD can read more about the framework in this article: Going Beyond Scrum.

The Spotify Model

Another approach you may encounter is the “Spotify Model,” which we discussed in a previous reading. It is important to note that Spotify’s model is not a true Agile framework. There is no standard guide on how to implement it. The model began as a description of how Spotify overcame the challenges of scaling Agile. By focusing their efforts on culture, team autonomy, communication, accountability, and quality, they increased their agility over time. Spotify’s approach has had a huge impact on workflows and team structures across the tech world. Some of the key components include:

• Squads: Like Scrum teams, Squads are autonomous teams of 6–12 people working toward the same outcome. All Squads include a coach (similar to a Scrum Master) and a Product Owner.

• Tribes: When multiple Squads work on the same feature area, they form a Tribe of 40–150 people. Each Tribe has a Tribe Lead who fosters collaboration and coordination.

• Chapters: Squads may be autonomous, but specialists (e.g., JavaScript developers) should still align across an organization. Chapters establish best practices and, where necessary, set standards. 

• Guilds: Any group of people interested in a certain topic can form a Guild, where people with shared interests can come together as a community. 

While some organizations have had success with this model, be aware that it evolved from Spotify’s already significant Agile experience. It is the product of extensive introspection and adaptation and draws heavily on the company’s culture of trust, transparency, and autonomy. Therefore, the value of Spotify’s approach to scaling is not in team names like Squads and Tribes but in how they developed practices that supported and served their organizational culture. To learn more about the Spotify Model, check out this video from Henrik Kniberg.

Best practices for scaling Agile

No matter which framework you choose, it’s important to keep a few basic principles in mind:

• Treat scaling models like SAFe, Scrum of Scrums, LeSS, etc., as general frameworks, not instruction manuals. 

• Different situations require different solutions. It’s okay to mix and match elements from multiple frameworks, as long as you apply the principles and values of the Agile Manifesto.

• Don’t try to scale without prior Agile experience. Going straight from Waterfall to scaled Agile can be risky without a knowledgeable guide.

• Finally, and most importantly, don’t scale if it isn’t necessary. The larger your team, the more complex and difficult your project becomes. 

Key takeaway

Scaling Agile can be as simple as putting two Scrum teams together into a Scrum of Scrums configuration or as sophisticated as training an organization of thousands in the SAFe framework. When you have a large team or a big deliverable that requires multiple workstreams, think about how you can scale to suit your situation. Remember that you can modify SAFe, LeSS, and other scaled frameworks to meet the needs of each project. Make sure your team understands Agile principles before you try to scale since scaling inevitably introduces more waste and complexity.