Pass GAQM CSM Certification Exams in First Attempt Easily

GAQM CSM Certification Practice Test Questions, GAQM CSM Exam Practice Test Questions

Want to prepare by using GAQM CSM certification exam practice test questions efficiently. 100% actual GAQM CSM practice test questions and answers, study guide and training course from Exam-Labs provide a complete solution to pass. GAQM CSM exam practice test questions and answers in VCE Format make it convenient to experience the actual test before you take the real exam. Pass with GAQM CSM certification practice test questions and answers with Exam-Labs VCE files.

Chapter 02 - Introduction to Scrum

1. Introduction to Scrum

In this chapter, we're going to introduce you to all of the core Scrum practices: what Scrum is, what Agile is, what the Agile Manifesto is, and how Scrum enables organisations to take advantage of certain key concepts like empiricism and self-organization, and ultimately to be able to produce better results for customers in less time. Let's take a look at how Scrum is put together.

2. Learning Objectives

In this section, you're going to learn some of the key reasons for looking at agile development methodologies as opposed to traditional methods of project management. We'll talk about some of the specific benefits of the Scrum approach. We'll introduce six key core Scrum principles and why they are so very important to why Scrum works, and then five key aspects of any project and how Scrum leverages and supports those.

3. Terms to Know

There are a number of key terms that you're going to need to learn during this chapter, including things like adaptation, the Agile Manifesto, information, radiators inspection, portfolios, programs, and projects; scrum itself; guidance; body time; boxing; transparency; and waterfall.

4. Lesson: Scrum Overview

In this lesson, we're going to give you a good, solid overview of Scrum itself, where it came from, the key benefits associated with it, how it scales to support enterprise projects, and then the key aspects and processes that make Scrum work.

5. Scrum Overview

In virtually every enterprise, we have a need to effectively create and run projects. Project management, in and of itself, is really a management framework and a management tool. How do we spend money in a limited amount of time and bring together various resources to produce various products and services that are going to deliver value to the customer? And so when we think about any kind of project management or software development lifecycle methodology, we want to think about it largely in terms of how, in fact, we manage resources like people and time on a temporary basis to produce things that are valuable, whether they be tangible products or various services that we're going to deliver within any particular project. We're going to be asked to engage with many different groups of stakeholders, from end users to customers to various development and support teams. We'll have to provision and deliver the solution in question, and then the projects must be able to manage themselves. They produce various types of artefacts and ultimately produce deliverables that we can hand over to customers that they can leverage and use. So in order to actually carry these projects out successfully, organisations have wrestled with many different types of project management frameworks. All of these frameworks are fundamentally about management structures and controlling how our resources, time, and people are utilised to effectively create, provision, and deliver solutions for things.

6. Project Management as a Discipline

So project management as a broad discipline is really about establishing how, in fact, we're going to plan, organize, motivate, and control resources and people in a way that helps us achieve a specific type of goal. And in any project management methodology, whether you're talking about the PMI Pen Box or Prince 2, Scrum, or any other agile methodology, the basic stages of the project really still remain the same. We need to have some way to initiate it and kick it off. We have to have some ability to plan and design what it is that we're going to go do. How much planning and design we do may depend on the model we choose, how we're going to actually execute it and carry out the work, how we're going to establish monitoring and control so we can keep up with the work, and then how we stop—how it is that we know when we're finished and we can go ahead and close the project out.

7. Software Development Lifecycle Management

In order to wrestle with some of the unique aspects of creating and managing software in the industry, we've created a number of different software development, lifecycle methodologies, or management tools. Effectively, what we're trying to do are the same things that we described just before to be able to effectively initiate, plan, execute, control, and deliver projects, but to be able to do that in a way that combines requirements, design, acquisition, integration, testing, validation, and potentially deployment of solutions, and that ultimately produces a particular product or service with a lifecycle of its own. One of the things that's interesting about software projects in particular is that there are frequent changes as the customer's needs change, the markets change, and legal and regulatory requirements change. The product or service has to change as well. And so one of the things that's particularly attractive about Agile methodologies is that they're going to effectively enable us to manage change as required.

8. Traditional PM

In traditional project management methodologies, we use a technique called waterfall. Waterfall is intended to be very structured and provide a great deal of control over how we carry out and execute a project. In short, we want to be able to lock down each of the stages of the project before effectively beginning the next one. So, for example, I want to be able to lock down the requirements before I begin doing my design. I want to be able to lock down my design and architecture before I begin doing development and so forth. However, there is a fundamental issue, and that issue is that it does not work very well except for very short-term projects, such as a couple of weeks. And the reason it doesn't work well isn't because people aren't trying or aren't doing good work, but simply because of the pace of change. In a typical six-month project, as much as 60% of the requirements will change. This has everything to do with the pace of change in business, changes in legal and regulatory requirements, changes in internal capabilities, competitive threats, and any other combination of drivers you can imagine. So, in short, being able to deliver a flexible approach to how we're going to manage changes in projects is very fundamental to project success. And waterfall as a traditional approach really only works well when you have very well-defined and stable requirements over a very long period of time.

