Agile

Dependency is a potential obstacle that slows down or blocks the work of a Scrum Team.

There are three main categories of dependencies that a Scrum Team encounters, and each category of dependencies differs in complexity.

1. Intra-team Dependencies

The least complex scenario of dependency is when one team possesses all the skills needed to create a backlog item (PBI) that is potentially ready for deployment. The team has no external dependencies. However, team members may still face:

Backlog items dependent on each other, and/or

Tasks in the sprint that depend on each other.

In any case, a self-managing team with a skilled Scrum Master should be able to understand these dependencies independently. If such dependencies are identified, developers clarify technical dependencies to the Product Owner (PO), and the Product Owner uses this information to reorder the product backlog. Regarding dependencies between tasks in a sprint, developers are responsible for coordinating actions on these tasks.

What can help:

Rework and decompose backlog items to make them more independent. This is best done before sprint planning, during Refinement, but can also be done during sprint planning.

When planning a sprint, it’s essential to understand potential risks created by dependencies and agree on how they will be resolved. For example, the choice between Path A or B for Element 2 cannot be implemented until Element 1 is completed. Carefully monitor these dependencies during the sprint.

2. Inter-team Dependencies

The next, more complex category is inter-team dependency, arising in a multi-team environment where more than one team works on the same product. Each team can take and deliver product backlog items as they complete them, but control over the sequence of delivery or technical coordination between teams may be required.

You can start with something simple – coordination between self-managing teams.

What can help:

To minimize conflicting information, there should be only one Product Owner.

Ensure that the Product Owner works with teams and understands how to distribute work. For example, if you assign all high-priority tasks to Team A and lower-priority tasks to Team B, it may result in less value if Team A fails, compared to a situation where both teams work on tasks with the same priority.

Choose one or two representatives from each dependent team as representatives. These representatives will be responsible for coordinating with representatives from other teams. This activity will be carried out within the Scrum of Scrums – a regular meeting aimed at exchanging information and solving coordination issues between teams.

Using Scrum of Scrums, team representatives can also coordinate actions before and after sprint planning and Sprint Review.

Remember that Sprint Review is open to any interested party, and members of dependent teams may attend. Don’t forget to invite them.

3. External Dependencies

This is the most complex case – when the Scrum Team cannot complete all the work required to deliver a sprint backlog item. They need help or support from:

Another Scrum Team,

Another department, or

An external supplier.

Do the external parties on which the team depends practice Agile and Scrum?

If yes, they understand what is expected of them, and you can coordinate work plans at the product backlog level.

If not, and you cannot change this yet, the Scrum Team will have to plan its work according to the schedules of external parties. Ensure that tasks for monitoring and working with these dependencies are included in the team’s capacity.

What can help:

Request delivery confirmations from external parties. Get information on work volumes and specific dates.

Monitor the situation. Invite external representatives to the team’s daily Scrum meetings. Regularly check the agreed delivery schedule. Instead of checking the progress of work, periodically ask: “Are there any reasons why you cannot meet your commitments?”

Conduct a Retrospective on the performance of the external party. Were they reliable? Can you rely on them to deliver what they promised on time? If not, what will you do differently next time to reduce risks?

Finally, do not add a task to the sprint if there is an external dependency without specific delivery commitments. Since this is a business issue, Product Owners must be fully engaged and obligated to provide any assistance needed to manage the external party or another department in your organization. Product Owners have the authority and levers that can be very effective when used correctly.

Remember that dependencies can disrupt the continuous delivery of value. Do not think of dependencies as just how things are but instead consider them as potential obstacles and make efforts to eliminate or mitigate their impact.

One of the most significant challenges for entrepreneurs is how to turn their ideas into plans. You might have a good idea, but describing and working through it can be much more complicated. From ideas for a new business to creating a cohesive plan and concepts for new products and services, it can take weeks or even months.

Lean Canvas is a planning method that helps you understand the essence of your idea. This method places all the information on one page, helping to outline the necessary key points without unnecessary details.

What is Lean Canvas?

Lean Canvas, the “Lean Business Model Canvas,” is a one-page business plan method created by Ash Maurya, adapted from Alexander Osterwalder’s Business Model Canvas.

