Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Scrum@Scale: An Interview with Agile Manifesto Co-Author and Scrum Co-Founder Jeff Sutherland

Scrum@Scale: An Interview with Agile Manifesto Co-Author and Scrum Co-Founder Jeff Sutherland

This item in japanese

Key Takeaways

  • Jeff Sutherland, the founder of Scrum@Scale, leverages open source practices to make content and trainers available to people and organizations worldwide. By doing so, Scrum@Scale collects feedback from global transformations at scale and fine-tune the framework and the practices. Like Scrum, Scrum@Scale is an open source and adaptive framework.
  • The key success criteria, that must be attained before scaling, is to ensure that we’ve established an agile bubble that works well with one to 6 teams and ensure that these teams release software to production at the end of each sprint, while increasing their velocity and value to their customers at the end of each iteration.
  • Today, waterfall leadership is still a predominant global anti-pattern and most scaling frameworks support that. Executives keep thinking and operating in a waterfall fashion and deploy scaling frameworks to insulate themselves from agile delivery and from teams.
  • Scrum@Scale is one of the first scaling framework that allows leaders to become integral part of the cultural and execution transformation. Leaders organize themselves in an Executive Action Team (EAT) whose purpose is to “eat” organizational and product flow impediments. Leadership refactors the organization while in more mature transformational stages, teams become empowered to refactor the organization.
  • DevOps and continuous delivery have always been part of Scrum. In order to deploy to production faster and deliver greater quality value to customers, Scrum and DevOps engineering practices must integrate.  

Shaaron A Alvares: Jeff, thank you very much for doing this interview. I follow your activity and the adoption of Scrum@Scale and saw that you have been very busy setting up a certified trainer program, already adopted globally. You are also travelling to deliver conferences and to train certified trainer candidates yourself. Can you tell us more about what you are up to these days?

Jeff Sutherland: About 2 years ago, the Scrum Alliance leadership asked us to work with them on a formalized scrum scaling framework. We wanted a framework that would be as useful to the business and executives as to the people on the scrum teams. There are several scaling frameworks available, but none met what the Scrum Alliance had in mind to support organizational business agility. They also wanted this scaling framework to enable people to contribute to the model and help evolve it through shared feedback and case studies. The Scrum Alliance wanted this scaling framework to be open source, like Scrum itself.

Scrum Inc. negotiated with Scrum Alliance leadership, and at the beginning of 2018, we created and launched the joint-venture Scrum@Scale that offers training and certifies instructors.

Yes, I am definitely quite busy. I am the Chief Product Owner for Scrum@Scale content. I, essentially oversee and develop the curriculum for training instructors and create content for the Scrum@Scale guide. I deliver Scrum@Scale practitioner trainings all over the world and I have been supporting all the “Train the Trainer” certification sessions for the new Scrum@Scale instructors. We have almost 100 certified trainers worldwide today. As part of Scrum Inc., I also deliver Certified Scrum Master courses because clients and practitioners want to be trained by the founder. I am also invited to deliver talks and I still conduct research and write papers.

We are also finalizing two new books. I am reviewing one of them right now, The Scrum Fieldbook, by my co-author and the CEO of Scrum Inc. JJ Sutherland, which aims at helping executives and large organizations think about how to approach Scrum and how to scale Scrum across their entire organization. The book is available for pre-order and will publish in October. This book is a follow-on to our original book “Scrum: The Art of Doing Twice the Work in Half the Time”, published in 2014. The new fieldbook contains lots of case-studies about how people and organizations are applying and experimenting with the framework.

On a separate thread, with a group of practitioners, we have been working for the last 10 years on the Scrum Patterns book. The book is in final edits and will be out in Summer or Fall of 2019. The Scrum patterns are extremely important because we have found that, in order to get high performing Scrum, teams must implement the recommended patterns at the team level before they can begin scaling. People attempt to leveraging just a few practices, such as the daily stand-up event, but it doesn’t work well. We can’t get all the benefits of Scrum if we don’t implement all the recommended patterns. We’ve been teaching the patterns in our courses for many years and I am glad that the book is coming out because it documents some of that. It is important work and will help people succeed in their adoption of Scrum and Scrum@Scale.