9. Agile History

So in response to some of the struggles that we've seen over history around using traditional waterfall approaches, starting in about 1995 and really coming to a head in about 2001, we've looked at industry-independent ways to flexibly manage projects and manage change. One of the key moments in this is the publishing of what we'll call the Agile Manifesto, which happened in February 2001. And the basic idea of the Agile Manifesto is that traditional project management methodologies valued certain things that we care about for the purposes of control but compromised other things that we might find even more valuable. Traditional project management, for example, emphasises the use of formalised processes, keeping tools, and how we actually carry out projects, comprehensive documentation of all the different aspects of the project throughout its lifecycle, negotiation of explicit contracts with six terms, pricing, and deliverables, and then the creation and maintenance of fairly detailed and long-term project plans. Now, as we've already discussed, in an environment where we have very frequent changes in requirements and where we have very dynamic, different needs that are happening within the customer environment, there are certain things that are happening that we have to value more than these particular formalised structures. These include interactions and individuals, as well as how various individuals working in teams either provide requirements or collaborate to build solutions to those requirements. How is it in fact that customers and their organisations can work together to build solutions that focus very much on the business value in question as opposed to being able to deliver to a fixed set of written requirements? Likewise, rather than focusing specifically on the documentation, if this is in fact a software project, working software is the solution intended. And so we want to have a very explicit focus on visible working software that customers can use for high-value solutions. that a focus on working software is simply more important than comprehensive documentation. That doesn't mean we won't have documentation, but we want to prioritise working software over documentation. Similarly, a strong emphasis on customer collaboration allows us to effectively manage change and risk as projects progress. And we want to be able to have the flexibility to respond to changes as they're identified in a way that's going to help us ensure that we don't deliver a solution to yesterday's problem, but to the problems that are currently being faced and the opportunities that currently present themselves to the business in question. So, to put this in a nutshell, we value the things on the right: we value having consistent processes and tools; we value having good documentation; we value having clarity in what's expected through negotiations; we value having some planning and structures. On the other hand, we value the things on the left more. How we actually create appropriate interactions, how we deliver working software that quickly delivers real value to customers, how we facilitate ongoing collaboration with customers, and how effectively we respond to the inevitable changes that will occur.

10. Agile Manifesto Principles 1-5

So the next two slides look at the key principles that were published in the Agile Manifesto. The first five are on this particular slide, and they begin with customer satisfaction. At the end of the day, the project doesn't exist to be on time or on budget, but to deliver working solutions that enable the customers to perform. Are we, in fact, delivering value with the solutions that we have? So really, the most important part of this is that it puts the customer at the centre of the universe. That is fundamentally the reason for any ofthese projects to exist that we want toserve customers and make them able to utilizeour solutions to gain value for their organizations. We want to be able to use change as an opportunity rather than as an inconvenience. When customers request changes, these are sources of competitive advantage, and we want to be able to leverage them and help them take advantage of them rather than perceiving it as a disruption to our existing plan. We want to be able to deliver working software solutions on a frequent basis. And one of the basic notions of Scrum sprints, for example, is that we provide potentially deliverable solutions every single round for the purpose of keeping our focus very explicitly on delivering value to the customer and getting value in their hands in a way that they can leverage and use as quickly as possible. People and development teams must collaborate and work together on a consistent, daily, and ongoing basis in order to achieve this business's success. What are the customer needs and wishes, and how exactly do the development teams, whether we're talking about developers, testers, integration, and the like, collaboratively work together to build solutions in support of the business need? Lastly, in this particular sequence, we want to be able to enable our motivated teams to be successful at creating solutions. We work very hard to hire smart and capable people. We want to create effective environments for them, and we want to create appropriate supports for them. And there's a very fundamental level of trust here: people want to do good work, and if we create good environments for them to do good work, pretty often they're going to deliver high-value solutions for customers.

11. Agile Manifesto Principles 6-12

In continuing with the agile principles The next one is that we want to be able to create appropriate environments for regular, ongoing face-to-face conversations. People simply collaborate more effectively in person, and when you create close working teams, it certainly reinforces the idea that they are, in fact, one team working toward a particular set of goals and objectives. that the primary measure of progress in any particular software project is the delivery of working software, especially working software that focuses on the highest-value ideas and objectives of the customer. Agile processes are meant to create sustainable practices. So ironically, even though we call them sprints, one of the things to keep in mind is that we want each one of these teams to have sustainable levels of work so that we can continue to deliver high-value solutions again and again and again. In order to be able to do that, we want to be able to focus not just on providing pieces of solutions, but on ongoing, continual focus on technical excellence, effective design, and effective integration. By focusing on things like refactoring within each particular sprint, one of the benefits that comes immediately is that you create solutions that are more flexible, that are easier and more adaptable to change over time. One of the things that happens within any agile methodology is to focus very simply on what has to be done. And in fact, one of the key things that we're going to focus on is exactly how it is that we maximize the amount of work that we don't have to do so that we can focus our energies on the things that are highly valuable that we do want to do. In order to create effective working teams, we want to be able to take advantage of self organization.In short, we're going to create a team, and that team is going to work in a cross-functional way to produce a solution together as a group. And that team is going to figure out together how to divide work into tasks, how to work collaboratively together, and how to produce the outcomes that are needed. Last, and perhaps as important as any of the others, is that we want any particular agile approach to be able to facilitate how our teams reflect on their performance. How do we get more effective? How can we change our behaviors to become more efficient, effective, and to deliver higher-quality results in less time?

