Anyone who has been working in software development over the last 10 years or so will have at least heard of the term Agile. People often talk about doing Agile or being Agile but, beyond a cool-sounding buzzword, what is Agile really all about? Well, to answer that question, we need to look at the origins of Agile software development.

Back in the late 1990s, many senior software developers and industry leaders, fed up with the static and inflexible software development methodologies prevalent at the time, were already experimenting with more flexible and responsive techniques and approaches. In 2000 and 2001, a small group of these influencers met up to discuss these methods and techniques. The unifying theme behind this effort was a desire to be able to quickly deliver working software to end users and to get rapid feedback on the software's impact and scope. In the forthcoming years, methodologies developed under this philosophy came to be known under the umbrella term of Agile.

The Agile philosophy is best captured in the Agile Manifesto (2001), which identifies the following values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The Agile Manifesto clearly states that while there is value in the items on the right of this list, we value the items on the left more. So, it is not an abandonment of the old values, but a realization that some new values (individuals and interactions, working software, collaboration, adapting to change) are far more relevant in the modern software development world. In addition, they also came up with a set of principles (see Principles behind the Agile Manifesto in the Further reading section), emphasizing continuous delivery, frequent feedback, personal interactions, and much more. These principles are as follows:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from every couple of weeks to every couple of months, with a preference for a shorter timescale.
• Businesspeople and developers must work together daily throughout the project.
• Build projects around motivated individuals.
• Give them the environment and support they need and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development.
• The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity – the art of maximizing the amount of work not done – is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

It becomes clear that Agile is not a specific methodology, process, or framework but more of a mindset; a set of principles and ideals to guide us through the software development process.

This is a rather important concept to keep in mind: throughout my career, I've heard managers, directors, and developers boasting about being Agile because they have daily stand-up meetings, practice pair-programming, or use a Kanban board (more on these in Chapter 7, The Sprint Journey). All these are perfectly good tools to support an Agile development lifecycle, but their use alone does not make us Agile any more than wearing a cape and my underwear outside my pants makes me a superhero. To truly be Agile, you have to think and act in an Agile manner, that is in a manner consistent with the Agile Manifesto. One of the most popular ways of being Agile is by applying Scrum in your organization or team.

With this in mind, let's take a closer look at the Scrum framework.

In the previous section, we mentioned that in the late 1990s several visionaries were experimenting with flexible and adaptive ways to develop software. Two of these visionaries were Ken Schwaber and Jeff Sutherland. They came up with an Agile framework called Scrum, which was based on using the scientific method of empiricism, rather than strictly following a pre-defined plan. Scrum embraces Agile, not only because it was created by two of the people involved in the creation of the Agile Manifesto, but also because the Scrum values are actively derived from Agile principles (see Scrum Values meet Agile Principles in the Further reading section). In fact, most organizations that have adopted Agile methods use Scrum (see The State of Agile in the Further reading section).

It is important to emphasize that Scrum is a process framework, not a process by itself. It introduces a number of rules, milestones, and checkpoints that must be adhered to, regardless of the underlying development process. The Scrum framework can be used to contain a varied number of popular development methodologies, processes, or techniques, as per the organization's working practices. Scrum doesn't tell us how to perform our work, it just sets up a container within which to perform it. We can use whichever development methods and design or release processes we like, within Scrum. As long as these abide by the Agile and Scrum principles, it is absolutely fine to do so.

Scrum encourages the adoption of values such as respect for people, openness, and commitment in order to help us to cope with uncertainty and solving complex problems. It promotes the creation of self-organizing and cross-functional teams that are able to deliver working software independently and in spite of ever-changing external requirements and circumstances.

The Scrum framework consists of three components:

• The Scrum Team: A self-organizing, cross-functional set of people who will deliver the working software.
• Scrum Events: A number of time-boxed events that help create regularity, provide feedback, foster self-adjustment, and promote an iterative and incremental lifecycle.
• Scrum Artifacts: Items that represent work or added value and that provide transparency for the team's work progress and achievements. Artifacts are also the cornerstone of inspection and adaptation.

The Scrum Team attends Scrum Events and creates Scrum Artifacts as well as working software. Events are attended at predetermined intervals and may trigger the generation or modification of artifacts. Artifacts may be inspected by the team but also by external inspectors. The following diagram illustrates these interactions:

Figure 1.1 – The Scrum framework components

The usefulness of Scrum lies in its three main components (Teams, Events, and Artifacts) and their interactions. We'll be discussing these components and interactions in detail in Chapters 3, The Scrum Team, Chapter 4, Scrum Events, and Chapter 5, Scrum Artifacts.

For now, let's take a look at one of the ways Scrum makes us work more efficiently and productively with the adoption of an iterative and incremental development lifecycle.

One of the greatest benefits of using Scrum is that it prescribes an iterative and incremental approach to software development. This is by far the most effective and efficient approach for creating software in today's world and in the next sections, we'll explain exactly why that is the case. Let's begin by remembering how we used to develop software…

The waterfall legacy