Alvares: This is exciting Dr. Sutherland, and I am really looking forward to reading both books! I see you are leveraging open source and making the Scrum@Scale guide not only available to the public, but you are also allowing anybody to provide feedback and suggest improvements on GitHub. Then, the Scrum@Scale site contains multiple case studies presented by trained professionals. You also developed a global virtual Scrum@Scale community of practices, where trainers and coaches offer free advice and answer questions. And there’s also a Slack channel open to anyone.

What are, to date, the key benefits of open sourcing this content? Were you able to collect feedback and drive greater adoption of the framework?  

Sutherland: First of all, why open source? In 1995 Ken Schwaber and I formalized Scrum. I wanted it to be free and open source because I wanted to drive a much faster adoption globally. That worked very well for Scrum, so we scaled and improved this model for Scrum@Scale. As an example, for practitioners to become certified trainers, they need to submit a case study, and they need to be willing to make it open source. We already have almost a 100 case studies; not all are on the website, some are in production. We will have 1000 case studies posted, which will allow us to see all the various ways people and organizations have implemented and customized Scrum@Scale to their culture and organization. Like Scrum, it’s not a prescriptive model. The framework is adaptable and helps tune the organization iteratively. That is a significant difference compared with most other existing scaling frameworks that we wanted to showcase on our site through various case studies. The virtual coaching sessions also offer a forum  and creates a community where anybody can ask questions, share their challenges, quick wins and best practices.

Alvares: If I am not mistaken, you started the design and the first rollout of Scrum@Scale in 2014, and more recently in May 2018 you released the 1st iteration of the Guide available on the Scrum@Scale website. As you were experimenting with the framework, designing the practices based on feedback, what are, according to you, the key anti-patterns you observed in organizations, and how does Scrum@Scale address these?

Sutherland: You’re right, we started writing down a formalized version of the framework and we started rolling out Scrum@Scale training in 2014. Many people who were not getting high-performance teams with known scaling frameworks asked me to document how I repeatedly got high performance with Scrum@Scale: “Sutherland you need to write down how you’ve done it”. So, I went back to the first implementation and first prototyping of Scrum@Scale, which was in 1983 at a large financial institution running banking systems for 150 banks across the United States and Canada.

I was their CTO and VP for Advanced Systems. I started by getting few leadership members onboard and with their buy-in we implemented a different operating model using Scrum practices. I recommended executives to choose the business unit losing the most revenue and experimenting Scrum adoption with them. We initially created an agile bubble with the entire ATM Business Unit including sales, marketing, support, installation, and development and got it performing and operating really well. We institutionalized weekly sprint planning meeting where product managers met with the teams to prioritize the product backlog and address organizational impediments to flawless delivery. We got them to a point where they were deploying working features every Friday. We implemented a prototype not only of scrum but also of Scrum@Scale, and within 6 months it became the most profitable business unit in the bank. The bank decided to invest $20M to grow the business unit so we got more money to build a larger Scrum@Scale implementation.

The anti-pattern I observed at the time was waterfall leadership in non-Agile business units! All their projects were late, and to fix this management added more people onto the teams without planning, and requested additional detailed daily and weekly status meetings and reports, which only contributed to delaying the project even more.

The leadership situation hasn’t much improved today. I regularly attend Scrum Gatherings and Agile conferences. At the last couple of Scrum Gatherings, I asked, among an attendance of 200-300 people in the room: “How many of you are doing Scrum but with a management functioning in a waterfall fashion?” Almost a 100 % of the people in the room raised their hands. So, up until today, we still observe this anti-pattern. Managers and leaders want to receive all the usual waterfall reports and they still adopt scaling frameworks in a fashion that insulate them from teams and agility. This common situation causes an extreme amount of pain on people and organization. That’s the most common anti-pattern. Scrum@Scale is designed to change this situation and gives leadership an active role in the end to end transformation.

Alvares: As you mentioned, one of the biggest challenges that hinders large transformations is to bring the leaders of an organization onboard. Leaders are interested, they want the benefits of Agile, but they don’t feel that it’s for them. They also generally focus on doing Agile rather than becoming a more agile and nimble organization. They focus on the techniques rather than the mindset. What are the winning tactics you’ve used when faced with leadership resistance? How do you get them to attend Agile leadership trainings for example?

