Erik Weber

Scaling Scrum. Agile at Scale. Enterprise Everything. Everyone is using the Scaled Agile Framework SAFe. Scaling, Scaling, Scaling. If you’re working in product development, you’ve probably had a few conversations on this topic. It seems to be all the rage right now. In this blog post I hope to lend some clarity to what we mean by scaling. It turns out not everybody is talking about the same thing, and different organizations have different things they want to scale. So here’s a break down of possible scaling scenarios, along with my very simple, high-level, thoughts on where you might want to start. One quick note on the word “product.” A Product is something a customer buys or internal stakeholder uses, as seen from their point of view. Too often the development side of the house sees products as a reflection of how their teams are organized or how the code has been written, or some other inside-out view. This is probably a result of Conway's Law, it frequently causes problems, and is a topic for a different blog post (or book?). 5 Scaled Agile Scenarios 1. One Product, One Team You don’t need to think about scaling the process. Just relax, and focus on growing a solid agile team. Professional Scrum may be a good place to start: its mixture of XP, modern development practices, lean product ownership, and the Scrum framework is a good choice for most teams. You may however want to start reading on #5. Note that for every scaling scenario that follows, I’m presuming you actually have a healthy, sustainable, vibrant agile team at the core. Before you focus on how to scale anything, I highly suggest spending some time getting the most out of the people and teams you already have. Improvements at the team level almost always have a greater ROI than improvements in scaling. Or if you don't believe that, at least know this: if you're doing "just OK" at the team level, you'll be doing no better that "just OK" at scale, and probably much much much much worse. 2. One Product, Many Teams This scenario’s chief obstacle is how do you get many dozens of people to create a single product, a big complicated product, all working towards the same goal, and creating the thing all at the same time?! Things that help here include: A single backlog owned by a single product owner who is the person with the overall customer-centric vision for the product. You may scale some of the tactical PO duties (writing PBI details, acceptance criteria, daily clarification of work) downstream by having strong business/product/analyst skills on the development teams. You can scale some of the market-side PO work upstream by having a team of product managers/marketers help with pricing strategies, customer feedback, and market research. A way for teams to select work from the product backlog, without stepping on each other’s toes. With just a few teams this is fairly straightforward and PBI’s can be pulled via having a simple conversation amongst team members. ProTip: Refinement sessions should focus on dependancies up and down the Product Backlog as well as across teams. With dozens of teams, you may think about asking the PO and teams to label the backlog with a few simple categories in order to help this go a bit faster. A scaling framework may help here, but I do caution against large and long meetings just for selecting work – the cost almost always outweighs the benefit, and it screams of the old-school-thought that we can perfectly estimate->assign->execute the work. Keep this simple, it’s not the biggest obstacle in this scaled scenario. A way for teams to create a single product. Turns out if you want hundreds of people to simultaneously create one product, there are technical necessities. Single source control, continuous integration/build/test/deploy, use of SOLID principles, API’s, DevOps concepts, etc. The bigger you scale, the more of this you need. A way for teams to communicate with each other. You probably need a mixture of formal interactions and informal communication cues. Some of the scaling frameworks can help with the formal checkpoints. My experience is that the informal communications are even more important. Focus on growing a culture of communication where anybody can go talk to anybody else, regardless what team you’re on or who you report to. Some chat tools like hipchat/slack/yammer and video tools like skype/hangouts/sqwiggle can help when there are hundreds of people across the globe too. A way to see progress on the product across all the teams. Sprint Reviews become a challenge with dozens or hundreds of teams. Think about different formats like the “science fair” or the “video reviews” made popular by the teams at Microsoft. Tools like UserVoice or even some Visual Studio tools can be useful for gathering asynchronous feedback from stakeholders/customers. You also may have to do some arithmetic magic in excel for creating a multi-team release burndown for teams that have various velocities (even if you’re using a scaling framework I do not recommend the practice of “normalizing estimates” across teams, it breaks some core relative estimation principles, and it’s simply not needed). My recommendation here is to start with Professional Scaled Scrum and the Nexus Framework. 3. Many Products, One Team This is an often-overlooked situation in the whole scaling discussion. Many teams are in the difficult position of developing and supporting many different products and product lines all at the same time. The scaling question here is “how do we figure out what the team should be working on?” and the following things should be considered: Our constraint in this system is the throughput of a single team. We should optimize for that constraint by ensuring they are only working on the most valuable work we can find. Therefore, product ownership, backlog refinement, and hyper-prioritization based on value become even more important. You should be terrified of working on the wrong things. Lean thinking tells us that context switching is a form of waste, so “work a little bit on all the products” is probably not an optimal strategy. You will have to get good at “saying no” and being able to explain that the team is focused on higher value items at the moment. Shorter sprints or flow-based systems typically work very well here. I personally like combo of: Kanban + DoD + Refinement-On-Demand + XP-Modern-Development-Practices. Extreme focus on quality. If you’re in the situation of also having to support all these various products, nothing buries a company quicker than poor quality. You have virtually no chance of survival if in addition to all the above, we have to constantly worry about production support issues. Keep quality high, tech debt low, and never compromise your definition of done. Managing many different product backlogs and comparing the value of items between all of them can be a pain. Not to mention there are projects coming to an end and a funnel of possible new ones to begin. You need to consider some sort of agile portfolio management, whether that’s a tool, process or framework. The key to agile portfolio management is to visualize the portfolio, get the PO and other stakeholders talking about it on a regular basis, and have a lightweight way to get the necessary data you need to make decisions. 4. Many Products, Many teams First, for each product, see #2. Now the only problem that remains is how to manage all these various products we’re building, which we just covered in #3. You have both situations happening simultaneously. This is where most organizations reach for a solve-for-everything scaling framework. And that’s not such a bad idea here, assuming that the individuals and teams on the core of this huge scaled system are already operating at very high levels. As in #1 above, I suggest you focus most on the teams, and don’t spend all of your time, effort, on money, and solving for the higher level scaling issues. A process optimization that helps a dozen people at the top but hinders thousands of people on development teams is, well, not an optimization. 5. Beyond the Team What do you do when other departments needing to plug into agile product development? What are the leadership behaviors, management tools, and organizational structures that best support an agile enterprise? Along with the software and product development practices, the agile umbrella includes many other concepts that are useful to other departments in a modern agile organization. Here’s just a few to look into. Operations: DevOps and Continuous Delivery Finance: Beyond Budgeting HR: Drive, Holocracy, and The Alliance Framework Sales & Marketing: Pragmatic Marketing and the O’Reilly series of Lean Books Leadership & Management: Management 3.0, Radical Management, and Stoos, and The Responsive Org Conclusion Want to be part of this discussion? Do you have more suggestions for "beyond the team" techniques? Want help implementing these ideas? Please contact me!