When I first started programming, we used to build our systems in distinct, single stages: first analysis, then design, then coding, and so on. Each stage would cover everything we would need to consider in order to deliver the whole system, down to the finest detail. Once the stage was complete, we would move on to the next stage of the development lifecycle and never re-visit the previous, completed stage. This is now known as the waterfall approach because each stage was like a distinct level of a waterfall, one following the other in sequential, non-repeatable fashion, as illustrated in the following figure:

Figure 1.2 – Waterfall development

As we soon came to discover, there were some serious drawbacks to this approach:

• First, it took a long time to actually deliver software to our users. Since we had to consider every possible requirement, and design and document every possible functionality before we could start coding, it would take months or often years to progress from system inception to system deployment. By that time, a competitor would have beaten us to the punch by delivering their system first or the business need for our system would have simply passed, overtaken by circumstances and changes in the market.
• Secondly, since we were moving sequentially from stage to stage, any design flaws or false assumptions that were discovered after deployment could not be fixed without a major re-haul of our system. This took a lot of time and effort.
• Finally, if requirements were changed by the customer once we were past the design stage, we would have to start pretty much from scratch again.

In short, the waterfall approach was inflexible, risky, and time-consuming. It worked well for projects with rigid, unchanging requirements that were not affected by market conditions and weren't time-critical. However, as software applications started to become more prevalent in our lives and the market expanded and diversified, such projects started becoming rarer. Gone were the days in which consumers were happy to sit and wait for the next version of their spreadsheet application to come out from one of the two companies that produced them, or to wait for their email provider to fix a bug in their email system due to there being no real alternative.

Today, customers have plenty of choices and they value the speedy delivery of working software over dependence on monopolistic software providers. For software providers nowadays, time-to-market is an essential factor in their strategy and waterfall development is just too risky and rigid to follow. Luckily, the people who came up with Agile methodologies saw this at an early stage and almost all of the Agile methodologies that were developed, especially Scrum, follow what is known as an iterative and incremental development approach. Let's find out what that means.

Iterative and incremental software development

Iterative development means developing software in small chunks repeatedly, instead of waiting for everything to be finished and delivering a large chunk at the end. It entails breaking down the requirements that need to be implemented and implementing a few at a time. So instead of having a large, big-bang software delivery at the end of the project, we have many smaller deliveries at regular intervals. These delivery intervals are known as Iterations. In Scrum, we call an iteration a sprint.