Sutherland: Well, first, we tell the executives: “you want the teams to be agile, but it doesn’t work very well if it’s just the teams.” This is nothing new. One of the primary reasons for project failure in the waterfall world for the last 50 years is the absence of executive support in fixing organizational issues. The same anti-pattern is happening with Agile projects.

With Scrum@Scale, we send a couple of coaches to do what we call a Go See. We had a team last year at Toyota who identified the top organizational issues that a healthy agile implementation can drastically improve. Then, we did a customized executive workshop, where we looked at the issues identified, prioritized them by most valuable and impactful, and identified how Scrum can fix them. With the leaders, we developed a transformation backlog and an implementation roadmap to tackle the top priorities. We then created a high performing Scrum bubble with few teams, a sort of proof of concept to show the entire leadership that it works, before scaling up.

We introduced the “Executive Action Team,” EAT, as an integral part of the scaling framework. The EAT “eats” impediments, which is their primary responsibility. They operate as a Scrum of Scrums team, are the final stop for removing impediments not handled at the teams’ levels and they are responsible for optimizing the product backlog, transparency and communication pathways across the organization.

Based on our experience, getting the executives involved right from the beginning is critical to a successful transformation. We don’t need all of them when we start, but it needs to be someone or some few that are committed to implementing agile in the organization and making it work. If they are not willing to do that, then they should stay with waterfall because it’s not going to be that much better.

Alvares: You presented at various conferences the concept of organization refactoring by leaders and then by teams. They both require significant change in management mindset. According to Scrum@Scale, in an agile and sustainable organization, opposed to a “Fragile” organization, trained managers, known as leaders, refactor organizations. Then, in the most mature organizations, referred to as “Anti-Fragile” organizations, it’s the teams who refactor the organization. Could you elaborate on that? How do we go from Agile to “Anti-Fragile”, what are the key differences, how long may that take to move from 1 state to another? What are the key mindset shifts needed to happen?

Sutherland: We found over and over again that, in order to maximize production against the product backlog, we want the teams formed and operating in a way that’s going to make it easy for them to delivery quickly. As an example, at LEGO, the management spent 6 months deciding for a large program who the teams should be and how they should be structured. Then, they applied Scrum and it didn’t work. They hired Henrick Kniberg who put all the developers in a room for a morning. Product owners presented the product backlog and asked everybody: “what should the teams be?” In a couple of hours, people figured out how they should organize, and it worked immediately. You need to get the right team formation behind the right backlog, and the right people on the right team. Teams needed to be cross-functional and feature oriented as much as possible. Getting input directly from them is critical to be successful.

In most organizations, traditional waterfall management decides on team formations and approaches scaling frameworks as a mean of insulating themselves from Agility. Organizational refactoring purpose is to tune, and potentially restructure the organization in order to continuously protect the flow of value and eliminate organizational debt.

In “agile maturity states” managers, now called leaders, fully empower teams to self-organize behind product backlogs. Leaders (the managers) become accountable for refactoring the organization to best support production enablement and business agility.

In “anti-fragile maturity states”, the teams set product strategies, provide product directions and refactor the organization to maximize the flow of value. Leaders support and enable continuous improvements as requested by the teams. There are still too few organizations which reached these levels of maturity.

To summarize, we want to create an initial backlog and form the teams around that backlog. That’s the basics of Scrum@Scale. Now, the goal is to enable twice the value delivery in half the time at scale, and we can’t do that unless first - you can apply Scrum really well, and unless second - you can get the organization aligned to deliver at scale. To achieve scalability, no matter how many teams you have, you need to increase production. In the waterfall world, the more people we add onto the team, the slower we get, that’s Brooks Law and that’s a waterfall anti-pattern. To avoid that anti-pattern, we need to redesign the organization that will best scale. If you double the number of teams, production should double as well. This is hard to do.

Alvares: I’m aware that Scrum and Scrum@Scale can also be applied to non-software development industries. But in the software development industry, how does Scrum and Scrum@Scale integrate with DevOps engineering practices? Today, most organizations adopted or are aggressively adopting DevOps to engineer their release infrastructure, and also for the many cultural benefits it offers. What are the synergies between Scrum@Scale and DevOps, how do they work together?