In the past few months I've been working with a company whose products are most hardware, circuit boards, and firmware. There is some software, but it's "less than 10% of the cost and time required to release new product." So the purpose in bringing me in was speed up the hardware side of things, and just leave the software side alone. Here are some key lessons from this engagement: You can indeed make meaningful and valuable changes to hardware in 1-month Sprints. Use of rapid prototyping, 3D printing, and micro-onsite-manufacturing-labs are worth the cost of investment. Design by contract and componentization is key. The ability to get from idea to done in 1-month allows for better products, quality, and innovation. You can still send your final "box it up and send it to the store" bill of materials to an offshore manufacturing facility for economies of scale. For those technologies and teams that simply cannot get anything done in "less than 6 months," and yes that's a direct quote and I believe them, it still pays to get together every few weeks to inspect and adapt. This feels like micromanagement to those involved, as they are not used to having to show work more than every few months. This is an important realization to make early and coach through. For products that require both hardware and software, you are automatically in a scaled-Scrum situation. The company was surprised how little these teams communicate on a typical project. So using the Nexus framework makes alot of sense here. Even if one team isn't using Scrum, the Nexus Framework and communication mechanisms built into it are helpful. You need to become a software company. The pace of tooling, techniques, and technologies in software is advancing and changing at a pace exponentially faster than hardware. Even given all the modern hardware fabrication techniques this company has at their disposal, it's slooooooow compared to software. It didn't take long after shortening cycles for the company to realize a shift in strategy is needed. If we built multi-use-generalized-hardware platforms, we could release new products via writing software features only. Hardware and Scrum has always been something we talk about, and I'm starting to see the challenges and opportunities in this space. What have you seen? Leave me a comment below:

VersionOne does an annual "State of Agile Development" survey and publishes the results for the cost of your email address. Thanks VersionOne! I recently read through the 9th annual survey results for 2015, and there's lots of good, useful data there. For now I want to highlight the top five reasons agile adoption fails, and what you can do about it: Here are the top 5 leading causes of failed agile projects: 1. "Lack of experience with agile." 2. "Company philosophy or culture at odds with agile core values." 3. "Lack of management support." 4. "External pressure to follow traditional waterfall processes." 5. "Lack of support for cultural transition." My strategy for overcoming these challenges in most large global organizations is employing the Studio Model, something Ken Schwaber wrote about in Software in 30 Days. The basic idea is to carve out a part of your organization as a new "Agile Studio." Within the Studio, we start projects that are allowed to use various agile concepts techniques. And because most of the people are unfamiliar or inexperienced with agile techniques (#1), we only allow trained professionals to be on projects in the Studio. And the training we use is not a weak professor led teach-at-you course or silly learn-by-playing-metaphorical-games workshop, it's serious experiential courses that include actually building software. Making the decision to set up the Studio inherently involves management. It actually requires managers to take action to form such a structure inside their organization. By doing this we ensure buy-in, which intrinsically tackles the problems of #3 and #4. Sound too easy? Yes, we aren’t done yet… The scale of the Agile Studio is the primary management discussion point once we’ve achieved buy-in. Do we start with just one project because we're just not that confident in this agile thing? Ok, let's do that! Or do we start with a major scaled initiative because it's critical to our business’ success? OK, let's go! Once management has made a decision about how to start, they are the ones actually organizing and supporting the Studio. The lines of communication between management and the team are now open; they have skin in the game and are incentivized to see the Studio succeed. In fact, because change like this tends to make us humans nervous, we find management quite engaged in the Studio start-up. Additionally, everyone - managers included - require training and coaching in order to operate in the Studio - don't forget that #1 applies to everybody! #2 and #5 are a bit trickier. I wish there was a simple technique to install a new culture at your big company. Instead, I've come to believe that culture is a symptom. Culture change follows after other change - structural, organizational, process, communication style, etc. The best I can tell, and this is by no means a scientific study, an organization’s culture is mostly a result of the processes they use, and the communication styles of their leaders. So in the context of an Agile Studio, we actually change the processes we're using from day one. Do you want a culture that is transparent and freely inspects and adapts the work product? Well, let's use a process that builds those elements in. Soon you'll start seeing these things bleed into everyday work. As for leadership and communication styles, one of the things I often do in the Agile Studio is work one-on-one with each manager on this very topic. As an agile coach, I am skilled in this area, but I often use a Professional Coach for this type of work simply because it's such a different skill-set than "agile process coaching." Anything - absolutely anything can fail if it is not executed properly. What is clear from research is that using Agile techniques for software development is far more cost, time and demand effective than Waterfall or other, older methods. If your company has experienced any of the above obstacles to success in Agile adoption, let’s revisit your approach. Contact a Professional Scrum Trainer to ensure you remain competitive in the ever-increasing battle for better software with faster delivery. View the original post here: http://www.erikweberconsulting.com/blog/2015/7/21/failedprojects

The Standish Group's "Chaos Report 2015" was recently published. Standish gathers data from projects done across a variety of industries. They present the data in buckets of "successful, challenged, or failed" projects. I'd like to highlight my two key learnings after reading the 2015 Chaos Report. ONE: Standish redefined what "successful" means in 2015. Previously, a successful project was on budget, on time, and on target (e.g. scope). Standish admits "on target" was never a good measure because it lacked any measure of customer outcome. They even note there are many projects that met the triple constraints, but left the customer unsatisfied. So they replaced that measure with a measure of customer perceived value. This resulted in a 7% decrease in the rate of successful projects You read that right. If we start measuring ourselves the way our customers measure us, we're doing at least 7% worse than we think we are. This should be the final nail in the coffin of traditional scope/schedule/budget project management. “We found that both satisfaction and value are greater when the features and functions delivered are much less than originally specified and only meet obvious needs.” — 2015 Chaos Report, Standish Group TWO: There are three clear things you can do to increase your chance of project success. 1. Run small projects. Regardless other factors, small projects are more likely to be successful. By a factor of at least 10, up to 30. Over half of the huge projects return low or very-low value. Full stop. With this data, I can no longer understand why any huge project should ever get the green-light. Take the time to break projects into small pieces of work. Big batches & long queues are universally bad. 2. Run agile projects. Across all sized projects, agile projects are 350% more likely to be successful. This difference is minimal when running small projects - 32%. But at the huge project end of the spectrum, agile projects are 600% more likely to be successful. This is really strange, considering the intense focus on "scaling" that exists in the agile industry. Indeed, it's waterfall that sucks at scaling. “The overall results clearly show that waterfall projects do not scale well, while agile projects scale much better.” — 2015 Chaos Report, Standish Group 3. Train your agile teams. The data suggest that every time the team "levels up," the likelihood of project success goes up by 23%. From the lowest unskilled-untrained teams to the best "gifted" agile teams, there is a 224% increase in chance of success. Conclusion If you haven't already begun changing your organization to redefine how you think about success, start now. What matters most is the value your customer perceives. Traditional scope/schedule/budget is a poor proxy. And keep running small agile projects, with focus on the skills and training of folks on the team.