Incremental development means that each iteration builds upon software delivered by previous iterations. So, if we implement Feature A in our first iteration (let's call this version 1 of our system), then in version 2 our users will expect to see Feature A and another feature too. Sometimes, we may have to deliver Feature A again, but this time working better or faster or having fixed a bug in it. The point is, each iteration should offer something more than the previous one. This chunk of software and functionality that each iteration adds to the system is called an Increment. In Scrum, an increment is not randomly produced but is intended to achieve a specific goal, to deliver the desired functionality or to fix a specific problem. This goal is decided at the beginning of the Sprint and is known as a sprint goal.

The following figure shows the characteristics of an iterative and incremental development approach:

Figure 1.3 – Iterative and incremental development

As shown, in an incremental and iterative development cycle, there is no separation between the development stages. So, within the same iteration, our team may be designing some feature, while coding some other feature, while testing a third one, all at the same time. This approach to development gives the developers the chance to correct any mistakes, fix any issues, and inspect and adapt to changing requirements at an early stage, which means less time and effort and less risk of failure or late delivery.

In an incremental and iterative cycle, we deliver working software at the end of each sprint. So, as illustrated, for Sprint 1 we deliver a crude version of our product that doesn't do much but outline what we try to build, with some basic functionality. At the end of the sprint, we showcase our software to the stakeholders and receive feedback. At the same time, we come together as the Scrum Team to inspect and review what we did well in the sprint and what we could improve. This gives us valuable information on how to improve the product in the next sprint, but also on how to improve our working practices.

In Sprint 2, we apply the lessons learned from Sprint 1 and deliver a much more functional version of the product with more and better features. Once again, at the end of the sprint, we receive feedback, inspect, and adapt in order to improve both our product and our workflow.

In the final sprint, we deliver the whole product, fully functional. By incorporating the feedback we received and the lessons we learned in the previous sprints, we understand the customer requirements much better and have improved our productivity and teamwork. In fact, inspection and adaptation are key pillars of Scrum (more about these in Chapter 2, Scrum Theory and Principles), so it's no surprise that the Scrum framework imposes iterative and incremental development. It's one of the many reasons why doing Scrum is so beneficial. But let's look at some other reasons for doing Scrum…

Although Scrum is by far the most popular Agile development framework, it is by no means the only one. Kanban, Lean, Extreme Programming (XP), Dynamic System Development Method (DSDM), and Crystal are all examples of Agile processes, frameworks, or methodologies. I am not going to patronize you by telling you that Scrum is the best approach and you should follow it unquestionably at all times. As with every other tools, you need to decide if its use fits your needs. I advocate Scrum and I use it most of the time, but I once worked on a project where Kanban provided the most fitting approach, due to that project's special circumstances. Some of my fellow Scrum Masters and PSM members have occasionally found that using Lean tool-sets, such as 5S, or applying XP techniques, may suit a specific project's needs better. In fact, many organizations use elements from other Agile approaches in addition to Scrum. However, Scrum is the most popular for good reasons:

• Short, focused iterations allow for quick software delivery to customers
• Constant opportunities for introspection and adaptation allow better product quality and team efficiency
• Scrum's transparency allows external stakeholders to follow progress even without knowing or understanding Scrum

If this is not enough, consider the fact that the overwhelming majority of Scrum users emphatically state that they will continue to use it, that it offers value to their organization, and that it improves work quality (https://www.scrumalliance.org/learn-about-scrum/state-of-scrum).

Professional Scrum Master (PSM) assessments are available to anyone who wishes to validate their depth of knowledge of the Scrum framework and its application. Those who pass the assessment will receive the industry-recognized PSM certification to demonstrate their level of Scrum mastery. To better understand how these assessments came about, let's take a look at how Scrum was organized and evolved.

Scrum organizations and their history

Back in the What is Scrum? section, we mentioned how Ken Schwaber and Jeff Sutherland created Scrum back in the 1990s. To better support Scrum and encourage its adoption, Schwaber, Sutherland, and others created the Scrum Alliance in 2002 (https://www.scrumalliance.org/). In 2009, Schwaber decided to go his own way and created Scrum.org. These two still remain the only valid and authentic Scrum organizations. They both offer Scrum-related certifications. Scrum.org offers PSM certification at two levels: I and II for a fundamental and advanced understanding of Scrum, respectively.

To ensure that both Scrum Alliance and Scrum.org are aligned, that the Scrum content doesn't digress, and that Scrum remains independent of any organization, Schwaber and Sutherland created a public document called The Scrum Guide (Further reading). The Scrum Guide contains the definition of Scrum and its components and all the rules and responsibilities prescribed by the Scrum framework.

They occasionally revise this document, with the current version being November 2017. This book is based on and uses this version of the Scrum Guide. The Scrum Guide is essential reading for anyone wanting to take the PSM assessments, or indeed anyone practicing Scrum.

Now that we know how the PSM assessments came to be, let's get better acquainted with the PSM I assessment, which is what we'll be focusing on in this book.

The PSM I assessment

Unlike its Scrum Alliance counterpart, the PSM assessment requires passing an online exam. Here are some details on this:

• The exam consists of 80 multiple-choice questions and must be completed within 60 minutes.
• The pass mark is 85%.
• The exam is only offered in the English language.
• Some questions have only one correct answer. Some questions have multiple correct answers. Some questions have only a True/False answer. It is clearly indicated during the exam how many answers are correct for each question
• Not every question has the same weight, so don't think that you need to answer 68 (that is, 85%) questions correctly in order to pass the exam; it could be fewer or more, we just don't know how the questions are weighed.
• The exam costs 150 US dollars, which are payable online by credit card.

There are no official pre-requisites for taking the exam. In other words, Scrum.org does not require you to attend any of their courses, read any of their books, or even have real-life Scrum experience before sitting it. Having said that, allow me to offer you some tips:

• As with any knowledge domain, real-life experience makes a difference when taking an assessment. I know PSM I holders who passed the exam without having worked with Scrum before. However, any experience you have working in an actual Scrum-based organization will increase your odds of passing.
• Books by the Scrum creators, such as Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust in the Further reading section, provide some valuable insights that can often prove useful during the exam.
• The Scrum Open Assessment (https://www.scrum.org/open-assessments/scrum-open) is an extremely valuable tool to prepare you for the exam. Some of the questions in it often appear during the actual exam. I strongly recommend taking the Open Assessment before taking the actual exam.

We will be covering the PSM I assessment in great detail in Chapter 9, Preparing for the PSM I Assessment.

In this chapter, we discussed the concept of Agile development and its nature as a specific philosophy, guided by certain values and principles. Adopting the Agile mindset will help you immensely with applying Scrum and solving everyday problems with your projects. We then introduced the Scrum framework, describing its three components and we reviewed its benefits, namely its flexibility, adaptability, and transparency. Finally, we examined the iterative and incremental development approach used by Scrum and highlighted its relevance to the modern software development world.

We concluded the chapter by talking about PSM assessments and the PSM I exam. Throughout the rest of this book, we will expand our knowledge on Scrum and how to apply it, thereby gaining knowledge that will help you to obtain your PMS I certificate and become a successful practicing Scrum Master.

In the next chapter, we will discuss the Scrum values and principles and how they support and affect the Scrum framework.

• Principles behind the Agile Manifesto, https://agilemanifesto.org/principles.html
• Scrum Values meet Agile Principles, https://www.scrum.org/resources/blog/scrum-values-meet-agile-principles
• The State of Agile, https://betanews.com/2019/05/07/state-of-agile-report
• The Scrum Guide, https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf
• Ken Schwaber and Jeff Sutherland, Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust, Wiley publications, 1st ed., Mar 2012