lighttangent

Loading

Blog

Agile

What is Spotify agile framework?

Spotify was first introduced in 2012 by Henrik Kniberg and Ander Ivarsson. Henrick Kniberg mentions that Spotify is not a framework or a model but rather it is just an example of how the company works. This was implemented in the company Spotify and they have scaled it to over 30 teams in 3 cities.

Terminologies in Spotify agile framework

  • Squad – The team is called a Squad. It is similar to a Scrum team. A Squad is an autonomous team with direct contact with stakeholders. Every Squad has a Product Owner who is responsible for prioritizing the work. A Squad has access to an Agile Coach who helps them in the way of working.
  • Tribes – A group of teams that works in related areas is called Tribes. Each tribe has a tribe lead who is responsible for providing the best possible habitat for the squads within that tribe. Tribes meet regularly and share knowledge, tools, and techniques.
  • Chapters – A Chapter is a small family of people with similar skills and working with the same general competency area. For Example – All the UI/UX engineers will report to one manager. Every Chapter has a Chapter Lead and the Chapter members report to the Chapter Lead. A Chapter Lead is part of a squad and is involved in the daily activities of the squad.
  • Guilds – A Guild is a more organic and wide-reaching “community of interest”, a group of people that want to share knowledge, tools, code, and practices. For example, the Agile Coach Guild, and Product Owner Guild.
  • System Owner – For Ownership of the System, a pair of system owners ( 1 from development and 1 from Operations) are assigned and they are responsible for any changes to the systems in terms of system stability, managing operational risks and releases.

Conclusion

Spotify is neither a model nor a framework, it is a way of working that has key structures, practices, and mindset that enable Spotify to perform. According to Henrik Kniberg, Spotify was valuable to the company at that time. It is a unique instance of Scrum@Scale suitable for that moment. Spotify no longer uses the way of working that was established as this is ever-evolving. Spotify is not a scaling framework, hence do not consider it for organizational transformation.

Source – https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

Agile

What is scrum@scale?

Definition of Scrum at Scale

Scrum@Scale is a framework to deliver results across any organization. It is a lightweight, adaptable framework that can be customized per the organization’s context. It is a component-based architecture that allows companies to build their organization like they build their products.

As per the Scrum@Scale guide, Scrum@Scale is a lightweight organizational framework in which a network of teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value. These “products” may be physical, digital, complex integrated systems, processes, services, etc.

Scrum@Scale helps an organization to focus multiple networks of Scrum Teams on prioritized goals. It aims to achieve this by setting up a structure that naturally extends the way a single Scrum Team functions across a network and whose managerial function exists within a minimum viable bureaucracy (MVB).

Why Scrum at Scale

Scrum, as originally outlined in the Scrum Guide, is a framework for developing, delivering, and sustaining complex products by a single team. Since its inception, its usage has extended to the creation of products, processes, services, and systems that require the efforts of multiple teams. Scrum@Scale was created to efficiently coordinate this new ecosystem of teams. It achieves this goal through setting up a “minimum viable bureaucracy” via a “scale-free” architecture. Dr. Jeff Sutherland developed Scrum@Scale based on the fundamental principles of Scrum, Complex Adaptive Systems theory, game theory, and object-oriented technology.

Scrum@Scale – How does it work?

  • Scrum at Scale – Team Level (Follows Scrum guide and have a Scrum Master, Product Owner and Development Team). This is for a single team.
  • Scrum of Scrums – A dynamic group that includes representatives from Scrum Teams. The recommended optimal number of teams for Scrum of Scrums is 4 or 5.
  • Scrum of Scrum of Scrums – More than one Scrum of Scrums may be needed to deliver a complex product; a Scrum of Scrum of Scrums is formed out of multiple Scrum of Scrums. To facilitate the daily scrum and retrospective, Scrum at Scale recommends a role called Scrum of Scrums Master (SOSM), similarly a Chief Product Owner is required to facilitate the Sprint Review and Backlog Refinement.
  • Executive Action Team – This team is formed for Scrum of Scrum of Scrums. It comprises of individuals who are empowered, politically and financially to remove impediments. This team coordinates multiple Scrums of Scrums and interfaces with any non-agile parts of the organization.
  • Executive MetaScrum – This team is formed for Scrum of Scrum of Scrums. A forum for leadership and other stakeholders to express their preferences to the PO Team, negotiate priorities, alter budgets, or realign teams to maximize the delivery of value. At no other time during the Sprint should these decisions be made.