The plan has several blocks that will help you mark key points to transform your business idea into something more concrete.

Lean Canvas is specifically designed for entrepreneurs to make it easier for them to get a clear and straightforward idea of what they plan to implement.

Structure of Lean Canvas

Below are the sections of Lean Canvas with explanations:

Customer Segments: Understanding who your customers are is a crucial step. You can’t understand their primary problems if you don’t know who they are. In the “Customer Segments” section, you need to identify who your target audience is, which may include several customer segments.

Problem: It’s essential to understand the key problems your customers face. This section is used to list the main problems you intend to solve, faced by customers from different segments.

Revenue Streams: Where will your money come from? How do you plan to set prices for your products or services? Your pricing model is a crucial part of what you offer, and you’ll need to study and test it. How much are people willing to pay, and what is the minimum price you can set to achieve your goals?

Solution: What solution to your customers’ problems do you plan to offer? You won’t always have the perfect solution immediately, but the goal of creating a business plan is to help you start this work. If you want to find a solution to your problem, don’t assume it will come to you. Talk to your customers from different segments to find out what they want and need.

Unique Value Proposition: This section is in the middle of the page because it’s what you offer your customers. It specifies the unique value your business can provide. You need to think about what sets your brand, product, or service apart from others trying to solve the same problems as you.

Channels: What channels do you plan to use to attract customers? These are marketing and advertising methods you plan to use, from digital marketing such as SEO to more traditional channels like radio, print, and television. Remember that different generations use different communication channels.

Key Metrics: Your key metrics are what you will use to monitor the effectiveness of your business. You can identify some key indicators that you will closely monitor to understand how people interact with and use your business and its products or services.

Cost Structure: These are the costs your business will incur to launch and sell your product or service. This may include market research, technology, personnel expenses, and more. Having an idea of your one-time and periodic expenses, you can roughly estimate how many customers you will need to break even.

Unfair Advantage: Your unfair advantage is what you have that none of your competitors do. It’s something that can’t be copied or bought and will help you stand out. This is the final step in the process and often the most challenging. Your unfair advantage can be many things, from unbeatable personnel to an existing customer base.

You don’t need to spend hours filling out Lean Canvas. In fact, you should be able to outline some ideas in about 20 minutes. Of course, you won’t have all the necessary information immediately. But this plan will help you determine whether your business idea is justified and what your next steps should be.

And don’t forget that Lean Canvas is a flexible plan that can be adjusted later on.

If you work in an organization that is adopting or has already adopted Agile, you may have come across terms like Squad, Tribe, Chapter, and so on.

These names are not mentioned in the Scrum Guide, and it’s not entirely clear where they come from.

In reality, these are terms from the Agile model used by Spotify.

Spotify, a streaming service founded in 2006, allowing legal streaming of music, audiobooks, and podcasts without downloading them to the device.

Spotify is a 100% Agile company that started with the Scrum framework. However, as their teams grew, they noticed that some elements of the Scrum framework didn’t work for them. Therefore, they decided to change some Scrum roles, artifacts, and events.

Spotify’s engineers understood that Agile is more important than Scrum, and principles are more critical than specific practices. As a result, they renamed the Scrum Master to Agile Coach because they wanted more of a “serving leader” than “process masters.” They also renamed Scrum teams to Squads, and so on.

The structure used by the company for the flexible scaling of different teams located in different places became known as the Spotify model.

Squad

A Squad is a small, cross-functional, self-organizing team, usually consisting of fewer than eight people. Team members have overlapping responsibilities, and they work together to achieve their long-term mission. Autonomy is a key factor in Squads. The team doesn’t have a separate team lead, but there is a dedicated Product Owner.

Each Squad decides independently what to develop, how to develop it, and how to work together during development. However, the Squad must operate in line with the Squad’s mission, product strategy, and short-term goals.

How Squads Work at Spotify?

As Spotify has many different Squads, they needed to create some structure. Each Squad is grouped into a Tribe, which has a head. In this setup, you can change the composition without changing the manager. They also have a Guild, representing an interest community that uses a mailing list or another informal method of communication within Spotify.

Now, a bit more detail about the Spotify structure.

Tribe