12. Agile Methods

Agile methodologies come in a variety of flavors, including Lean Kanban Extreme Programming, Crystal, DSDM feature-driven development, test-driven development, adaptive software development, agile, agile unified process, and domain-driven design. In this particular course, we're going to focus on Scrum. But as you'll see, Scrum leverages many techniques from a number of these other agile methodologies. If you're interested in studying some of the other Agile methodologies as a follow-on to this course, I encourage you to study the Agile Expert programme as well.

13. Scrum History

The history of Scrum begins back in the 1980s with a couple of development leaders named Takyuchi and Nanakka. When Takiuchi and Naka were looking at how development teams worked at that time, the focus was very, very much like we would think of a relay race where requirements teams passed the baton to design teams, who passed the baton to development teams, and so forth. And in many cases, nobody was working on all of these pieces. and there were effectively many, many opportunities to drop the baton. If you've ever watched a real race, of course, this is what we're watching for. Are the baton passes between the runners going to be clean? And that becomes a key opportunity to see whether or not we're going to be able to successfully win the race. Instead of that approach, Tokyuchi Nanaka suggested a rugby approach that effectively made it a team game. And what we really want is to score the goal together as a team, and that requires the team to collaborate together. How exactly are we going to work together, leveraging all the capabilities of all the team members, to effectively be able to score the goal? This was expanded in 1995 by Ken Schwaberin Sutherland, and their intent was really to begin describing what would ultimately become Scrum. How do we create a lightweight approach to how we manage projects and how we do software development and lifecycle management in a way that facilitates these key principles of teamwork, self-organization, and empiricism?

14. Scrum Benefits

Scrum delivers many, many different benefits. And as we work our way through the course, you'll get to see exactly how different aspects of the Scrum approach help us to gain certain pieces of this. One of them begins with adapt ability.We want to be able to have project teams that can effectively adapt to different circumstances, changes in requirements, changes in risks, and so forth. We want to have a very transparent approach to how we deliver solutions so that our customers, stakeholders, product owners, and other development team members can clearly see who's got what. And if you've worked on a lot of projects, you're probably well aware that this is the fundamental issue in almost all of them. Likewise, as we work our way through, we want to have continuous feedback both from the team and from our customers and stakeholders on the solutions, identify continuous opportunities for improvement both of the products and of our processes, and be able to continually deliver high-value solutions to customers. Remember that working software is a primary value proposition here? I want to deliver a working solution to the customer. I want to be able to do this in a sustainable and continuous way so that my teams can continue to perform over a long period of time. I want to be able to prioritise customer wishes and needs so that we can deliver the most high-value solutions as early in the life cycle as possible. I want to be able to do this in as efficient a way as possible. But if you think about traditional project management, does the project manager actually know what the most efficient use of human resources is to carry out a whole bunch of tasks to produce a software solution? I suspect the answer to that is "no" for almost any organization. And so we want to look at more efficient ways of allowing teams to self-organize and figure out how they're going to work together to get the work done. Finally, the Scrum approach provides a high level of motivation to teams because there is a high level of trust and responsibility assigned to work teams to figure out how they will collaboratively work together to produce results for the customer. We want to be able to use this flexibility to more easily identify and resolve problems, issues, and risks, to produce effective deliverables that will satisfy customers, and to keep very focused in our minds on how it is that what we're doing supports customers and outcomes. Now, in order to get there, we want to be able to establish very high-trust environments where customers and other stakeholders have confidence in the scrum team to produce and deliver those solutions. And the scrum team in turn works well together to produce and carry out that work. The notion of collective ownership effectively means that the team wins or loses together. And so it's very important as a fundamental part of Scrum and self-organization that the team hold one another accountable for being able to produce the results the client needs. As we get better at this, we increase our ability to take on this type of work and produce results in a more efficient manner, which we'll refer to as high velocity. And then last, and certainly not least, because we're providing a lot of opportunity for conversation and interaction, there's a tremendous amount of opportunity to identify innovative solutions to problems and improve overall practices.

So when looking for preparing, you need GAQM CSM certification practice test questions and answers, study guide and complete training course to study. Open in Avanset VCE Player & study in real exam environment. However, GAQM CSM exam practice test questions in VCE format are updated and checked by experts so that you can download GAQM CSM certification exam practice test questions and answers files in VCE format.