Components of Scrum@Scale

Scrum at Scale framework is divided into the Scrum Master Cycle and the Product Owner Cycle. The “how” falls under the Scrum Master cycle and “what” falls under the Product Owner cycle. For effectiveness, the Scrum Master Cycle is supported by an Executive Action Team (EAT) which focuses on how they can get it done faster and the Product Owner Cycle is supported by an Executive MetaScrum (EMS) forum which focuses on what is produced by the Scrum of Scrums.

Roles at Scrum@Scale

The two roles that are specific for scaled agile in Scrum at Scale are as follows –

  • Chief Product Owner – Sprint Review and Backlog Refinement are facilitated by a Product Owner Team guided by a Chief Product Owner (CPO).
  • Scrum of Scrums Master (SOSM) – Daily Scrum and Retrospective are facilitated by a Scrum Master for the group, called the Scrum of Scrums Master (SoSM).
  • The remaining accountabilities (Scrum Master, Product Owner) are part of the Scrum team. A Scrum Master along with facilitating the daily scrum and sprint retrospective for a team can also facilitate a Scrum of Scrums.

Conclusion

In order to begin implementing Scrum@Scale, it is essential to be familiar with the Agile Manifesto and the 2020 Scrum Guide. A failure to understand the nature of agility will prevent it from being achieved. If an organization cannot Scrum, it cannot scale. Scrum@Scale is a delivery method agnostic. It provides structure through a minimum viable bureaucracy (MVB) in the form of an Executive Action Team and Executive MetaScrum forum.

Source – Scrum at Scale guide

Tip – Read the Scrum@scale guide for more information – Scrum@Scale Guide

Agile

What are Agile Coach skills?

Agile Coach is a leadership role and it requires multiple skills however the skill and experience requirements differ from Organization to Organization.

Below is a list of skills required for an agile coach (The list is arrived at by analyzing 9 agile coach job descriptions across various industries. The skills are not in order and there are overlaps as the terms are used by various companies across organizations)

  • Agile Development
  • Continuous Improvement
  • Problem-Solving
  • Lean Portfolio Management (LPM)
  • Stakeholder Management
  • Conflict Resolution
  • Coaching ( Individual and Team Level)
  • Executive Coaching
  • KPI/Metric Monitoring
  • Organisational Transformation
  • Backlog Prioritisation
  • Decision Making
  • Software Development Lifecycle
  • Growth Mindset
  • Risk Management
  • Inclusive Leadership
  • Collaboration and leadership
  • Strong communication and facilitation
  • Proactively acts to address obstacles
  • Implement positive change
  • Focus on results – creatively solves problems to ensure goals and objectives are met or exceeded
  • Deep understanding of Agile principles, values, and methodologies, with expertise in Scrum and Kanban
  • Culture Transformation
  • Program Management
  • Lean Management
  • Inclusive Leadership
  • Previous experience as a collaborative leader
  • Must have excellent analytical, organizational, and interpersonal communication skills
  • Must be detail-oriented and results-oriented with strong problem solving and time management skills
  • Must have proven experience in working and communicating effectively in cross-functional teams
  • Must have strong teamwork qualities with the ability to establish and maintain solid working relationships with peers, vendors, senior management, and other departments 
Agile

What is Disciplined Agile Delivery (DAD)?

Definition – Disciplined Agile Delivery (DAD)