A Tribe is a group of Squads linked by the nature of the work they perform. For example, several groups working together on the same product function or closely related product functions/one product in the portfolio of different products.

The recommended number of people in a Tribe, according to Dunbar’s number, is about 100. Dunbar’s number is a hypothetical limit on the number of stable social relationships that can be maintained, depending on the volume of the neocortex. According to Dunbar’s calculations, it was considered to be 150.

In a Tribe, there is a Tribe Lead responsible for creating a productive and innovative environment for Squads. The Tribe Lead may also be part of a Squad.

Chapter

A Chapter brings together specialists in specific disciplines/technological areas within a Tribe. For example, QA engineers, database specialists, front-end and back-end developers, UX/UI specialists. People performing these functions in several Squads of one Tribe come together in a Chapter.

Each Chapter regularly meets to discuss its achievements and issues in their respective knowledge areas, for example, QA Chapter, UX Chapter, DB Chapter.

In a Chapter, there is a Chapter Lead who can guide different Chapter members on “how” best to accomplish a task. The Chapter Lead can also be the direct manager of Chapter members, performing traditional managerial duties such as people development, career growth, etc. The Chapter Lead is also a member of one of the Squads in the Tribe, allowing them to understand issues from within.

All Chapter Leads in a Tribe usually report to the Tribe Lead, and the Tribe Lead performs all managerial duties for Chapter Leads in their Tribe.

Guild

A Guild is like an “interest community” covering Tribes throughout the organization, where people gather and share knowledge in a specific area.

Imagine an organization with three Tribes, each located in three different places. Depending on the location, each Tribe may have its QA Chapter. It is necessary for the members of the QA Chapter of one Tribe to exchange processes and knowledge with the members of the QA Chapter of the other two Tribes. The Guild serves precisely this purpose.

Henrik Kniberg, one of the contributors to the development of the way of working within Spotify, in response to the growing popularity of the Spotify model and its copying in other companies, claimed that the Spotify model is not a team scaling framework. Also, he stated that the Spotify model is not strictly a “model” as such but rather an example of how work is organized in a specific company.

In project management, the work environment is dynamic and often tense. For this reason, various conflicts are unfortunately a common occurrence. If you are managing projects, it’s crucial to understand how important it is to manage conflicts.

What is Conflict?

Conflict is a clash of opinions between disagreeing parties, which can be individuals or organizations, in resolving various issues.

Conflict management is the process of timely identifying and resolving conflicts that arise during project implementation. Conflict management is one of the key tasks of project managers.

Types of Conflicts: Constructive and Non-Constructive

Constructive Conflicts: These conflicts lead to well-founded decisions and contribute to the development of relationships between conflict parties.

Non-constructive Conflicts: These conflicts hinder making informed decisions and effective interaction between conflict parties.

Thomas-Kilmann Model

The Thomas-Kilmann model defines five different conflict resolution techniques. The model is based on two parameters: assertiveness level and cooperation level.

Competition

Involves making opponents accept one’s point of view by ignoring their opinion. This behavior can be effective in conflict resolution but might suppress team members’ initiatives.

Avoidance

Involves avoiding conflicts in any situation. The side effect of this approach is low initiative among team members, possibly resulting in the absence of an optimal solution to tasks.

Compromise

Is an approach where conflicting parties partially accept each other’s decisions. This allows quickly reducing conflict intensity but may lead to suboptimal decisions.

Collaboration

Helps resolve conflict situations most effectively. Opponents must be open to dialogue and strive to understand each other’s reasons for disagreement. This approach aids in developing the best solution to the problem.

Accommodation

Is an approach where one party unconditionally accepts the opponent’s opinion, disregarding its own. In this situation, conflicts may accumulate and eventually escalate into a more serious confrontation.

Conclusion

The most productive way to end a conflict is through collaboration, where both opponents gain something. Unlike compromise, where each party is forced to make concessions, collaboration’s main task is to find a solution that fully satisfies everyone.

And most importantly, remember that conflict is a kind of progress engine.

“As a whole, humanity will never be able to completely get rid of conflicts,” says historian-political scientist Elina Zurapova. “It is, if you will, a kind of driving force, an ‘impetus.’ It is that cargo on the scales that mai