I’ve been witness to the start of hundreds of teams and projects. There’s a point at which, during the launch of a new team even before the first Sprint, I can tell with fair certainty whether the team will be successful or not. I’ve been thinking about what the root causes of this are, and here’s my conclusion. The success of a new team mostly depends on how the organization views the teaming process. Let me draw two extremes to highlight my point. Some orgs believe teams have to come together, care should be taken in teaming, formation, and launch. These are the orgs that believe that project success is a function of the team and team launch. Other orgs believe individuals can be assembled at will, and project success is more a function of executional excellence. Obviously organizations fall somewhere in the middle of this spectrum. But there’s a point in the team formation process where the core beliefs of management are reflected onto the team, in a transference type way. There’s no direct connection or action taken by management, but there is a REAL effect on the performance of the team. The simplest thing you can do as a manager is to start looking at the team launch process. Start looking at the way your org starts new projects. Are teams thrown together? Is there a teaming process? To individuals have the skills and resources to thoughtfully form a new team? My experience in these situations is backed by research. J Richard Hackman’s extensive research in team dynamics gave us the 60-30-10 rule, explained in his book Collaborative Intelligence. The variations in team performance can be explained in the following way: 60% is due to the design of the team, 30% to the launch of the team, and 10% to the execution on ongoing coaching of the team. That should be a big wakeup call to those of us trying to start new teams and projects. 90% of the success of the team can be attributed to things that happen before we even start sprinting.

I always spend time during training classes thoroughly covering the concept of Definition of Done, sometimes abbreviated “DoD.” As a concept it’s fairly easy to understand and people generally see the value right away. And in practice, for many teams, this concept is the single biggest game changer for their speed, quality, and process. But I’ve also found that there are many ways to put the DoD into practice, and many techniques for using it during the course of a Sprint. I’d like to share some of those here: Manual Walk-Through. The most basic pattern is bringing up the DoD in the Sprint Review and manually walking through it for each PBI. This has the effect of putting focus on the importance of the DoD, and making it “front and center” for the whole team and stakeholders. This is very important as it establishes an agreement between the Development Team and the PO and other stakeholders that every PBI they show at a Sprint Review will adhere to the DoD. I highly suggest starting with this pattern to build that trust. However, it is a time consuming activity and quickly grows dry after a Sprint or two. Consider moving on: DoD checklist. A common technique I see on many Scrum teams is using the DoD as a checklist. The team either pasting that checklist inside each PBI As the team progresses on the PBI, they check off elements of the DoD that they’ve met. It’s now very quick to bring up the PBI in a Sprint Review and show that the checklist is complete. DoD as tasks. Another common pattern is to create a task for each element of the DoD. Similar to the checklist, it ensures we are focused on the DoD item by item. Tasks are sometimes easier to handle than an additional checklist, and most Sprint Backlogs have the concept of “task” already, whether it is stickies on a whiteboard or a tool like TFS. PO Review of DoD. If the team is in the habit of showing PBI’s to the PO during the Sprint, the PO can use that time to ask if the DoD is met. I’ve seen this spawn really good discussions mid-sprint, not only about the DoD but about the PBI’s itself, acceptance criteria, and other clarifications. Be sure to bring up the DoD in each retrospective. Ask what we need to clarify. Ask what we could add to make it more robust. Ask other teams what they have on their DoD that has helped them. I like to see the DoD updated each Sprint, even it’s it’s only a minor clarification, just to make it a habit. Finally, there is really only one anti-pattern when talking about Definition of Done. And that’s cheating. Every time you bend the rules, say “good enough,” or forget about the DoD all together, you are taking on risk (and technical debt). I guarantee this will come back to bite you later. The Definition of Done is a really effective tool for ensuring quality, building trust with stakeholders, and producing a pattern of how the team creates product. Go up your DoD game!

