When the Agile Manifesto hit the street in 2001, it combined several methods, sometimes called "lightweight methods," under a single banner. Scrum, DSDM, ExtremeProgramming (XP) and Crystal were all "agile" in that they matched the spirit of the manifesto. These methods enable small teams to do their best work, getting the paperwork out of the way and bringing the customer into the conversation.\nThe focus on "small teams" worked for small teams. Today, larger organizations want to move toward more agile methods, too. The methods they\u2019re interested in extend the original methodologies to include larger teams, coordination and oversight. They also introduce risk; an experiment that goes wrong for the entire IT department is much more dangerous than for a team that experiments for a few months.\nMost large organizations commit to a single software development framework. Companies that don't \u2013 that try to pick and choose the best pieces from each \u2013 still want to create a single vision. Either way, making the right choices requires understanding them all, their strengths and weaknesses, when and how they make sense.\nSo let's talk about them.\nWhat's left from Scrum and XP?\nTeams execute a project at a time (at least, we hope they do). Organizations execute programs \u2013 combinations of several projects that may overlap. Larger projects are built by teams of teams, or teams of teams of teams, that may work in different physical locations. This type of work requires coordination. Larger organizations typically want a loose-tight coupling \u2013 giving the teams freedom to innovate while creating just enough shared expectations to make cross-team coordination easier. Managing the work-in-progress, the planned work and the scheduling of when projects start and stop becomes much more complex.\n[Related: Learning Scrum: an empirical approach to product development]\nThen there is the legacy problem of switching to an agile approach. One senior manager of a Fortune 500 hotel chain described his rollout process as \u201ca dozen people on one conference call, taking systems down and back up again, over a five-hour period.\u201d\nScrum, XP, Crystal and the other first-generation development methodologies don\u2019t provide an answer to these questions. We\u2019ll explore how the new methods address these needs.\nSaFE\nThe popularity of Dean Leffinwell\u2019s Scaled Agile Framework (SAFe) makes finding training or consulting easier. There are plenty of articles, tutorials and videos online, and the certification process is clear and fairly mature. Relatively easy for organizations to transition to, SaFE is also prescriptive \u2013 it tells organizations exactly what to do. One program manager from a Fortune 500 company commented anonymously that without understanding the advantages of every piece of SAFe, senior management tends to adopt all of it, including team work, program work, \u201cbusiness epics,\u201d \u201ctechnical epics,\u201d metrics at every level and a host of other requirements. All those extra pieces can actually add complexity to the organization, which runs counter to the goals of agile adoption.\nLeSS\nLarge Scale Scrum (LeSS) literally scales up the activities in scrum, applying them at the team-of-teams level. In LeSS, large-scale planning takes one or two members from each team to form a second meeting; there is a daily standup that does the same as the daily scrum. The \u201coverall retrospective,\u201d which happens the week after the end a sprint, likewise pulls representatives from each team to discuss large program issues. On top of these, LeSS also adds open space, town hall meetings and other coordination and communication activities.\nThe formal LeSS Rules for two to eight teams fit on the front and back of a page; the version for product teams of up to a thousand people, LeSS Huge, is not much larger. Craig Larman, co-creator of LeSS, claims that large organizations add unnecessary complexity through single-function groups, handoffs and weak or slow feedback. \u201cRather than introduce a method which adds a Band-Aid on top of this\u2026we are trying to change the organizational design to create multi-skilled feature teams. These ideas are in contradiction to how organizations are usually set up.\nDaD\nWhile scrum assumes a team is in flight, it does not include where the team started, or how to make \u201csprint zero\u201d decisions, such as the base technology platform, the programming language and the architecture. That\u2019s where Disciplined Agile Delivery (DaD), Scott Ambler\u2019s framework, begins, including the inception of the project, architecture and team formation, and the end \u2013 production, operational use and support. Where \u201cScrum\u201d tends to assume a team exists in maintenance mode, DaD does not, giving the team time to decide on the platform, build tools, project schedule and the other challenges that happen for product development more and maintenance efforts less.\nLeadingAgile\nBased in Atlanta, LeadingAgile was founded in 2010 and quickly developed an international reputation as a company that provides executive level consulting on large-scale agile transformations. Instead of a \u201cscaling framework,\u201d LeadingAgile provides a "transformation framework" that begins by evaluating a company\u2019s planning goals relative to predictability or adaptability. This methodology also asks if product functionality is expected to Emerge (discovery based on market need) or Converge (delivering specific requirements and features at pre-determined intervals).\nLeadingAgile then offers guidance to improve delivery based upon what is driving the business today, while establishing a foundation to achieve where the IT organization needs to be to support the business tomorrow. The company organizes groups of teams into \u201cexpeditions,\u201dwhich move progressively through \u201cbasecamps,\u201d developing the skills needed to improve business outcomes over time. CEO Mike Cottmeyer calls this a \u201ctransformation roadmap,\u201d because LeadingAgile focuses on aligning objectives, creating transparency and improving business performance over implementing abstract models and rules.\nAlternatives to the \u2018big\u2019 frameworks\nAfter the aforementioned \u201cbig three\u201d and the work of LeadingAgile come a host of smaller scaling frameworks and methods. Sam Laing\u2019s Scrum Lean in Motion (Slim), for instance, is designed to complement LeSS. This author is the creator of Sustainable Cultural Agile Release in the Enterprise (SCARE), which applies the theory of constraints to agile adoption and is based on patterns that have emerged from successful scaling projects. Ron Quartel\u2019s FAST Agile, recently announced at the Agile Roots conference, focuses on improving the integration speed of large groups (and reducing waste) through the use of near-continuous open space meetings for planning.\u200b\nIf you could think of managing a large IT organization as one portfolio of work as a kind of scaling, then another option to consider is Johanna Rothman\u2019s work on The Project Portfolio and Program Management.\n[Related: Johanna Rothman: Getting serious about portfolio and program management]\nWhat the scaling frameworks are missing\nAdam Yuret, a portfolio management and strategy consultant, points out that the scaling frameworks cannot prevent a senior executive from personally poring over specifications and bug lists. He adds that \u201cNot only is that not the best use of their time, but when you have that as an example, it leads to middle-management doing the same thing, which eventually ends up with programmers getting conflicting directions from multiple people.\u201d Yuret\u2019s fix is not a framework, but strategy deployment, where leadership communicates clear strategic intents, then trusts the teams to deliver on that strategy however they see fit.\nA few other leaders, including Arlo Belshee, Matt Barcomb and Alistair Cockburn, have gone on to propose alternatives to the \u201cscaling framework\u201d idea.\n\n\t\n\nWho needs a scaling framework anyway?\nIn 2008, Arlo Belshee won the Godon Pask Award, the official award of the Agile Alliance for contributions for the practice. After earning the Pask Award, Belshee moved on to a coaching\/teaching position at Microsoft. That experience informed his 2013 blog post, Scaling Agile the Easy Way, in which Belshee claims that scaling objections have it backwards; that when companies develop true multi-disciplinary teams that can regularly ship software, the problems go away. As Belshee explains it, this is what happens once teams have that competence:\n\n\u201cThere won\u2019t be technical dependencies between your teams. Each team will be able to deliver value to the customer. Teams won\u2019t cause problems when they integrate code with each other. None of the products will have bugs (well, not for more than about an hour out of every 2 weeks). Teams can work together in order to provide solutions that enhance each other. Teams can also deliver business value without coordinating with any other team.\u201d\n\nBelshee is not alone.\nMatt Barcomb, an independent Agile coach and former VP of product development for Taxware, points out that while the problem of \u201cscale\u201d sounds hard, it typically means one of three things: spreading, coordination or alignment. As Barcomb explains it, what we think of as the big, organizational problems are fairly easy to understand:\n\n\u201cThey are either having some success in one area and need more teams to be successful (spreading); or they have a large multi-team project problem (coordination) which is addressed with concepts from Rothman\u2019s books or portfolio kanban and flow-based roadmaps, or else senior leadership is frustrated because through middle management down to teams don\u2019t seem to be getting traction on the goals\/KPIs they want (alignment). They typically introduce more controls, more detailed processes and more measures [\u201cframeworks\u201d] that typically result in the exact opposite.\u201d\n\nBarcomb\u2019s approach, like LeadingAgile, is to identify where the gap is and to work on that, making small improvements to skill and culture along the way.\nFinally, we have Alistair Cockburn, who organized the Snowbird Conference that created the Agile Manifesto, and was known as one of the leading thinkers on the topic before and after that conference.\nInitially hesitant when approached about scaling agile frameworks, Cockburn went on to talk about something he called the "Heart of Agile.\u201d In a nutshell, at the enterprise level, the heart of Agile asks these questions:\n\nIndependent of anything else going on, how will you increase collaboration?\nAccounting for everything else going on, how can you increase trial and actual deliveries to consumers?\nHow will you get people to pause and reflect on what's happening to and around them?\nWhat are some experiments your people will do at different levels in the organization to make a small improvement?\n\nThese questions are designed to help an organization decide which small change to make next in the pursuit of Agility, and to ground that change in the context of this organization and this moment, instead of relying on someone else's revealed wisdom. In short, they focus on responding to change instead of following a plan.\nCockburn subsequently elaborated on his blog with a post titled Using the Heart of Agile on the problem of scaling. \nPutting it all together\nThe dominant framework, SAFe, provides a way for a large IT group to organize itself as teams of teams of agile teams. LeSS does the same by focusing on improving communication between the teams. Belshee suggests starting by making high-functioning Agile teams that can ship working software on demand, and the scale problems disappear, while the other consultants tend to recommend small changes to adapt an organization toward a more Agile ideal.\nOnce we dig past \u201cscale\u201d to the real problem your company is most interested in solving right now, then one of these solutions might make more sense than the others.