Sutherland: Let’s go back to 1983, where I implemented the first Scrum@Scale prototype at a bank. If you recall, we delivered working features every Friday afternoon: this means that building, testing as well as deployment had to be automated. That’s what today we call DevOps. DevOps means that ultimately there are no humans involved through building testing and deployment. And removing manual processes has always been the primary goal of Scrum, right from the very beginning of Scrum.

In 1995, I was working at a company that had just gone public. One of the first things we did was to set up the teams to deploy every week: we moved the server out of the server room and put it in the development area to support continuous deployment. DevOps has always been part of the whole idea behind Scrum. At that time, we were formalizing the Scrum framework and practices and we wanted these engineering practices to actually be an integral part of the definition of Scrum and Scrum Guide. We were working with Ken Beck, founder of Extreme Programming. With Beck, we agreed that he would focus on the engineering practices, while we would focus on team, product backlog and organizational practices. But ever since its original inception, in 1983, the best Scrum implementations have always included Extreme Programming and DevOps practices.

DevOps largely became an important concept today because of the tool vendors develop to achieve full automation of build, test deploy and operational support. But to achieve technical excellence, teams first need to be agile. DevOps is the tooling for automating deployment, although it introduces significant cultural benefits.

Later in 2005, I wrote an article titled “The Future of Scrum: Parallel Pipelining of Sprints in Complex Projects” that describes Scrum@Scale and continuous deployment. This article is the first ever published on continuous deployment and automated operational support.

Alvares:  Why are companies still hesitant to invest in full DevOps automation, in full stack developers’ recruitment and in organizational change, especially when they face so many complex integrations? I worked in data-driven environments at Microsoft’s Enterprise Commerce (ECIT) and Global Volume Licensing, at Expedia with their Booking data engineering teams, and with several companies that deal every day with cross-domain and complex applications and data integrations. Instead of investing in their release pipeline, they hire more people with little to no automation skills, they duplicate and silo roles, and develop additional manual processes.

Sutherland: We talked about leadership resistance, the absence of commitment or training. The management of waterfall organizations, because they’ve been doing waterfall for the longest time, which is very high risk and lead to many failures, fear that agile is going to be even riskier. Some leaders never had any training, never read any papers on agile or  DevOps and therefore don’t understand that, well implemented, DevOps and agile transformations increase the flow of value and revenue while making defects go way down. We have extensive industry data showing that agile significantly reduces risks. The fact that some leaders haven’t read a single research publication showing what goes on with agile is a major malfunction in the global industry.

The second aspect, and this is important, relates to automation. David Rico has written groundbreaking papers and a book showing the return on investment for automating the entire build, test and deployment pipeline. He demonstrated that the return on investment is over 72,000 percent. Executives who still consider agile as being risky and automation costly will lose their business to companies that continuously invest in their internal release technology and full DevOps automation. Amazon that has 3,200 scrum teams delivering a new feature to market more than once a second, gets 72,000 dollars back for every dollar they invest in automation.

To illustrate this, when Amazon started offering loans in Germany, the largest bank in Germany shared with me that they no longer could compete and had to get out of this market. “Amazon can turnaround a loan in minutes. They can assess your risks and give you a loan within minutes, when it takes us weeks: we cannot compete.” So, managers of these big legacy companies need to wake up or they’re going to get “Uberized” or “Amazoned.” Once Uber or Amazon take away their business, they don’t get it back.

About the third aspect you mentioned regarding complex cross companies integrations, there is a really interesting case study on this very issue on the Scrum@Scale website. A company in Italy, specializing in smart homes IoT, shows how multiple teams, some local, some remote and 3 external vendors scaled using Scrum@Scale while eliminating painful dependencies between hardware, software, and suppliers. In about 20 sprints, they increased their production 18 times. It’s basically Scrum@Scale implementation but across multiple organizations.

All of this is driven by good Scrum at the bottom, Scrum@Scale at the organizational level, pulling people together to deliver products much faster, of much higher quality, with much lower risks.

Alvares: As you implement Scrum@Scale within organizations and as you gather feedback, you are truly changing the way leaders think and approach work, especially executives because they drive strategy and reports. Did you come to reconsider most common Agile metrics? Which ones should we use, which ones should we bury because they are no longer relevant?