File this one under: “how do you do Sprint Reviews when you have lots of teams?” Indeed, the traditional presentation format gets long, boring, and ineffective when you have more than a handful of teams presenting at a Sprint Review. From the point of view of an executive, this is exponentially true if you are overseeing many different products. The Video Sprint Review technique can help. I learned about the Video Sprint Review from Aaron Bjork at Microsoft, and if you skip to the ~40 minute mark of this video you can hear it too. Basically, with hundreds of developers, it doesn’t make sense to do a presentation style Sprint Review every few weeks. So they’ve adopted a pattern of “Sprint Mails.” Each team sends out an email at the beginning of the Sprint with what they have planned, and at the end of the Sprint with what they have DONE, along with a video of the working software. This email goes to all the teams and all the management: An example "Sprint Mail" from Microsoft. Sprint Plan on the left, Sprint Review including a Video on the right. A few things about this really work for Scrum at scale. And there are a few dangers. What works is that it’s actually feasible that a single stakeholder could review dozens of videos each Sprint. Whereas a traditional Sprint Planning meeting would take hours and hours, these short videos deliver information in concentrates bursts. The constraint of a 2-3 minute time-boxed video encourages the team to show the most important stuff in a highly organized and distilled way. This scales well, both in size and in geography – much easier to work with a distributed team using this technique. A few things to watch out for, besides the urge of creative folks to make Hollywood quality productions, as Aaron points out in his talk. This technique is largely unidirectional. The teams are telling the stakeholders what they’ve done. It’s incumbent on the stakeholders to speak up, and actively search out the teams and give feedback about what they’ve seen in the videos. This takes a special kind of culture, and managers are going to have to constantly work on creating this environment. The closer stakeholders and teams work together, the better product you’ll end up with. Another thing to watch for is the Definition of Done. We need to be extremely clear on what DONE means, especially when it comes to deployment environments, as a lot can be concealed in a video. Perhaps a good addition to these Sprint Mails would be a DoD checklist, or starting the video with a quick review of what DONE means. With these things in mind, I hope you consider adding this technique to your bag of tricks. Video Sprint Reviews can be very effective at scale, with many teams, and with many products.

Young Jimmy is in 3rd grade. He's constructed an immaculate paper-mâché volcano. It took every spare minute of the last to weeks to make. His mom carefully loads it in the back of the minivan. The anticipation is too much for Jimmy, he can't even look. Arriving at school, Jimmy helps her carry it into the gymnasium, one step at a time, a balancing game like he's never experienced before. Just as Jimmy gets his red and black peaked masterpiece setup in his booth at the Annual Science Fair, panic strikes him. So wrapped up in the architecture and construction of the erupting mountaintop itself, he's forgotten the vinegar and baking soda at home. "No worries," he thinks to himself, he took plenty of pictures during the test runs, "I'll just post the pictures up in my booth and the judges can see how absolutely perfect my volcano is." -- When you have many teams working on one product, having each team present and show their portion of the increment could take hours. And some stakeholders are only interested in certain portions of the product, and feel as if their time is being wasted in long Sprint Reviews. One technique that remedies this situation is the Science Fair or Bazaar. I'm seeing and using these more and more for Sprint Reviews. The concept is simple. The PO kicks off the Sprint Review with everyone's attention. She might go over the product vision, roadmap, state of the marketplace, and highlight significant new features delivered in the last Sprint. Then she dismisses the massive group and invites them to find teams they wish to talk with more in depth. The teams are lined up on the outer edges of the room (or in separate meeting rooms, hallways, or any free space!), with their team name and core functionality area clearly marked with a sign. They invite stakeholders into their "Science Fair Booth" and walk through the Increment with them, ask for feedback, allow the stakeholders to interact with the product, observe, and thank them as the move on. This technique is great of massively scaled projects with dozens of teams. Everybody gets an overview of the entire product, but then all the details are left to individual teams. Stakeholders can pick and choose what they want to see, and spend as little or as much time as they wish with the teams. When starting out, I highly suggest that you coach teams to pull in stakeholders actively, just like merchants at a bazaar, coaxing them to come and interact with the product and give feedback. As a new technique, sometime people just need a little nudge in the right direction. Get excited for showing off your product, just like Jimmy. Speaking of Jimmy.... -- As Jimmy is putting the finished touches on his arrangement of photographs, he spots Susie setting up next to him. Now Susie has always been just a bit behind Jimmy in school, always getting the second best marks, always finishing the race just behind Jimmy. Her volcano is a solid specimen, certainly, but nothing compared to the pixel-perfect replica of Vesuvius that Jimmy made. Susie, however, has remembered he vinegar and baking soda. As the judges make their rounds, Susie carefully measures out the exact ratio of ingredients, sets up her volcano, and at just the right moment: SWOOSH! Guess who wins the blue ribbon? -- Regardless of the Sprint Review format you choose, remember this: you have to actually show your done, working Increment of product. You have to actually "pour the baking soda and vinegar together." No pictures, no screenshots, no mockups, no prototypes, no talking endlessly. Show your work. This is your chance to show what you've built. This is what builds trust with stakeholders, and allows you to collaboratively inspect the product, and adapt for the next Sprint. Luckily, product development isn't as messy as paper-mâché. Well, rarely.