It is a toolkit that contains agile strategies that will guide you to the best way of working (WoW) based on your context. A team/organization is more aware of its context, hence choosing the agile strategies that best suit its context and fit for purpose for your organization. One of the important points to know about DAD is that it comes from the Project Management Institute (PMI). PMI acquired the DAD Agile Delivery in 2019 to get a foothold in the world of agility. Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise by IBM software engineers Scott Ambler and Mark Lines. This is NOT a framework, unlike other frameworks in agile like Scrum/Kanban.

Foundation of Disciplined Agile Delivery (DAD)

The Foundation is based on the following –

The mindset of Disciplined Agile Delivery –

The mindset is based on the freedom to choose practices suited for the team’s context as per PMI.org, Disciplined Agile Delivery (DAD) is based on three pillars (1) Principles (2) Promises and (3) Guidelines.

People – The way you collaborate and how you are organized in your teams or enterprises can impact your ability to deliver value. Disciplined Agile Delivery has two roles – Primary and Secondary. Primary roles are commonly found on DAD teams and supporting roles are there to help the primary role takers in delivery.

Agile – Agile is the way that you choose to think and act.

Lean – Lean is an approach that produces value for customers quickly through a focus on reducing delays and eliminating waste which results in increased quality and lower cost.

Serial – Serial captures the essence of the strategy, to work through a progression of phases or stages in a linear manner. DA principle Be Pragmatic supports using whatever approach or life cycle necessary to achieve the desired outcomes. For all life cycles, DA provides a robust set of choices and tools to help teams and organizations be more effective.

WoW ( Way of Working) – Every team is unique and the context is different. The Disciplined Agile® (DA™) tool kit enables teams to choose and later evolve a fit-for-purpose way of working (WoW).

Source – pmi.org

Adoption of Disciplined Agile Delivery (DAD)

Similar to Kanban, Disciplined Agile Delivery (DAD) recommends starting from the current state and then focusing on continuous improvement.

Conclusion –

Disciplined Agile Delivery (DAD) is a tool kit from the house of PMI. It is like a buffet lunch and PMI provides you with the buffet, it is up to the team to customize and decide what works for them. It is prescriptive in terms of the buffet provided by PMI and you have to select from the buffet menu on the other hand it gives the freedom to choose the item as per your interest.

Learn about agile scaling frameworks- What are the agile scaling frameworks?

Agile

What is LeSS ( Large Scale Scrum)?

LeSS framework was created by Bas Vodde and Craig Larman. LeSS or Large-Scale Scrum is about taking Scrum and applying the Scrum concepts across multiple teams. LeSS is relatively small and simple. LeSS focuses on the root causes of organizational weaknesses when scaling. In short, LeSS is a scaled-up version of one-team Scrum.

Why did LeSS start?

As per Craig Larman, Frameworks with a lot of definitions and “prescriptiveness” don’t work in terms of large-scale adoption. They aren’t contextual enough. They inhibit empirical process control (a key Scrum principle) and the unique learning and exploration that must take place. Development groups (and the work of development) are just too varied for anything like a detailed highly-defined framework or process, or much of a standard recipe. 

LeSS Structure

LeSS recommends that organizations focus on structures first before rolling out LeSS. LeSS consists of set of principles and experiments. It also provides a framework with rules.

Types of LeSS Frameworks

There are two types of LeSS Frameworks – LeSS and LeSS huge. LeSS can be applied to up to eight teams whereas LeSS huge is applicable for more than 8 teams.

Components of LeSS

  • A Single Product backlogs
  • One Definition of Done for All Teams
  • One Potentially Shippable Product Increment
  • One Product Owner
  • Multiple Cross-Functional Teams (With Single no specialist team)
  • One Sprint

Conclusion

LeSS like Scrum is a framework suited for Product development. If there is no Product, there is no Scrum similarly if there is no product there is no LeSS. There will be a school of thought of applying LeSS to a Non-Product team, however, the results will not be great.

Source –

Learn about agile scaling frameworks- What are the agile scaling frameworks?