Sutherland: Few years ago, I met with Cisco’s management team. They had about 1000 Scrum teams in their Silicon Valley operation. They showed me the data of their velocity and none of their teams were improving. I told them: “They’re not improving Scrum@Scale delivery because it’s not scaling right”. Cisco’s management immediately decided to make a few changes: first, they trained all their scrum masters; and second, they ensured that teams were investing in continuously improving.

The first important metric is the team velocity. It’s important to understand how it works, how it’s tied to process improvements, and how it’s improving.

The second important measure of success is the happiness metric. I run my company using Scrum, and we use the happiness metric. Are people happy about the way things are working? If your velocity is going up and happiness is going down, you’re going to crash and burn, right? What you want is to keep happiness very high and velocity improving.

The third metric that is very important, and that nobody tracks, is the revenue. If teams are delivering lots of points, how much revenue does the product owner gets for every point. We want that number high and increasing. We also want to measure the performance of the product owners. If we have the teams doubling points and the product owner doubling revenue per point, you get 400% more revenue.

But the metric, I am very focused on today, and we just released a paper in March 2019 on this topic, is process efficiency. One of the problems with velocity is that we can’t compare across teams. As we were working with Toyota last year, we decided to try some of the metrics they use for their production system. Process efficiency is the ideal work time divided by the actual clock time. Let’s say a story would ideally take a day to deliver but it takes 20 days to get it to Done due to various wait time, the process efficiency would be 1 day over 20 days, which is 5%. For most Scrum teams, the process efficiency is less than 10%. General Electrics’ managers, as an example, told us right away what their process efficiency was: 5%. If you increase that process efficiency number, you get tremendous improvements in production. The beauty of process efficiency is that it is comparable across teams. Also, according to the definition of lean, process efficiency should be at least 25%, so most scrum teams are not lean and that’s a problem. I am currently working with clients at the team level helping them analyze their process efficiency and bring it up. Some teams were able to bring it up within a single sprint and double their velocity in 1 sprint just by focusing on process efficiencies.

I’ve given you 3 metrics that we use all the time, velocity, happiness, and revenue per point or value delivery per point for the product owners. Today, I am really focused on improving process efficiency: how can teams deliver as the best teams deliver at Toyota.

Alvares : Dr. Sutherland, what you have accomplished in the agile industry is colossal. You have introduced new ways of thinking, working and collaborating that’s impacting millions of people worldwide. With that, the intensity of your activity is very impressive: what time do you wake up in the morning and what do you eat for breakfast?

Sutherland (Laughing): I start my days with a bulletproof coffee because it increases your metabolism as well as causes you to lose weight or maintain a stable weight. It helps you get started in the morning. And throughout the day, I eat a high protein and high-fat diet, like the keto diet, which keeps my energy up, and keeps me moving.

I can tell you though, the thing that really keeps me going truly is how many great companies and teams are implementing Scrum@Scale successfully. I was speaking with a division manager at Intel who has today 500 Scrum teams, and he shared that “in the last 10 years of using Scrum and Scrum@Scale, we have increased production 18 times”. This is what Scrum was created for. It’s celebrating and sharing these success stories that truly keeps me going!

Alvares: A question that I asked when I interview scrum masters: which Scrum event (ceremony) do you prefer and why?

Sutherland: It’s hard to pick one, but the most important thing to do is to get the backlog into a high ready state. And right after that, it’s the retrospective. We recently clarified the objectives of the retrospective in the Scrum guide: the retrospective is designed to identify a process improvement that’s implemented in the next sprint. If you can get your backlog ready and you can execute improvements every sprint, you will have an awesome Scrum team.

About the Interviewee

Jeff Sutherland is a former US Air Force “Top Gun” and the co-creator of the Scrum framework. This model, developed in 1993 and formalized in 1995 with Ken Schwaber, has since been adopted by the vast majority of software development companies around the world. Sutherland is a leading expert on how the framework has evolved to meet the needs of today’s business. Realizing its benefits are not limited to software development, he has adapted this strategy to several other industries including finance, healthcare and telecom. Scrum and Scrum@Scale are now widely adopted and create hyper-productive development teams. As founder and Chairman of Scrum Inc., creator of Scrum@Scale, Senior Advisor and Agile Coach to OpenView Venture Partners, Sutherland train executives and shares agile best practices with organizations around the globe.

Rate this Article