Starting a team new to agility on their first sprint is one of my favorite and most rewarding things to do. The enthusiasm, newness, sense of accomplishment, teamwork, and the communication displayed in just the first sprint is usually enough to leave most folks happily surprised. “Wow, I never thought our team could work like that. And we got so much done and without all the waiting and waste. Wow!" Of course that’s not what I hear at first. Well before the first sprint what I usually hear is this: “We’re all working on 6 projects at once, I can’t be on the Scrum team too." “We can’t have features all the way done, because they have to go through UAT and be approved by the quality review board, you can’t do that in 2 weeks." “We have to have an approved architecture before we can get a development environment setup" “I don’t think our offshore vendor will work this way." *These are are real quotes from real people A long time ago when I first started in management consulting, what I would hear when people said these things was logical arguments and problems that needed solving. And I’d go about my job and help them solve these problems. This typically resulted in passionate arguments and heated debates. I was only marginally successful. What I hear now is fear. I hear people scared to try new things. Afraid of what will happen if it fails. Unsure about how the new process fits in with the old. Fear that they could be held personally responsible if things go south. And this is far more useful a conversation starter. People can more easily be coached around fear than argued with logically. Especially when it comes to “the way we’ve always done it here” issues.

In the book Scaling Up Excellence by Sutton & Rao, they discuss two different ways to think about scaling: the “catholic or buddhist” approaches. I think this is a very interesting way to think about Scaling Scrum. The jist is: catholicism scales by having standardized practices and procedures, then scaling via creating perfect replicas of its already excellent self; buddhism scales by standardizing values and principles it deems excellent, then scaling via letting each practitioner vary the methods and practices in order to find a more perfect version of itself. In a nutshell, you might describe it as a centralized top-down approach versus a decentralized self-organized approach. Two very different approaches. Guess what approach most businesses take? Guess what’s most successful? --- I was recently in Scrum.org’s Scaling Professional Scrum course. Over two days, the course examines various approaches to scaling. The thing I really loved about the course was it’s principled approach toactually thinking about what might work in your specific context. We started by examining what makes a single Scrum Team click, and how to get more out of the Scrum you already have. Then when thinking about adding teams, adding products, or even adding an entire organization that you’ve just acquired, the class guides you through a series of exercises that force you to take a thoughtful, curious, critical look on what practices and methods might work or not work. For those of us that were “stuck,” there’s enough guidance and suggested practices in the course to give everyone a springboard to act on new scaling ideas. This balance of tools & techniques --- It turns out that if the thing you’re scaling is a complex, involves many different types of people, is subject to changing markets and conditions, and is at least a little bit unpredictable, then the best long term results come from a buddhist scaling approach. Now if the thing you’re scaling is mostly repeatable, predictable, the work is uniform in nature, and there is little ambiguity, then the best long term results come from a catholic scaling approach. You might guess that most businesses choose a catholic approach. We hear the following micro-narratives all the time: “That team is really successful, let’s do what they’re doing.” “We need to have standard work built upon best practices of the entire organization.” But it turns out what we need is not centralized methods and practices given by the top of the organization, but rather values, principles, and vision from the top and the freedom to explore practices within the boundaries those values create. The narrative in organizations that are successfully scaling goes more like this: “how does this help us live up to our goal of delivering products to customers more frequently?” “We really need to find a way to increase transparency around this project, one of our core values is transparency.” “If we created all the UX designs a sprint ahead of the coding sprint, how would that enable us to ‘welcome changing requirements’ and recognize that ‘the best designs emerge from self-organized teams’ ?" Notice there are no right or wrong answers from the top, yet concepts may be deemed right or wrong after we examine them in relationship to the values we hold. For example, the UX Sprint concept above is an extremely common scaling approach that seems to work mechanically, is very easy to implement in a catholic sort of way, yet in many ways doesn’t stand up to the agile principles we might deem excellent. Concepts from various scaling models might be perfectly suitable to your context, and I encourage you to start with a the principles and values you want your organization to reflect, and choose scaling techniques as you view them through the lens of these values.