We all know that one of the four values of the Agile Manifesto states:

“Responding to change over following a plan.”

However, this doesn’t mean that if we work with Agile, we don’t plan at all.

Here’s what is stated:

So, without denying the importance of what’s on the right,

we still value more what’s on the left.

Thus, planning your work is an important and integral part of Agile.

Characteristics of Agile Project Planning

Let’s explore different levels of planning mentioned in the “Agile Planning Onion.”

It’s crucial to understand that Agile planning is applicable at every layer of the “onion.”

We use planning not only at the team level (daily, iteration, release) but also for product management, portfolio management, and Agile strategy management.

In the Scrum framework, Agile planning is iterative. This means that we develop and adjust our plan at the beginning of each sprint. The goal is to invest time in planning at the optimal moment and easily adapt to changes during the execution phase.

However, besides this, there’s top-level planning, preparing a product roadmap at the very beginning, outlining major releases and corresponding features. This is also planning, though at a higher level.

After top-level planning and initial task estimation based on teams’ Velocity information, we can forecast the time required for tasks or the entire project.

Planning in Scaled Agile Environments

In scalable Agile frameworks, planning is more extensive.

Let’s take SAFe as an example, with an event called PI (Program Increment) Planning.

PI Planning is a face-to-face event based on a cadence, a regular event that serves as the “heart” for the Agile Release Train (ART), unifying all teams with a common mission and vision in the ART. PI Planning is crucial for SAFe; it’s considered that if you’re not doing it, you’re not doing SAFe.

“Those who do the work plan the work.”

Offline planning has its advantages, and the unwritten SAFe “rule” is: “Those who do the work plan the work.”

However, when physical presence is impossible for all participants, as seen during COVID-19, technical means for virtual meetings can be utilized. Many teams have successfully created a hybrid situation where several teams join both online and offline.

A Bit More Detail on PI Planning

PI Planning has a standard agenda, including a presentation of business context and vision, followed by group planning where teams create their iteration plans and goals for the upcoming Program Increment (PI). Teams specify when they’ll complete the discussed tasks.

All teams’ members participate in this event within the Innovation and Planning (IP) Iteration.

PI Planning extends for two full days. If participants are in multiple time zones, this time is often extended.

Business Benefits of PI Planning

PI Planning provides numerous benefits for business, including:

Establishing direct communication among all team members and stakeholders

Aligning development stages with business goals, context, vision, and team and program goals

Identifying dependencies and engaging teams in collaboration

Aligning requirements and team performance, eliminating redundant work

Facilitating quick decision-making.

Participants

PI Planning is a significant event that requires preparation, coordination, and communication.

Among the participants: business owners, product managers, Agile teams, architects/system engineers, and other stakeholders.

PO Sync is a time-limited (usually 30-60 minutes) weekly or more frequent meeting whose goal is to synchronize the Product Owners of individual teams in achieving common objectives.

In “The Scrum Guide,” this meeting is not mentioned and, accordingly, is not one of the Scrum ceremonies. Nevertheless, in some organizations working with Scrum, this ceremony is conducted.

PO Sync is used in scalable Agile frameworks, such as SAFe or Scrum at Scale.

PO Sync is somewhat similar to Scrum of Scrums (SoS), but the participants are Product Owners and Product Managers.

In SAFe, the organizer of this meeting can be the Release Train Engineer (RTE) or the Product Manager.

Among the discussed topics:

Functionality, performance, and compatibility

Work volume and schedule adjustments

Task prioritization

Checking task prioritization in team backlogs

Coordination and identification of interdependencies between teams

Team progress in task implementation

Task decomposition to align with the release

Definition of MVP (Minimum Viable Product)

Plan for subsequent actions

In SAFe, this meeting is mandatory. Sometimes PO Sync and SoS are combined, and such a meeting is called ART Sync.

Is it worth conducting PO Sync in organizations using Scrum or, for example, Kanban?

It all depends on the goals and tasks set by the Agile Office/PMO. If the purpose of these meetings is clear, participants and the agenda are defined, then why not. Otherwise, it will complicate processes and be a waste of time for all participants.

Let’s not forget about one of the values of Agile:

