Scrum Inc. is the premier provider of Scrum training and consulting. We help companies and individuals dramatically increase productivity and quality. Follow this blog to get information on Scrum training, consulting and much more.
Frequently there are great debates about the use of the Fibonacci sequence for estimating user stories. Estimation is at best a flawed tool but one that is necessary for planning work.
User story estimation is based on Department of Defense research in 1948 that developed the Delphi technique. The technique was classified until the 1960’s (there are dozens of papers on the topic at rand.org). Basically, the Rand researchers wanted to avoid the pressure towards group conformity that typically led to bad estimates. So they determined that estimates had to be done in secret. Initially, the estimates would be far apart because people had different perceptions of the problem so they would have them talk about highs and lows after estimating in secret, then estimate in secret again. At Rand Worldwide you can read the original papers that demonstrate convergence.
Rand researchers then studied the effect of the numbers estimators can choose and found a linear sequence gave worse estimates than an exponentially increasing set of numbers. There are some recent mathematical arguments for this for those interested. The question then--if you want the statistically provable best estimate--is what exponentially increasing series to use. The Fibonacci is almost, but not quite exponential and has the advantage that it is the growth pattern seen in all organic systems. Why does the Fibonacci sequence repeat in nature? So people are very familiar with it and use it constantly in choosing sizes of clothes. For example, tee shirt sizes are Fibonacci. Since some developers are averse to numbers (a really strange phenomenon for those working with computers) they can use tee shirt sizes and their estimates are easily translated to numbers.
Microsoft repeated this research in recent years in an award-winning IEEE paper. As a result, Microsoft has abandoned hourly estimation on projects. See Laurie Williams, Gabe Brown, Adam Meltzer, Nachiappan Nagappan (2012) *Scrum + Engineering Practices: Experiences of Three Microsoft Teams. *IEEE Best Industry Paper Award, 2011 International Symposium on Empirical Software Engineering and Measurement.
So the Agile community has converged on the Fibonacci as the sequence to use. Unfortunately, many agile teams do not use it properly and try to get everyone to agree on one Fibonacci number which gives you mathematically and experientially provable bad estimates through forced group conformity. This is the very thing the Rand researchers invented the Delphi Technique to avoid.
Over and over again, researchers have shown that hourly estimates have very high error rates. This is true even if the user is an expert. It’s the tool that’s the problem. If you want to practice based on evidence, relative size estimates simply deliver a much more accurate estimate.
The first Scrum team finished it’s first Sprint 24 years ago last week. My goal then, and it continues to be, was high-performance teams. In the decades since I have been solely focussed on that. How do we enable people to accomplish more, live better lives, and fundamentally change the trajectory of their success?
Millions of people globally are now meeting every day for their Daily Scrum. It is astonishing how Scrum has reshaped the world of work across many disciplines and beyond software. The Standish Group data shows that Agile projects are three times less likely to completely fail than waterfall projects and four times more likely to succeed. This is what is driving companies to want to become “Agile.”
Currently, the existential threat to Scrum is “Bad Scrum.” So I have spent the last few years codifying the best-practices for scaling scrum and thinking about what works and what doesn’t and put a name on it: Scrum@Scale.
Scrum@Scale is the framework for organizations to iteratively develop the best way for Scrum to work in their context. So I’ve kept it simple. The Scrum@Scale Guide is just a few pages. Just like with Scrum, and the Scrum Guide, it’s free. You don’t need to ask my permission. Grab it, use it, and share your knowledge and your experience.
Each and every Scrum team is different, even teams within the same organization. They have their own culture, ways of working, successes, failures, their own context. But they follow a common framework. And within that framework they iteratively develop novel solutions to the problems they are trying to solve.
To spread good Scrum, and to have the impact we want to have on work, we need more people than just Scrum Inc. teaching it. We had a pilot last year with Angela Johnson of the Co-Lead Team and learned a ton. We are posting her classes on the Scrum Inc. website as well as scrumatscale.com. Last week, we graduated our first class of Scrum@Scale trainers. There are 17 of them.
You can read about the process of becoming a trainer including all of the qualifications and benefits on our site scrumatscale.com. I do want to point out one thing we do require. To become a Scrum@Scale trainer you have to have scaled Scrum and you have to submit a case study of that work. What did you learn? What was hard? What worked? And that case study has to be shared. Not just with Scrum Inc. Not with other Scrum@Scale trainers. With the world. We want the world to hear about our trainers’ victories, and for those stories to become reference points in a global conversation.
We’ve already had hundreds of people take our Scrum@Scale classes, many of them coaches and trainers. The consistent feedback we’ve gotten is that this is a codification of the best scaling practices they had been applying for years. We want to foster a community where the people and organizations transforming themselves learn from each other.
We’ll be posting all of the case studies from this first trainer class in the next few weeks at scrumatscale.com. We want to create a living library of the myriad ways to effectively scale Scrum within a common framework. A library that is there whether you are at a Fortune 100 company in the US or at a hyper growth startup in Hyderabad.
As you might know, I stepped down as CEO of Scrum Inc. in January. One of the main reasons is so I could focus my efforts on spreading Scrum and Scrum@Scale to as many people as possible whose lives will be better for it.
Watch the Full Video of the Scrum Guide Revision Webinar
Please post your comments or questions related to the webinar on this page so that responses are transparent and shared with everyone.
The Scrum Guide reflects the definition of the Scrum framework as designated by its co-creators Dr. Jeff Sutherland and Ken Schwaber. The document, written in 2010 is the single definitive embodiment of Scrum. The Scrum Guide covers Scrum’s roles, events, artifacts, and the simple rules that bind them together into this powerful, light framework.
This unique Guide, like any Scrum practice itself, is regularly iterated through inspection and adaptation by both Jeff and Ken based on feedback from Scrum practitioners, the Scrum Guide User Voice, and their own first-hand experience launching Scrum practices in Fortune 100 companies.
This year the co-authors have met and provided revision and edits to the Guide to allow Scrum to maintain is place as the vanguard for tackling any project.
In 2009, I was in Palo Alto doing Scrum Training and I decided to test drive a Tesla Roadster with my business partner and fellow trainer Gabrielle Benefield. Right after the drive, I put in an order for a brand new red Roadster. It is the best product I've ever invested in. Check out comments in Quora.
What's Happening at Tesla?
After buying the Roadster, Elon gave early Roadster enthusiasts "Friends and Family" stock at $17. The stock has appreciated to over $350 in 2017. I had enough stock to pay for my Roadster and it made all future Tesla cars essentially free. While it is too late for everyone to buy a Roadster and get in on the IPO it is not too late to buy a Model 3 that "drives like a Porsche and costs like a Prius". It is even cheaper today to put solar on your roof. The payback in my state is about four years (electricity is then free for 20 years at least and it increases the value of your house) and that doesn't count the cost savings on never having to buy another gallon of gasoline.
After three versions of the Model S, and my order for the Model 3, I was eager to see what Tesla was doing with Scrum. There were many people from Tesla in the classes, some passionate advocates for more and better Scrum. Tesla could certainly use more Scrum. They are now entering what Elon calls "production hell", trying to fill 500,000 orders for the new Model 3 as fast as possible.
Currently, everyone is working hard and under stress. With more and better Scrum they could turn "production hell" into "production nirvana." At another auto manufacturer we worked with, a team of 200 that could not deliver anything was cut to a team of 20. That team shipped a critical production system in just a few sprints. Tesla needs that!
You Need "True Scrum" not "California Agile"
To deliver with 10% of the staff, you have to do what the Japanese call "True Scrum", the Scrum of the grandfathers (Takeuchi and Nonaka) and fathers of Scrum. There is far too much "California Agile" in Silicon Valley, where developers do whatever they want and so you get "whenever" delivery.
At Tesla, we taught the Scrum Inc. pattern based approach to Scrum. In this approach, there are at least 11 ways to double your velocity in your next sprint. This way of implementing Scrum resonated with the class participants, some of whom were from a rocket factory not far from the Tesla plant. After we finished the class at Tesla, they asked me to present key lessons learned to their Scrum teams at the factory.
The Rocket Factory
We visited the stealth mode rocket factory after the Model 3 launch at Tesla. The CEO is running the company 100% Scrum for all departments (departments are teams or sets of teams). They are committed to building and launching rockets in 10% of the time of SpaceX. We talked to their whole development team about the key lessons we teach in the Certified Scrum Master course on how to deliver "Twice the Work in Half the Time."
Silicon Valley Agile Leadership Network
As a bonus to the Tesla courses, I attended a user group meeting for the Silicon Valley Agile Leadership Network at Computer Associates in Santa Clara. There we talked about how to scale Scrum without breaking Scrum. 50% of the audience said they were doing Scrum in a company where the management was still using Waterfall. Agile was viewed as a running wheel you put in the development area to make the developers run faster. All the same command and control Waterfall reports were required. A scaling framework was often chosen to keep the managers safe from Agile and protect the hierarchical organization, rather than refactoring the organization, incentive plans, and job descriptions to achieve higher performance. I talked about how the best companies do Scrum where the management becomes Agile and directly works on and supports Scrum teams.
In December of 1993 my father, Jeff Sutherland, gathered a team of people and asked them to go on a new journey with him, a new way of working. A way he had started developing forty years prior while a cadet at West Point, developed through years as a fighter pilot, as a professor seeking new treatments for cancer, and leading six different technology companies. A way of working rooted in respect for people, a way to unleash human potential, a way that delivered results faster than anyone had ever thought possible. A way with the unlikely name of Scrum.
That first Scrum Team had no idea they would ultimately reshape millions of lives the world over. This January marks twenty-four years since that first Sprint. Scrum Inc. was founded just twelve years ago with a clear mission, as my father put it: “To fundamentally alter the way of work; to make the world a better place by building teams of better people.”
That mission strikes me as more urgent today as I begin my first day as CEO of Scrum Inc. The change we have the extraordinary fortune to be living through is re-writing the social compact, changing how people live, relate to each other, think about ourselves and our communities, what we are capable of, and who we want to be and possibly can become. We live in a time of unprecedented possibility. Fewer people live in poverty now than at any other time in human history. Fewer children die. Fewer wars are fought. Fewer people live under tyrants.
It is easy to focus on disruption and danger, fear and fatigue. Those are real. And our path as a species is far from set or certain, but I believe deeply that Scrum, and Scrum Inc. can help put a thumb on the scale for a better world.
Last year Scrum Inc. worked with Teams in sixteen countries and on every continent save Antarctica. We help organizations in domains covering every field of human endeavor, software, data science, banking, defense, manufacturing, automotive, oil and gas, power and water, space, aviation, retail, robotics, automation, media, chemicals, pharmaceuticals, health care and transportation. We have grown dramatically, gathering together some of the finest minds and bravest thinkers on the planet. We have also failed quickly, learned mightily, and had dramatic success.
As the founder of Scrum Inc. Jeff’s presence will continue to be felt daily. He will continue to teach and write, research, speak, and develop new ideas. He will continue the work of sharing Scrum@Scale to a community well beyond Scrum Inc. and engage with leaders globally. While he will no longer be CEO of the company, he will instead now have the most important title in Scrum: Team Member.
We at Scrum Inc., through more than twenty years continue our commitment to Jeff’s vision and legacy of better people, better teams, and a better world for our customers, our partners, and each other.
Jeff Sutherland presented a management keynote in Germany at the Management 3.0 Stammtisch on 4 December 2017. Jürgen Ditmar started the Stammtisch meetup 5 years ago after starting Management 3.0 classes because participants wanted to continue the discussions in the class and to learn and exchange more ideas.
The Stammtisch takes place every month (beside August). It’s an open and free event for everybody interested in the perspective of new leadership and management and it has initiated spin offs in Frankfurt, Stuttgart, and Nürnberg.
Based on the ideas of Management 3.0/Managing for Happiness it’s all about how to develop, manage and lead a healthy agile and modern organization. The format differs: sometimes Jürgen runs workshops (e.g. Agile games, non-violent communication, Nexus, LeSS, Scrum@Scale), or has discussions (5 Dysfunctions of a Team, M3.0 Examples) or hasspeakers (Jeff Sutherland, Craig Larman, Jurgen Appelo, etc.)
Management 3.0 - initiated by Jurgen Appelo - is a book (leading agile developers – develop agile leaders), mindset, training, network combined with an ever-changing collection of games, tools, and practices to help any worker to manage the organization. At the moment there are more than 200 M3.0 facilitators hosting trainings in 136 countries and speaking 20 languages. With close to 100 trainings Jürgen is the most experienced trainer worldwide.
Jeff has spoken at several Stammtisch events in the past. The 53rd Stammtisch was standing room only with people spilling out into the hall. An energetic discussion was had by all with particular emphasis on the Role of Management in Scrum and Scrum@Scale.
Below is a partial transcript of the Q & A from the "Scrum at Scale: The Path to Agility" presentation that I delivered to the International Institute for Learning, Inc. The questions and brief answers selected for this post provide answers to common questions about whether or not Scrum can work across various industries and organization types.
What we know is that Scrum is being implemented across all domains. Scrum works wherever Scrum is well practiced and well supported. If you are interested in increasing business value and business agility, decreasing waste and time-to-market, or future-proofing your organization, you should be interested in Scrum.
Q: Hello. Thank you for the opportunity. I work for the public sector in Cape Verde, a small African country on the west coast. Considering the projects complexity in the public sector, involving many stakeholders, changing scope and short cycles. What would be your thoughts on how agile practices can help improve public sector project management. Thank you.
Jeff: In Kenya, a World Bank funded organization gets three times the work in 1/3 the time with Scrum. As a result, the World Bank increased their budget for this organization from $5M to $15M this year.
Q: Can Scrum work successfully in Construction Management? If so how?
Jeff: Yes, there are a number of examples. A large bridge in the Netherlands was built with Scrum. Tom Auld from the Collaborative Leadership Team uses Scrum to flip houses. You can also Google Scrum in construction for more details and examples.
Q: Jeff's book and his talk has great examples but Scrum seems more appropriate to process organizations with a pile of work to do. Where is the big picture to see how the items in the pile come together to create a large service or object?
Jeff: Systematic, Lockheed, Raytheon and others do massive billion dollar projects for half price with Scrum. You need training, a disciplined product owner team and strong leadership to coordinate and turn a huge vision into actionable backlog items.
Q: Can you use scrum for enhancements or bug fix in IT? When it does not fit producing a product following full SDLC process.
Jeff: Scrum is widely used in support teams, everywhere from call centers to help desks. Google this and get Scrum training.
Q: How do you avoid integration issues when deliverables are coming faster from different teams? Who is responsible for governance and any incompatibility/integration issues between different deliverables that, in some cases, are meant to work in harmony for a bigger objective?
Jeff: Amazon delivers a new feature to production every 10.6 seconds with 1000 Scrum teams. That's why they have all the money. You need to get Scrum training.
Q: I totally agree with your emphasis on Product Development; However, as a product already in production, is waterfall not the better way to go as profits become important. To simplify, change = change in cost.
Q: You provided examples how SCRUM helped organization doing repetitive work (e.g. toyota will keep doing cars). How can SCRUM help organizations who have different deliverables (e.g. IT services company that will deliver different requirements to different clients in different domains) and how can you avoid integration issues if you have scrums of scrums in this case?
Jeff: In our Scrum@Scale class we show how to do this. A deliverable is a set of backlog prioritized by the Product Owner. Teams pull that backlog and deliver a fully integrated increment of that backlog every sprint or more often.
Q: With so many teams, how do you manage load balancing between the teams and avoid under-utilization?
Jeff: Load balancing is managed by the teams and is largely automatic in Scrum. That is the power of self-organization. Load balancing is a waterfall problem, not a Scrum problem.
Q: Any key differentiators between SAFe vs SoS?
Jeff: SAFe is an IT framework that is useless in sales, marketing, and other areas. It is heavy weight with a lot of waste and will never get you twice the work in half the time. SAFe also does not address organizational incremental change which is essential for business agility.
Q: Can you apply scrum to hardware as well as software?
Jeff: Most of our clients today are hardware companies so the answer is yes. Check out Scrum Inc. ScrumLab for many online courses on Scrum in Hardware.
Q: Are you aware of scrum being implemented in higher education?
Q: Which kinds of organizations are not suitable for Scrum?
Jeff: Organizations that want to continue to do half the work in twice the time will not be happy with Scrum. In every organization about 30% of the people do not want to change.
Q: Do you believe all projects can be and should be done using Scrum, or are there some that should still follow Waterfall?
Jeff: Any project that you want to deliver twice the work in half the time with higher quality should be Scrum. The leading experts on process control on the planet have pointed out that waterfall is a predictive process control system suitable only for projects with less that 4% requirements change during development. Otherwise the projects blow up and are late.
Q: Do you think SCRUM could ever work in a University environment?
Jeff: Yes, Scrum can work in a university environment if people are willing to change (and some are not). Google Scrum in Research.
Q:Where do you see (which industries) Waterfall working better than Agile methodology?
Jeff: Software companies will have difficulty surviving without Scrum today. Hardware companies are finding the same thing. Other domains will learn as they get disrupted by newer technologies. If they don't change they will be replaced by robots.
Q: I work at GlobalFoundries as a product development engineer and a team leader. It seems to me as our whole organization is using SCRUM without even realizing it - How would you suggest implementing official SCRUM methods without disrupting our current quasi SCRUM, if you will?
Jeff: Implement Scrum@Scale where you start with a small subset of teams. When they can do twice the work in half the time, roll that model out across the organization.
Q: How to start the implementation of SCRUM in a big and complex oil company with a very rooted culture (tradition). Where and how to start?
Q: How would you approach fixing the issues with Health Care in the United States using SCRUM methodologies?
Jeff: Healthcare needs total disruption and Scrum is the tool to do it with. I spent 23 years in healthcare implementing Scrum. In fact, I developed Scrum while working on healthcare research projects that were heavily funded by the NCI.
Q: I am very involved as the President of a not for profit home owners association ran by a team of 5 volunteer BODs. Are you aware of any Agile implementations in similar organizations?
Jeff: There is a paper on Scrum in Church which shows how to run a non-profit organization with Scrum. Large banks and our venture capital group implement this model.
Q: Can SCUM be applied to R&D in the Health Care Sector?
Jeff: After spending 11 years in research as a medical school professor and 12 years as CTO of two leading healthcare software companies, I can definitely say yes. Google Scrum in research.
There were great talks by many people using Scrum to make their work and life better. My presentation was on the Scrum@Scale which is designed for full company Scrum in any domain. In particular I addressed the Shu, Ha, Ri of scaling Scrum. Shu is the beginners state (20% improvement, Ha is the intermediate state (>200% improvement) and Ri is the state of mastery (>400% improvement in production and time to market). To get to the Ri state you need to understand Moore's Law.
Moore's Law Moore's Law is fundamental to understanding why Scrum was created and why it scales. Simply put, In 1965 the co-founder of Intel Gordon Moore observed that the number of transistors on a chip was doubling about every two years. That has continued for more than fifty years. The problem was that software development didn't have that kind of exponential growth, instead it was growing literally. In 1993, when Scrum was created, I became chair of the Object Management Group's committee on the problem. We needed to get software on an exponentially improving production curve. Hardware and software experts on the committee collaborated to figure this out and I wrote several papers on this work, for example "The Emergence of a Business Object Architecture" and "Why I Love the OMG."
What they Learned at Intel - NOTHING SCALES! At the 2016 Construx Software Executive Summit in Seattle, I met the Agile leader from Intel who booted up 25,000 engineers doing Scrum. Scaling transistors on a chip has been in the DNA of Intel since one of the founders wrote Moore's Law. The Agile leader pointed out that Intel learned that "nothing scales" and that you need a "SCALE FREE" architecture to solve the problem. The internet is one example and Scrum is another.
How You Can Tell When Your Scrum is SCALE FREE When we published the first paper in the IEEE Digital Library on a globally distributed team across North America and Russia, the academic reviewers pointed out that many people had shown improved productivity with process enhancement but no-one had ever published a paper showing linear scalability. In Distributed Scrum: Agile Project Management with Outsourced Development Teams we showed that doubling the number of teams by adding more teams in Russia to a large U.S./Canadian product development effort led to more than a doubling of global production. During the entire history of software development, this phenomenon of linear scalability has only been demonstrated on Scrum projects. For another example see Scrum and CMMI Level 5: The Magic Potion for Code Warriors. That is because Scrum, when done properly is SCALE FREE by design.
Many Scaling Frameworks are Not SCALE FREE You can tell if your scaling framework is crippling performance if productivity has not reached a 400% improvement and when you add more teams, productivity does not go up at linearly. You will never get your teams SCALE FREE unless you understand Moore's Law and implement it in software. This phenomenon is also seen in teams outside of software as it is domain independent.
Gordon Earle Moore (born January 3, 1929) is an American businessman, co-founder and Chairman Emeritus of Intel Corporation, and the author of Moore's law. As of January 2015, his net worth is $6.7 billion. Wikipedia
In part 2, Steve shares his success and details the deployment steps of this Scrum at Scale transformation.
My engagement with this particular division of the organization began shortly after a meeting at headquarters presenting to the technical leadership of the Fortune 100 corporation. That was in February. It was in April, after I had been working with this division for about 6 weeks (3, 2-week Sprints) when the velocity data and happiness metrics indicated that I had the information the leadership team needed to take things to the next level.
The leadership team had been very supportive of Scrum and were attending training and actively engaging in Sprint Reviews. They had proven themselves open to feedback coming from division-wide retrospectives. For example, at a leadership meeting, the GM stated “Since deploying Scrum, I have much better real-time visibility of what’s going on with key projects. I don’t always like what I see, but I know what’s going on!”
However, the leadership team had not yet run as a Scrum team themselves.
An early morning meeting with the head of R&D and the GM secured the support necessary for organizing the leadership team as a scrum team, complete with a Scrum Master from outside the executive organization. When I asked the GM if he and his team were ready to run as a Scrum Team, his reply was "yes, full steam ahead!"
This Leadership Scrum Team would host both the Executive Action Team (EAT) and the Executive Meta Scrum (EMS). They would work off of both a transformation backlog and a second backlog with stories representing the value they would deliver to their own staff and shareholders. The GM would be the Executive Product Owner for the EMS.
Of course, a transformation to authentic Scrum, or what Dr. Sutherland calls "Aggressive Scrum", doesn't take place overnight. It is a journey. However, that journey doesn't have to take years and organizations don't have to settle for a sub-optimized version of Scrum. This organization was able to define its vision for the transformation, and begin to pursue it in just a handful of Sprints.
The key to success was experimenting with scaling scrum across R&D, which necessarily involves the Quality and Manufacturing departments. These critical functions were integrated using 4 simple rules for scaling Scrum. Those simple rules, or ingredients, include: having a dedicated Scrum Master, Team, and Product Owner (in other words, actually doing Scrum at the team level), scaling the Scrum Master via the Scrum-of-Scrums, and scaling the Product Owner through the Meta Scrum. And, as we know from research concerning Complex Adaptive Systems, these simple rules allow for easy adaptation to the needs of a changing, complex organization.
Of course, we already had Scrum teams with Product Owners and Scrum Masters. And, those teams were coordinated through the Scrum@Scale "Scrum of Scrums" for the R&D organization with the Lab EAT being the focal point of the escalation of the various team's impediments. I had also initiated daily Meta Scrums immediately after the 15-minute Lab EAT so that we could determine how to best leverage the Scrum@Scale framework in its entirety for the whole organization, not just R&D. We tried a few different permutations and ended up with the arrangement below:
By running a daily Meta Scrum, we were able to inspect and adapt based on feedback and arrived at the best structure for the organization at that time. We decided to run the Meta Scrum twice a sprint anticipating an eventual once a sprint cadence. The structure of the Meta Scrum is depicted below:
Putting this together gives us the current Scrum@Scale picture:
This is asymmetrical in that impediments are still concentrated and escalated through the Lab EAT. This is a pragmatic practice until such time as leadership can scale Scrum across the entire organization.
In another few sprints, as the organization further refines how to scale Scrum based on the data being collected, we have an expectation that we will arrive at something closely approximating the following:
This desired end state is more fractal in that impediments and backlog associated with a particular deliverable (product, product line extension, component, etc.) are co-located within the Scrum-of-Scrums or Scrum-of-Scrum-of-Scrums that is responsible for that deliverable.
The leadership team has learned that a Scrum transformation isn't just following a recipe. Leaders actually have to commit to making Scrum their "day job" and endure the heat of the kitchen with their teams. They need to both work with and coach the rest of their organization on how to orchestrate their teams' individual dishes into one great dining experience.
True Scrum is documented in the Scrum Guide which has been highly optimized after decades of iteration based on real-world experience. Some scaling frameworks are inconsistent with the official guide and introduce waste into the system. As a result, they don't scale, particularly if they break the fractal nature of Scrum.
Business agility requires scrumming the organization. If a sales team were asked to implement an IT scaling framework, results would not be good. Scrum@Scale solves this problem by supporting all domains. See Scrum in Sales.
We learned from Reid Hoffman, founder of LinkedIn and host of the podcast "Masters of Scale," that organizations like AirBnB have to start by doing things that don't scale. You need to get a small set of teams doing "twice the work in half the time" and then expand a working model in rolling waves across a large organization.
When I polled the Scrum Gathering in the United States, 60% of organizations trying to scale Scrum have waterfall management. They think that agile is something they do in the IT area to make them go faster. To protect the waterfall corner office they implement a translation layer they call a scaling framework that protects their jobs by giving them all the standard waterfall reports. It was interesting that in Amsterdam they do better Scrum. Only 50% of the audience said they were doing WaterScrum.
Also, be sure to join me for a live webinar to launch an update to the Scrum Guide on 7 Nov 2017 where Ken Schwaber and I will talk about changes that reflect the deployment of Scrum across organizations and many domains outside IT.