Scrum as Designed: An Agile Framework vs. Scrum as a Delivery Methodology

In this post, I would like to share my thoughts and observations on two ways to approach what people call Scrum.

Scrum as Designed: An Agile Framework

The first approach is the one designed by Scrum—a robust framework that provides a very high level of business and technical agility. The Scrum Framework is designed and intended to operate in highly volatile and changing environments.

Scrum as a Delivery Methodology

The second way to view Scrum, which is not intended by the design of the Scrum framework, is as a methodology to organize work and delivery. This is what I see in many organizations and settings. The reason this is still called Scrum is that there is no other widely accepted name for it. That’s why there are deviations from the original Scrum. I don’t see anything wrong with this, but calling it Scrum can be confusing, as the original Scrum sets specific expectations for what it should be. SAFe has made a good branding approach to differentiate from the original Scrum and calls it SAFe Scrum, another thing that you can recall is Spotify Tribes.?

Professional Suggestion

My professional suggestion is to design your own delivery approach and give it your own name :)?

Key Inputs for designing a delivery framework:

• Changing Business Environment: Use the Stacy Model or Cynefin framework to determine this.
• Need for Business Agility: How justified is your need for business agility?
• PnL Analysis: Agility does not come free of cost; it has its own economic aspects. Consider this as well.

Key Factors to Design

Leadership and Management Practices

• How do you want to manage your portfolio?
• Do you want to manage or coordinate work across multiple teams?
• How do you want to manage/organize the work in a single team?
• How much autonomy do you want to provide to the teams? What is the decision-making process?

Delivery Practices

• How frequently do you deliver your product?
• What practices support your delivery style?

Feedback Loops

• Do you need to test business hypotheses and get market feedback?
• How frequently do stakeholders need to give their feedback?
• How frequently do you need to introduce new metrics to measure your products?

Organization Structure

• Do you need cross-functional teams, or is working in silos fine?
• What team topologies would work in your setting??
• How do you interact with non-IT teams?

By considering these factors, you can create a delivery approach that suits your specific business needs while maintaining clarity and avoiding the confusion associated with mislabeling methodologies.