Moving away from the traditional model

The movement away from the traditional plan-driven and linear-sequential development model was gradual and spearheaded by a relatively small group of likeminded individuals. Later in this chapter, I am going to discuss how the agile movement was led by a group of engineers, and not by management specialists. The fact that engineers led this movement has ramifications for why many agile practices did not address enterprise scalability issues from the start. But for now, I want to get into a description of some of the so-called lightweight approaches that set the stage for modern agile development concepts.

There were several lightweight methodologies available to the software development community well before the values and principles of agile were outlined in the agile Manifesto in 2001. In common across these lightweight methodologies were a reduction in governing rules and processes, more collaborative development strategies, responsiveness to customer needs and priorities, and the use of prototyping and iterative and incremental development techniques. In short, lightweight software development methodologies evolved to eliminate the complexities of the traditional software development model.

In this section, I'll briefly introduce some of the better known or impactful lightweight methodologies. These include the following:

• Adaptive Software Development, defined by Jim Highsmith and Sam Bayer in the early 1990s [Highsmith, J. (1999) Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Dorset House Publishing Company. New York, NY].
• Crystal Clear, evolved from the Crystal family in the 1990s, fully described by Alistair Cockburn in 2004 [Cockburn, A. (2005) Crystal Clear: A Human-Powered Methodology for Small Teams. Pearson Education, Inc. Upper Saddle River, NJ].
• Extreme Programming (XP), by Kent Beck in 1996 [Beck, K. (1999) eXtreme Programming eXplained. Embrace Change. Addison-Wesley Professional. Boston, MA].
• Feature Driven Development (FDD) developed (1999) by Jeff De Luca and Peter Coad [Coad, P., Lefebvre, E. & De Luca, J. (1999). Java Modelling In Color With UML: Enterprise Components and Process. Prentice-Hall International. (ISBN 0-13-011510-X)], [Palmer, S.R., & Felsing, J.M. (2002). A Practical Guide to Feature-Driven Development. Prentice-Hall. (ISBN 0-13-067615-2).
• ICONIX, developed by Doug Rosenberg and Matt Stephens, was formally described in 2005 [Rosenberg, D., Stephens, M. & Collins-Cope, M. (2005). Agile Development with ICONIX Process. Apress. ISBN 1-59059-464-9].
• Rapid Application Development (RAD), developed by James Martin, described in 1991 [Martin, J. (1991) Rapid Application Development. Macmillan Publishing Company, New York, NY].
• Scrum, initially defined as a formal process by Jeff Sutherland and Ken Schwaber in 1995 [Sutherland, Jeffrey Victor; Schwaber, Ken (1995). Business Object Design And Implementation: OOPSLA '95 Workshop Proceedings. The University of Michigan. p. 118. ISBN 978-3-540-76096-2]

Adaptive Software Development (ASD)

ASD starts with the premise that large information systems can be built relatively quickly, at lower costs, and with fewer failures through the adoption of prototyping and incremental development concepts. Large projects often fail due to self-inflicted wounds associated with unnecessary complexity and lengthy development cycles.

Some organizations address those problems by breaking up the pieces of a large and complex project into smaller component parts and reassigning the work to multiple teams, who work on their assignments independently and in parallel. However, that approach creates new issues in terms of providing clarity on what the components should be and do, what the final solution must be and do, and how it will all come together. In contrast, Jim Highsmith's ASD approach employed a combination of focus groups, version control, prototyping, and time-boxed development cycles to incrementally evolve new product functionality, on demand.

Highsmith was an early proponent of rapid application development. With an emphasis on speed, RAD reduced cycle times and improved quality in smaller projects with low to moderate change requirements. However, RAD was not an adaptive strategy, and it proved not to scale well in large and more complex environments that have a great deal of uncertainty associated with them.

Highsmith's approach drew from complex adaptive systems theory as a model of how small, self-organizing, and adaptive teams, with only a few rules, can find a path to construct the most complex systems. He argued that imposing order to optimize conditions in uncertain environments has an oppositional effect, making the organization less efficient and less adaptive. Plan-driven development projects continuously operate out of step and behind current organizational and market needs.

ASD implements a series of speculate, collaborate, and learn cycles to force constant learning, adaptions, and improvements. Instead of focusing on the completion of predefined work tasks, ASD has a focus on developing defined features that provide capabilities desired by customers.

The term speculate replaces the term plan in the ASD approach. The basic idea behind ASD is that a team cannot implement a plan to enforce a strategy based on a deterministic view that the world can only follow one set of rules or lead to only one perceivable and desired outcome. Instead, empirical evidence observed over the course of a project quickly reveals the underlying assumptions of the plan are flawed.

Planning is still an acknowledged requirement in an ASD-based project, but the ASD developers and project managers are aware they live in a world of uncertainty, and that plans must change. Therefore, the astute development teams know that they must be willing to experiment, learn, and adapt, and do so over short cycles so that they do not get locked up in a plan that cannot work.

The ability of a project team to be adaptive is largely contingent upon their ability to leverage the strength of their combined knowledge and collaborate on finding effective solutions to complex problems. Again, overly prescriptive plans get in the way of understanding, problem-solving, and innovations. In ASD, the focus is on delivering results, and not on completing predefined tasks.

Learning is the final part of the ASD cycle. The development team obtains input from three types of assessments: technical reviews, iterative retrospections, and customer focus groups. Learning reviews occur at the end of each iterative development cycle. Iterations are kept short to limit the potential damage from making errors that do not support the common purpose of the team and the organization it supports. Customer focus groups provide necessary and ongoing input, feedback, and validation.

Crystal Clear

Over a period of time spanning about a decade, Alistair Cockburn observed numerous development teams to determine what set of practices separated successful teams from those that were not. His study began in 1999 when an IBM consulting group asked him to write a methodology for object-oriented projects. Alistair determined that the best way forward was to interview project teams to uncover their best practices and techniques.

What he found was that success was not at all determined by the methods and tools the teams used to support object-oriented programming. Instead, the success criteria were much softer, more structural, and not so much based on the particular methods and tools used by developers to create their code.

After 10 years of continuing these interviews of successful software development teams, Alistair Cockburn wrote the book Crystal Clear: A Human-Powered Methodology for Small Teams. In that book, Alistair cites the following factors as being most critical to project success:

• Co-location and a collaborative, friendly working environment.
• Eliminate bureaucracy and let the team do their work.
• Encourage end-users to work directly with development team members.
• Automate regression testing.
• Produce potentially shippable products frequently.

So, in other words, it wasn't mature software development practices or tools that made the difference in building and deploying high-quality software products. Rather, it was the decluttering of bureaucratic and overly complex organizational structures that made the most difference in team effectiveness.

In a crystal-clear environment, the development team consists of anywhere from two to seven developers, and they work in a large room or adjacent offices. The team works collaboratively, often holding discussions around whiteboards and flipcharts to work through complex problems. The developers, and not specialist business analysts, work directly with end-users and customers to discern the functional requirements and capabilities needed by the product.

The team does not follow the directions of a plan or manager. Instead, they focus on the requirements they uncover during their direct communications with customers, and then they build, test, and deliver incremental slices of functionality every month or so. The most effective teams also periodically review their work to uncover better ways to build software and operate in their upcoming iterations.

Alistair believes different types of projects need different approaches and that a single methodology does not support all project requirements. Thus, he developed the Crystal family of software development methodologies to support varying project needs. For example, larger projects require more coordination and communication. Projects that are governed by legislative mandates or have life or death consequences require more stringent methodologies with repeated verification and validation testing to confirm the designs and suitability of the products for their intended environments. Smaller development teams working on non-mission-critical applications need less oversight and bureaucracy.

Alistair classified his Crystal methodologies by the number of development team members that must be coordinated on a project, and by the degree of safety required by a product. There are five Crystal colors used to define project team size. These five Crystal colors are as follows:

• Clear for teams of 2 to 8 people
• Yellow for teams of up to 20 people
• Orange for teams of up to 40 people
• Red for teams of up to 80 people
• Maroon for teams of up to 200 people

The Crystal Sapphire and Crystal Diamond methodologies provide additional rigor through verification and validation testing to confirm the viability of mission-critical, life-sustaining, and safety-critical applications.

The Crystal Clear methodology incorporates three properties of most effective small teams. These properties are as follows:

• Frequent delivery
• Reflective improvement
• Osmotic communication, for example, co-location of team members to improve collaboration

Alistair cites four other properties displayed by the most effective small teams. These are as follows:

• Personal safety
• Focus, for example, knowing what to work on and having the ability to do so
• Easy access to expert users
• Automated and integrated development environments

Extreme Programming

Kent Beck is another software engineer who came to realize that great software can be developed at a lower cost, with fewer defects, more productive teams, and greater returns on investment than the industry was producing under the traditional software development model. Now in its second edition, Kent Beck wrote his book titled eXtreme Programming eXplained to detail his approach to achieving the aforementioned goals [Beck, K., Andres, C. (2004-2005) eXtreme Programming eXplained. Embrace Change. Second Edition. Addison-Wesley Professional. Boston, MA].

XP places value on programming techniques and skills, clear and concise communications, and collaborative teamwork. Kent explains the methodology in terms of values, principles, and practices. Values sit at our core and form the basis of our likes and dislikes. Our values often come from life experiences. On the other hand, values also serve as a basis of the expectation we have of ourselves and others. Practices are the things we should do in support of our values. Likewise, practices performed without direction or purpose work against our stated values. Finally, principles help define our values and guide our practices in support of our values.

The values defined in XP encourage communication, simplicity, feedback, courage, respect, safety, security, predictability, and quality of life. Values are abstractions that describe what good looks like in an XP environment.

There are quite a number of principles defined in XP, and simply listing them here would not provide much enlightenment. I've summarized some of the most important principles here:

• Treat people with respect, offering a safe participatory environment that values their contributions, gives them a sense of belonging, and the ability to grow.
• The economics of software development, and the impact on our customers, is just as important as the technical considerations.
• Win-win scenarios are always preferred.
• Look for repeatable patterns that work, even though you must understand the same patterns may not apply to every similar contextual use.
• Get into the habit of designing tests demonstrating compliance before developing the code.
• Seek excellence through ongoing and honest retrospective assessments and improvements.
• Seek diversity in experiences, skills, approaches, and viewpoints when building your teams.
• Focus on sustaining weekly production flows of incremental yet high-priority slices of functionality.
• Problems or issues will arise and represent opportunities to make positive changes.
• Make use of redundancy in practices, approaches, testing, and reviews as checks and balances to improve the quality of released products.
• Don't be afraid to fail; there is something to be learned from every failure.
• Improvements in quality have a net positive impact on the overall productivity and performance of the team.
• Implement changes toward XP in small steps, as rapid change is stressful for people.
• Responsibility must come with authority.
• Team responsibility spans the entire development cycle, from the assignment of a story through analysis, design, implementation, and testing.

Principles provide the development team with a better understanding of what the practices are meant to accomplish. As with the principles, there are many practices listed in XP. Since practices are at the core of XP, we need to take a quick look at them:

• Teams work together in an open space, big enough to support the entire team.
• Ensure that teams have all the skills and resources necessary for success.
• Keep key information out in the open and visible through whiteboards, story cards, and burnup/burn down and velocity charts.
• Maintain team vitality by producing work at a sustainable and healthy rate.
• Implement paired programming where two developers work and collaborate on one computer.
• Use story formats to understand the capabilities customers and users need, and their priorities.
• Plan work 1 week ahead through the refinement of identified high-priority stories.
• Plan work ahead quarterly to evaluate ways to get better, identify areas to aggregate related work (for example, themes), and assign stories to the themes.
• Build in slack and don't overcommit.
• Install build automation capabilities and make sure product builds never take more than 10 minutes to complete.
• Implement continuous integration practices so that the developers merge their working copies of software into a source control management system throughout the day.
• Implement a test-driven development approach where tests are written before writing the code.
• Make time to incrementally improve the design every day.

As this is a book on scaling agile practices, it's interesting to note here that Kent Beck addresses the issue of scaling XP. First, add teams, but keep the basic small team model when scaling XP. Next, break down any large-scale problems into smaller elements and have the teams address each issue as simply as possible. For larger and more intractable problems, do whatever you can to stop making the situation worse, and then work to fix the underlying problems while continuing to deliver useful products.

Feature-Driven Development (FDD)

As the name implies, the feature-driven approach emphasizes the implementation of new or enhanced features at a rapid rate. Developed by Jeff DeLuca and influenced by Peter Coad, the FDD approach leverages object-oriented concepts with the Unified Modeling Language (UML) to define a system as a series of interacting objects. UML provides a method to describe interactions between agents and systems. An agent can be an end user or another system.

At its core, FDD is another iterative and incremental development approach that stresses customer focus and the timely delivery of useful functionality. The FDD approach integrates concepts from XP and Scrum, and, like RAD, takes advantage of modeling techniques and tools – including Domain-Driven Design (DDD) by Eric Evan [Evans, E. (2003) Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley. Hoboken, NJ], and object modeling in color by Peter Coad [Peter Coad, Eric Lefebvre, Jeff De Luca (1999). Java Modeling In Color With UML: Enterprise Components and Process, Prentice-Hall. Upper Saddle River, N.J.].

Peter Coad, et al., came to realize that, model after model, they built the same four general types of object classes over and over again. These four repeating object class patterns are called archetypes, which means a common example of a certain person or thing. The four common classes and their color classifications include the following:

• Moment-interval (Pink): Representing a specific moment, event, or interval of time
• Roles (Yellow): Defining the way some thing participates in an activity
• Descriptions (Blue): Methods to describe, classify, or label other things
• Party, Place, or Thing (Green): tangible and uniquely identifiable things

Many agile development approaches use stories as the structure to capture the capabilities that customers and end-users need the product to provide. The UML modeling approach describes requirements from the standpoint of client-valued interactions and functionality (a.k.a. features).

DDD has a focus on modeling domains/domain logic. Instead of working directly with customers and end-users, the DDD approach encourages collaborations between developers and domain experts to define models that accurately reflect the business domain and their problems.

The feature-driven development approach encompasses five standard processes:

• Develop a model – feature-driven, time-boxed, and collaborative.
• Build the feature list – from the models, categorized and prioritized, and time-boxed.
• Plan by feature – the assignment of features to developers.
• Design by feature – establish a design package with two weeks of work each that logically go together.
• Build by feature – keeping the development focus on developing and delivering useful features.

While FDD is considered an agile approach and often included as a lightweight methodology, the approach, by design, supports larger projects involving 50 developers or more.

ICONIX

The ICONIX approach to software development is another use-case-driven practice. However, it is a lighter-weight implementation of UML than the more widely known and practiced Rational Unified Process (RUP). Though RUP incorporates an iterative software development approach, it is a heavyweight approach that is highly prescriptive and implements a comprehensive application life cycle management approach.

Described by Doug Rosenberg, Matt Stephens, and Mark Collins-Cope, the ICONIX approach predates XP and RUP, when Rosenberg and his team at ICONIX developed an object-oriented analysis and design (OOAD) tool, called ObjectModeler. Their ObjectModeler tool supported the object-oriented design methods of Grady Booch, Jim Rumbaugh (OMB), and Ivar Jacobson (Objectory). The ICONIX process was formally published in 2005 in their book titled Agile Development with ICONIX Process. People, Process, and Pragmatism [Rosenberg, D., Stephens, M. & Collins-Cope, M. (2005). Agile Development with ICONIX Process. Apress. New York NY.]. The authors provided further elaboration on the ICONIX approach in their 2007 book titled Use Case Driven Object Modeling with UML: Theory and Practice [Rosenberg, D. & Stephens, M. (2007). Use Case Driven Object Modeling with UML: Theory and Practice. Apress. New York, NY]. In its modern form, the authors promote the ICONIC process as an open, free-to-use, agile, and lightweight object modeling process that is use-case-driven.

ICONIX implements a robust and relatively document-intensive process – when compared to XP – for requirements analysis and design modeling. In addition, ICONIX implements an intermediary process, called robustness modeling, to help developers think through the process of converting what is known about the requirements, into how to design in the desired capabilities. ICONIX implements a modeling technique called robustness diagrams, which depicts the object classes (for example, use case descriptions of classes and behaviors) and the flow of how the defined objects communicate with each other.

From a logical perspective, there is a different level of abstraction when modeling and analyzing requirements versus analyzing software and systems design requirements. They are two different worlds – physical versus logical. The robustness modeling approach helps designers visualize the translation of information from the physical requirements into a logical implementation.

The ICONIX approach breaks out into four delivery milestones, which include a requirements review, a preliminary design review, a detailed design review, and deployment.

Requirements analysis informs the requirements review milestone. The output of the business analysis includes use cases, domain models, and prototype GUIs.

A robustness analysis informs the preliminary design review milestone. The outputs of the robustness analysis include both textual and graphical descriptions of user and system interactions, both of which serve as aids to help the development team validate the requirements and designs with their customers and end-users.

A detailed design informs the detailed design review milestone. The domain model and use case text are the primary inputs to the design document.

The code and unit tests inform the deployment milestone. The term deployment is a bit confusing as this milestone serves as the completion marker for developing the code to support the requirements, and not a physical deployment of the application to the customer.

In summary, the ICONIX process is a lightweight, agile, open, and free-to-use object modeling process that employs use case modeling techniques. Its strength lies in the techniques the methodology implements to transition use case models of requirements into useful design elements.

Rapid application development (RAD)

James Martin wrote Rapid Application Development (RAD) to address the issue that the speed of software development activities always seems to lag behind the speed at which businesses operate. Given that computers and software were fast becoming the backbone of business operations and competitive responses, it was untenable to have 2- or 3-year development life cycles with an even larger backlog of requirements.

James Martin notes in his book that there are three critical success factors that information systems departments face:

• Speed of development – to implement new business capabilities
• Speed of application change – to respond to new needs and priorities
• Speed of cutover – to quickly replace legacy systems and operations

Martin believed the key to sustained business success was the installment of rapid application development capabilities.

Martin was an early proponent of the use of computer-aided systems engineering (CASE) tools, and he was the founder of KnowledgeWare – the company that produced the IEW (Information Engineering Workbench) case tools. (Later, IEW was sold to Sterling Software in 1994, which in turn was subsequently acquired by Computer Associates.) Ultimately, IEW combined personal computer-based information and data modeling tools with a code generator that expedited the process of building software applications that run on mainframe computers.

Martin's concept of RAD was to use tools and techniques to lower development costs, reduce development times, and build high-quality products. Manual processes often lead to reduced quality when attempts are made to expedite the process. However, the methods and tools implemented within CASE tools enforce technical rigor while simultaneously improving quality, consistency, and efficiencies in software development.

The modern concept of RAD lives on through Integrated Development Environments (IDEs), such as Android Studio, Atom, Eclipse, Microsoft's Visual Studio, NetBeans, VIM, and many, many others.

Scrum

This book is about mastering Scrum for enterprise, and the next chapter provides much greater detail on the methodology. For now, I want to focus on introducing Scrum as an example of a lightweight software development methodology and how and why it came about.

Both the initial concepts behind Scrum and the name Scrum came from the works published by Hirotaka Takeuchi and Ikujiro Nonaka, in their 1986 Harvard Business Review article titled The New New Product Development Game [Takeuchi, H., Nonaka, I. (1986) The New New Product Development Game Harvard Business Review. Retrieved <May 21, 2020.]. This article builds on original concepts developed by Nonaka as published in a 1991 article titled The Knowledge Creating Company. [The Knowledge Creating Company. Oxford University Press. 1995. p. 3. ISBN 9780199762330. Retrieved March 12, 2013.] The concepts behind Scrum are built on Takeuchi and Nonaka's findings that organizational knowledge creation drives innovation.

Takeuchi and Nonaka note that the traditional linear-sequential development methods are not competitive in the fast-paced, fiercely competitive world of commercial new product development. Takeuchi and Nonaka cite six differentiating factors that provide the speed and flexibility necessary for competitive success: built-in instability, self-organizing project teams, overlapping development phases, multilearning, subtle control, and organizational transfer of learning.

An important insight, highlighted by the two authors, is that knowledge creation leads to innovation, which in turn leads to competitive advantage. Moreover, they found that learning from direct experiences, and from trial and error, are essential elements of knowledge acquisition.

Jeff Sutherland and Ken Schwaber collaborated to develop the Scrum methodology. In their book titled Software in 30 Days, Southerland notes that the writings of Takeuchi and Nonaka profoundly influenced his early works [Schwaber, K., Sutherland, J. (2012). Software in Thirty Days. How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust. John Wiley & Sons. Hoboken, N.J.]. Ken Schwaber says he was influenced by the works of Babatunde A. Ogunnaike in the areas of industrial process control, and the applicability of complexity theory and empiricism in software development.

Sutherland developed his views on Scrum, initially in 1993, as an alternative to the highly prescriptive and top-down project management-based methodologies typified in the traditional waterfall-based software development model. Later, in 1995, Jeff Sutherland teamed with Ken Schwaber to formalize and present the Scrum process at the OOPSLA'95 (Object-Oriented Programming, Systems, Languages & Applications) conference. Jeff and Ken continue to maintain the Scrum processes in the form of the Scrum Guide. [Schwaber, K., Sutherland, J. (2017) The Scrum Guide™ The Definitive Guide to Scrum: The Rules of the Game. ScrumGuides.org. https://www.scrumguides.org/]

In his book titled Scrum – The Art of Doing Twice the Work in Half the Time, Sutherland notes that detailed project plans and schedules of the traditional waterfall model gave a false sense of security and control [Sutherland, J. Scrum The Art of Doing Twice the Work in Half the Time. Currency (An imprint of Crown Publishing and a division of Penguin Random House). New York, N.Y.]. He also came to understand that project plans and schedules are a red herring that hinder truthful assessments of the project's real health.

Project managers know they are working with incomplete information and uncertainty when they develop their project plans. What many may not have understood is that the strung-out life cycle of the traditional model prevented discovery of most critical issues until very late into the project schedule. Moreover, by then, the issues were often numerous and cumulative, adding further complexity and challenges to identify and fix the root causes of the problems. In effect, the plans and schedules locked in requirements, deliverables, priorities, and work activities built on incomplete and dated information and wrong assumptions. Consequently, too many traditionally managed projects failed miserably.

Sutherland realized the alleged benefits of the traditional model – control and predictability through detailed planning – were at odds with reality. The traditional model attempts to force a deterministic approach to management – based on the idea that future events are predictable and controllable. In reality, the world is full of uncertainty, subject to stochastic and interlocking processes and events.

Bull riders wouldn't have a job if bulls didn't buck. However, cowboys wouldn't think that they could sit quietly on a bull's back, with a predefined plan, and not have to respond to the bull's every movement. At least, not if they have any desire to stay on the bull for the full 8 seconds. Instead, cowboys use their senses to take in real-time information about the bull's movements, and they constantly adjust their weight and position to stay in proper alignment with the bull's actions.

Bull riding may sound like an extreme analogy, but businesses are no less prone to being thrown off their game by the constant flux in their competitive surroundings. So why do we think we can ride out those fluctuations in business with a predefined strategy that is not responsive to new information and change?

Sutherland and Schwaber both came to realize that software development teams must embrace uncertainty with creativity and responsive movements. They also realized that an entirely different approach to product definition and development was necessary to resolve the self-inflicted wounds of attempting to control chaos. Resultingly, both turned to the philosophy of empiricism, which espouses a belief that real knowledge comes from information gained through sensory experiences and empirical evidence (for example, knowledge gain through observation and experimentation).

Empirical processes support knowledge acquisition through evidence-based strategies that employ the use of human senses to observe and document patterns and behaviors. Empiricism also promotes the use of trial and error practices to reveal the effectiveness of different strategies through experimentation and analysis.

Sutherland's and Schwaber's approach to empiricism is encapsulated in the three pillars of empirical process control: transparency, inspection, and adaptation. Transparency means process information must be fully available to those who are responsible for its execution. Frequent inspections help the team observe their progress with the desired goals. And when deviations from expectations are noted, the team responds by adjusting the process to achieve positive outcomes through adaption.

It's foolish to wait until all the requirements are fully defined, and the product is fully designed, coded, and tested, to see whether it works, and only then determine whether the product still supports the customer's needs. Instead, it makes more sense for the responsible team to frequently evaluate their progress against their goals, and their continued alignment with the customer's current needs and priorities.

Scrum is lightweight because it is not overly prescriptive. Scrum is a framework and not a methodology that might otherwise impose a lot of rules, constraints, processes, and documentation requirements. Within the Scrum framework, developers are free to use any number of tools and techniques to accomplish their work. But the Scrum framework enforces minimalism, offers an open and safe environment to try different things, and implements a frequent inspect and adapt cycle of events.

This book is largely about scaling Scrum concepts because Scrum has largely won the agile methodology wars in terms of wide-scale acceptance. Nevertheless, there are different views on how to scale the implementation of Scrum capabilities across a large enterprise or a large project. This book addresses why there is not a single method that works in all situations.

In this book, we will explore this Scrum scaling issue together in three parts. First, in the next chapter, you will learn the basics of Scrum. Then, in Part 2 of this book, you will learn about the different approaches to scaling Scrum. Finally, in Part 3, you will learn how to apply Scrum in different environments and situations.

But, before we get to the next chapter, we'll review some of the core implementation concepts implemented by the lightweight agile methodologies. Next, we need to understand how the core concepts support Agile's values and principles. Finally, I'll discuss how the agile movement was initially powered by software engineers and not by MBAs or management specialists. The development of the values and principles of agile, along with the development of lightweight software development methodologies by software engineers, had profound ramifications on adoption and scalability in both large enterprise environments and large, complex projects.