An urgent phone call
The call came from an executive at a top 500 company. The enterprise was an early adopter of Scrum and has been successful.
Later, in the hopes of further improving efficiency within the enterprise, the well-known ‘Scaled Agile framework’ was used.
“We immediately lost 30% of our productivity. Jeff Sutherland, you’re the founder of Scrum. You should be responsible for it. You should fix Scrum at Scale.” The voice came from the other end of the line.
Jeff was very surprised. He was immediately lost in thought.
In the past 10 years, the introduction of Scaled Agile has been a subject of great concern. Jeff has always believed that he created Scrum, constantly updating the Scrum Guide. He thought his work in this area was done. He spends a lot of time helping companies optimize their Scrum rollout to create business success. He also puts a lot of effort into compiling Scrum Patterns (The Best Practices).
He believed there were others who could do a better job of building a good organizational Scaled Agile framework on top of Scrum. After all, time waits for no one. In a blink of an eye, he had a full head of white hair, now more than 70 years old.
The call shattered his dreams.
Start working on solutions
He thought back to how he made the first Scrum transformation. Many people think that Scrum was developed between 1993 and 1995, so Scrum originated in 1993.
In fact, the first Scrum transformation, an organizational Scaled Agile transformation, took place in 1983. He’d taken a new job. “It was an offer my wife couldn’t refuse. After all, I was just a professor at a poor university at the time, and the pay was too attractive,” he laughed.
Being able to charge an “attractive” compensation naturally requires solving a “very problematic” situation. Soon after he got to work, he angrily reported to the CEO of the company and said, “Did you know that our projects keep getting delayed?” The CEO replied, “I am too busy to deal with complaint calls from major banks (the company’s key customer base) every day, but of course, I know!” Jeff replied, “Well, give me the division with the worst performance in the company. I’ll fix it my way. During this period, I will report my experience and progress of ‘working software’ every month. But at the same time, I ask you not to interfere with the operation of the division. Is that OK with you?”
At the peak of Agile popularity, this conversation is perhaps even more important than the Agile Manifesto of 2001. Because this conversation started Scrum and the first successful example of Scaled Agile at the organizational level.
Why can’t the existing methods solve the problem?
Jeff listed all the Scaled Agile models so far. He studied and compared them. He had an in-depth knowledge of these methods:
- What is the real problem being solved?
- Is the solution appropriate?
- The feasibility
- Difficulty of the implementation process
- Does it really fit the values of Scrum?
In the end, he didn’t find a solution that met his requirements in any of the “Scaled Agile models.” In particular, he emphasizes the great importance of practical data, and this is where he was least satisfied.
He knew it was his duty. He knew he had to fix this problem so that Scrum could be passed on correctly and scaled successfully.
Scrum@Scale
If you can’t Scrum, you can’t Scale. To truly scale Scrum, you must first know how to run Scrum. So before scaling:
- Scrum must be run properly
- There must be a way to build a strong Scrum team
- Must understand best practices for adapting Scrum
This is the first rule to scale Scrum. It is also the first principle of Scrum@Scale knowledge. The real goal of Scrum is not to give teams a workflow. Instead, the real goal of Scrum is to help teams deliver business value quickly and efficiently, outpacing competitors and gaining market share in an ever-changing market. This is Jeff’s design goal. If you master it, you can use Scrum correctly.
In other scaled agile models, Jeff felt that he failed to find the solution that met his requirements. So, he decided to start planning and designing Scrum@Scale; modeling the first successful scale-up agile approach in 1983 as the basis for reference.
Traditionally, large-scale agile had the difficulty of implementation, especially in a short period of time to deliver results. This is true every time a scaled Scrum model is implemented.
However, Scrum@Scale can quickly bring results to companies because of its practicality. Adding to that, Scrum@Scale uses hyper-productive patterns such as small and stable teams, Yesterday’s Weather, Interrupt Pattern, and other techniques to build hyper-productive Scrum teams without introducing extra overheads and wastes into the system.
Because of its remarkable effect, Scrum@Scale has also risen rapidly in the world and became one of the most popularized large-scale agile models globally.
We can now learn this online at Scrum@Scale.