Individuals and interactions are more important than processes and tools.

Scrum of Scrums (SoS) remains one of the oldest and, at the same time, widely used techniques in Agile.

Origin

The Scrum of Scrums technique was first applied in 1996 by Jeff Sutherland and Ken Schwaber, pioneers of the Scrum methodology. Later, in 2001, Jeff Sutherland described Scrum of Scrums in his article “Agile Can Scale: Inventing and Reinventing Scrum in Five Companies”:

Scrum of Scrums, as I’ve used it, is responsible for delivering working software of all teams in accordance with the Definition of Done by the end of the sprint or by the release during the sprint.

Purpose

Scrum of Scrums (also known as Meta Scrum) is a scalable Agile technique used to integrate the actions of multiple Scrum teams working on one project. SoS helps teams interact with each other, integrate the results of their work, and coordinate their actions to achieve a common goal. This is particularly crucial in projects with dependencies and/or where the sequence of work is essential.

Scrum of Scrums Meetings

In regular Scrum of Scrums meetings, representatives from different Scrum teams are present, usually the Product Owner or Scrum Master. The discussions cover work status, dependencies, obstacles, and issues related to synchronization and coordination.

Advantages of Scrum of Scrums

Scrum of Scrums has many advantages, including collaboration, information exchange, problem-solving, and more. Here are additional benefits of Scrum of Scrums:

Inter-team collaboration

Dissemination of information across Scrum teams through their representatives

Alignment of teams that have deviated from the course

Creating a platform for issue resolution

Application of Scrum of Scrums

Organizations typically use Scrum of Scrums as a technique when working on large projects and complex products. This technique is commonly employed as part of scalable Agile framewor

Do you know what Poka-Yoke is? It is one of the most effective methods of work standardization that can be used in any organization.

Lean Management adopted various principles and methods that originated as part of the Lean Manufacturing methodology, and Poka-Yoke became one of the most effective methods of work standardization, applicable in any sphere of production or services.

The idea used in this method, the prevention of errors and defects, is very versatile and has proven its effectiveness.

Meaning and Origin of Poka-Yoke

The term Poka-Yoke (ポカヨケ, poh-kah yoh-keh) was coined in Japan in the 1960s by Toyota industrial engineer Shigeo Shingo. Shingo also developed and formalized Zero Quality Control, a combination of Poka-Yoke methods to rectify potential defects and check the source to prevent defects.

Initially, the term was pronounced as “baka-yoke,” meaning “protection against foolishness,” but it was later changed due to offensive connotations. Poka-Yoke now means “error-proofing” or, more literally, the prevention (yokeru) of unintended errors (poka).

Poka-Yoke ensures that the correct conditions exist before performing a step in any process, primarily preventing the occurrence of defects. Where this is not possible, Poka-Yoke serves a detective function, eliminating defects at the earliest stage of the process.

Poka-Yoke is any mechanism in a lean production process that helps avoid mistakes. Its goal is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.

Examples of Poka-Yoke Application

In a broader sense, this is also a constraint defining behavior, like a step in a process that prevents incorrect work.

One of the most common examples is a driver of a manual transmission car having to press the clutch pedal (a process step – Poka-Yoke) before starting the engine. The interlock prevents unintended movement of the car.

Another example is an automatic transmission car with a selector that requires the car to be in “Park” or “Neutral” before starting.

They act as constraints defining behavior because there are actions that must be performed before the car is allowed to move. Over time, the driver’s behavior adapts to the requirements through repetition and habit.

Other examples can be found in childproof electrical outlets or a washing machine that won’t start unless the door is properly closed to prevent water leakage. These types of automations do not allow errors or incorrect operation from the very beginning.

In Summary

The Poka-Yoke technique is one of the most valuable gems in the crown of Lean Management. It is a way to ensure quality without the actual quality assurance process, primarily aimed at preventing defects.

Poka-Yoke can be implemented in any industry and has numerous advantages, the most important of which are:

– Helps get it right the first time
– Over time, makes errors impossible
– It is cost-effective

Errors are normal; just don’t repeat the same mistake again and again. To avoid repeating the same mistakes, specific checks or procedures need to be implemented, and that’s where Poka-Yoke techniques come in.