Pass Your PMI-ACP Certification Easy!

Prepare with top-notch PMI-ACP certification practice test questions and answers, vce exam dumps, study guide, video training course from ExamCollection. All PMI-ACP certification exam dumps & practice test questions and answers are uploaded by users who have passed the exam themselves and formatted them into vce file format.

Agile Principles and Mindset

6. Exploring the Agile Methodology of Scrum

Are you ready to get a little bit deeper in our discussion on Agile? Well, I know you are. We're going to talk about some of these different methodologies over the next several lectures. Our first one is talking about one of the most popular Agile methodologies, scrum. So we'll look at this methodology that you'll need to know a lot about for your PMI ACP exam. Reviewing scrum. So what is scrum? Well, scrum really is easy to understand, but it can be difficult to master. Scrum is really a rugby term. Scrum uses this methodology, which we're going to look at in this lecture, called the Scrum Framework. The Scrum Framework is a set of practices, roles and responsibilities, events, artifacts, and rules. So it's kind of this model that we adhere to as we move through the project. And we'll be looking at all of these different components in this lecture. There are three pillars or values that you should know about scrum. It's transparency, inspection, and adaption. So first off, transparency really begins with a common understanding of what done means in a scrum project. So what does "done" look like? And the understanding that you have of what I have done, what I have for the team, and what the customer has are all the same. So we're all transparent about this common goal of what "done" means; what equates to "done"?It's very important. Inspection—this is the review of the project to determine the completeness of the project. So when there are variances, we do root-cause analysis. So, in root cause analysis, we're looking for causal factors that have contributed to why we have not reached our goals in an iteration or the project as a whole. And then adaptation is when we make adjustments. We adapt to certain scenarios, so we make adjustments to the scrum process to mitigate problems or bad trends. A real common adaptation is that people take on too much work; they think they can get done more than what they're really capable of doing. So we adapt and overcome. So what does scrum look like? Well, this is the big picture of scrum, and we'll be talking about all this stuff in this section. But let's just walk through this flowchart of what equates to a scrum. So we'll start over here on the left with the inputs from executives, the project team, stakeholders, customers, and users. So all these inputs are what we want in the software, and those all go to the role of the product owner. Now, the product owner, this individual, owns this list of requirements, and the owner is going to work with the team and may also work with some key stakeholders about prioritising this list of requirements. And this list of requirements is called the product backlog. So a lot of time these items in the product backlog are called features, recalled user stories, or just stories. all the same thing. It's what's in the product backlog. Now, if you notice one, two, and three there, they're kind of in that orange colour in the product backlog, and the others are in blue. Well, that feeds into the next point. At the sprint planning meeting, the team talked about the development team here. They choose from the top how much they believe they can accomplish in a sprint. So of these eight items, in this example, how many of these can we actually create in a sprint? So that's the sprint planning meeting where they examine the prioritised list of requirements and they begin to think about, well, what can we really do? and we'll talk more about that process. It's really interesting. We'll talk more about that process coming up from the sprint planning meeting. They have their selection of what stories they're going to work on, and then they move into the start of the sprint. Now the sprint is typically four weeks, but it could be between one and four weeks. Typically it's four, but you can do anything. You can make it two weeks or three weeks if you wanted, but they look at those requirements and then they begin to get to work. And so they have a sprint backlog. All of the stories that they're going to accomplish over the next sprint are called the Sprint Backlog. The Sprint backlog contains assignments or tasks for the various developers. So the developers get to work on those items, and that's the sprint for the next four weeks as they only work on those from the Sprint backlog. Now, you can see it makes this big loop here. Before we complete the loop, we have a little breakout up at the top. Every day, every 24 hours at the same time, there's a daily scrum meeting. This is a 15-minute time box meeting, 15 minutes maximum. And in this meeting, the team will say or answer, "What have you done since yesterday?" What are you going to do today? And are there any impediments in your way of getting things done? And so it's a daily scrum meeting, but it's really short and really fast, and it's just for the development team. And then you see the scrum master as the person facilitating that meeting. Now, based on the outcomes of that meeting, the scrum master will update either a burndown chart or a burnup chart that is very similar. A burndown chart could be okay. We have 80 things to create. And as we start accomplishing these different stories, it feels like we're burning down the number of items we have to create. The burn is just the difference. It's the exact opposite. So it's the number of items completed. And as you get closer and closer to completion, there is the bar. The histogram gets bigger and bigger and bigger. So it's a burnt-up chart. Let's do a little loop in our sprint here. So we finish the sprint somewhere between one and four weeks, depending on what is standard for that organization. And then that creates the finished work that you see as output from the sprint. a little box there. Now with the finished work, we have a Sprint Review and a Sprint Retrospective. So we'll look at those that come up. I won't get too far ahead of myself, but it's a chance for the product owner, team, and customers to discuss the Sprint. The team can then reflect on how well Sprint worked for them in terms of taking advice from the product owner or customers. So we'll look at that in more detail coming up.However, that is the big picture of Scrum. That's what it is. A scrum sprint. As we saw in the last slide, it's a timebox iteration for project work between one and four weeks. A time box is simply a scrum with a set duration. Sprints, like I said, are between one and four weeks. Most of them are four weeks, but you could make them three weeks if you wanted. Now, during a Sprint, there are no changes allowed that would affect the goal of the Sprint. I'm going to hop back. So what we're talking about here is that there are no changes allowed that would affect the goal of the Sprint. Our team was assembled with the product owner as one of the most important considerations. And so now we're starting the Sprint Backlog based on those high-priority items. So if the customer says, "Oh, I want these requirements as well," they typically do not go to the top of this queue. They can be prioritised with what's left, but we don't interrupt the current sprint. It continues on. The only exception to that rule is: move back to the next slide. The only exception to that rule, if the projectgoals, if the changes make the Sprint goals obsolete. So if someone adds a new requirement that makes what you're currently working on no longer valid, then you can cancel the Sprint. But only the product owner may cancel a Sprint. It's pretty rare. You don't want this to happen too often. So what we're talking about here, though, with no changes made, is some collaboration where the product owner agrees to not change the priority of what's currently in motion in the sprint and the team agrees to deliver those user stories in a deliverable at the end of the sprint. So there is some collaboration there between the product owner and the development team. If a Sprint is canceled, what happens here? The backlog items are returned to the product backlog, assuming they're still needed within Sprint. You have several activities. You have the sprint planning meeting; you have the actual development; you have your daily scrums. And then at the end, we have our Sprint Review Meeting and the Sprint Retrospective Meeting. You've been introduced to some team roles in Sprint. You have the scrum, Master. This is the person responsible for communicating the Scrum methodology and then ensuring that the methodology is used effectively. So this is the project manager, but in Agile it's called the scrum master. So they work with the team, develop the Scrum methodology, and then they make sure that everyone's playing by the same rules. The product owner was the individual who was prioritising the backlog. So it's moving those high-priority items to the top of the backlog. The development team—these are the software developers who create the product through Sprint—is So the people actually doing the work There are some Scrum activities we want to be aware of. So we have these events or ceremonies, and there are five of them. That's what the product owner does: refine the backlog of products. The Sprint planning meeting is done with the product owner and the development team. The daily scrum is led by the scrum master, and the participants are the development team. And then we have the Sprint reviews and the Sprint retrospectives. One activity I've mentioned a couple of times is this idea of grooming the backlog. This is what the product owner does when he is reprioritizing the items in the backlog. It's also called backlog refinement. So this is any type of reorder or adjustment to the prioritised features or stories in that backlog. Now, the entire project team can work with the product owner on this, and typically they do to help prioritise the backlog. this backlog of grooming. The Sprint Planning Meeting is when the Project Team meets to discuss the goals of the upcoming Sprint. The team discusses how the work will be accomplished; the product owner reviews with the team the items in the updated backlog. The development team then defines how the work will be done to achieve the sprint goals and how they will be achieved. And then the development team is are self organized.This is a real key that we'll see coming up in terms of leading our team or allowing their team to emerge and lead themselves. the daily scrum. In scrum, this is a critical component. This is a 15-minute time box meeting. happens every day at the same time. It's also called a "standup" meeting because you're supposed to stand up when you do. This. It helps keep the meeting short if everyone's standing. The Daily Scrum is held every day at the same time and location, has the same agenda, and is just for the development team. So what's the agenda of the Daily Scrum? Pretty straightforward. What have I done since the last Daily Scrum? What do I plan to do today? And are there any impediments to my progress? Anything holding me back? As a result, this is an opportunity for the ScrumMaster to demonstrate servant leadership by removing impediments. They remove trouble for the team. It's possible that you have a really large Agile project, so you might break up the team into multiple teams. And so if that happens, you have a scrum of scrums, where you could have one individual from all of the different agile teams come together and have a scrum. And if it's really big, you could have a scrum of scrums. That's just kind of ridiculous, but it could happen. Now, when you have a scrum of scrums, four questions are answered pretty similarly. What has your team done since we last met? What will your team do before our next meeting? Are there any roadblocks in your team's way? And will your team put anything in another team's way? Scrum, a scrum of scrums kind of fun to say. All right, let's talk about Sprint reviews versus a Sprint retrospective. A Sprint review happens at the end of every Sprint. So who's going to be in the Sprint Review? Well, you have the development team, the product owner, the scrum master, and sometimes you might have other project stakeholders. The development team will demo the work that they've created in the last sprint, in the last increment. The group will decide if much has really been accomplished. So this gets back to that transparency where we all agree upfront what the definition of "done" is. And then the development team and the product owner will discuss the Sprint and the remaining items in the product backlog. So a Sprint Review is the product owner, the development team, the scrum master, and other project stakeholders, and then we do a demonstration. So where will demonstrations happen in a Sprint review? A little hint there. In the Sprint review, demonstrations happen. So what happens in the retrospective? In a retrospective, it's the development team. So it happens after the Sprint review, but the next Sprint planning session usually happens right after you get done with the Sprint review. So this is a meeting to inspect the team's work and adapt lessons learned and opportunities for improvement that we can implement in the next iteration; that's what we're after. So it's a review of the product owner's feedback about the last iteration. And it's an opportunity to improve upon your approach based on that retrospective and the last sprint. So based on what you've learned today, what are you going to do about it in this next sprint? Now, as a scrum artifact, these are things that the sprint creates. So you have a product increment. It's the outcome of your iteration. It's what you are demonstrating. It's a chunk of the overall project work. The development team and the product owner have to reach agreement on what "done" means for an increment. Then we have the product backlog. This is also a Scrum artifact, the product backlog. This is really the source that the product owner owns for all product requirements. The product owner remembers, sorts, and prioritises all those backlog items. So that's the priority. That's where the value is that the team aims to create. The development team always works on the most important items first. the prioritised items in the product backlog. Now, the backlog is something the product owner always has to prioritise before the current sprint. So you really can't start your current Sprint if the backlog hasn't been groomed and updated. Backlog refinement, or grooming, is done both by the product owner and the development team together. They don't do it individually, they work together. And then the team will estimate their capacity to tackle the items in the product backlog. So, in other words, how many can we do in the next iteration based on their size and their features and what the thing is? and we'll talk about that when it comes up. We'll talk about estimating items. Now, the last thing to talk about in this lecture is the Sprint backlog. Recall that we had a sprint backlog. It's very similar to the product backlog that's also prioritized. The Sprint backlog is a subset of the product backlog. The Sprint Backlog serves as your goal for your current iteration. It's all the stuff you're trying to get done. The Sprint Backlog is a view of the work to be accomplished in the current Sprint. And then the sprint backlog is updated and refined by the development team. All right, good job. lot of information here. Let's keep moving forward.

7. XP

Another agile methodology you should be familiar with for your PMI ACP exam is XP. XP for of course, Extreme programming. So, XP, you will have some test questions on this approach. It's not going to be a tonne of test questions, though, so it's probably the second to Scrum. So if you've not worked with XP before, don't worry; it's very similar. I know there are some differences for those of you who use XP every day, but it's similar to Scrum as far as your exam goes. So we'll take a look at the XP approach and what you need to know to pass the exam. So here is XP at a glance: the different phases of XP. We begin with exploration. In exploration, we have stories; we have a backlog, just like we do in Scrum. And then we have these opportunities for architectural spikes. So a new term for you is architectural spike," which is where we do a spike to go and set up the architecture. But what's a spike? It's a short iteration of work—a very tiny amount of work just to get things ready to set up the architecture and prove that the architecture will work. Now, tied to that, you might have a system metaphor. A metaphor is just a way to explain something like how the system will be as solid or as reliable as the email server. So give someone some context when you say it's going to be very reliable. So use a metaphor, just like a simile that is as strong as a rock. So a metaphor is a way to help communicate, especially to your customer, what you're trying to explain technically. Then we get an iteration plan where we have our stories, and then with our stories, we begin to create estimates of how long it will take a story to be completed. Now you might have some spikes, which are known as architectural spikes or risk spikes. And a risk spike is a short period of time to go and test to see if the risk can be mitigated or eliminated, or if it is likely to occur. So you need to plan differently. From there, we go into the actual iteration. In the iteration we go from pair programming to acollective code base to testing back to pair programming. So you have this cycle within this iteration. Now let's talk about pair programming. Pair programming means you have two people sit together, and one person is actually writing the code, and the other person is checking the code as it's being written. So it's a collaboration. So you're paired up together, and then those people switch roles. Occasionally associated with paired programming. We have testing, and we have the actual development. Continuous integration happens frequently, not just at the end of the day, but frequently. You check in your code, and it automatically goes through some type of unit testing, and then it is integrated into the collective code base based on the collective code base. Then you do the actual testing to see if it passes the test scenarios that have been written. If it does, you move on to the next piece of the project. If it doesn't, you can begin making adjustments and correcting the problem so that it will pass the test. At the end of the iteration, we move into customer approval, and that's where we have our UATs or our acceptance tests. User acceptability testing or our acceptance test for the work and then once the test has been approved, it is released. We have small releases to a population, a release server, or a sandbox where the work that we do begins to accumulate. So the small releases, though, are iterations of releases. XP's core values are simplicity, reduction of complexity, getting rid of extra features, and reducing waste. So that's a goal for XP. Find the simplest thing that could possibly work. Communication is a core value in extreme programming. As a result, we want to communicate critical information throughout the project management process. So it's one of our values in Extreme Programming as well. You ensure that the project team members know what is expected of them. You ensure the project team knows what other people are working on. You don't want two people working on the same piece of the project being in conflict with each other and not realising it. And then the daily stand-up method is a great way to communicate every day with your team. Of course, when we communicate, you're likely to have feedback. Your team needs feedback early in the project. So failing fast is one approach to getting early feedback. Feedback gives the team an opportunity to improve upon the project. Another value in XP is courage. Developers work. We have that collective code base. It's entirely visible to other people on the project team. Team members are going to share code. They are responsible for that pair of programming. So it's all out there in the open. So it takes a little bit of courage for other developers to look at your code, and then you can correct other people's code because it's shared; it's collective. But we also need respect, and team members must respect one another. You don't criticise other people because you respect each other. It's okay to train or to teach one another, but you're not being critical of each other. Everyone is responsible for the success and/or failure of the project. Now everyone can work differently, but they must work together. Some XP team roles Here. You have the coach. This is the project manager. You have a mentor, a guide, a facilitator, and a primary communicator. It's similar to Scrum Master, but the next P is called the Coach. Then you have the customer. It's the individual who provides requirements, priorities, and direction for the project. This is comparable to the product owner, the programmers. These are the people writing the code. This is your development team. and then testers. They define and write the acceptability test for the whole team. There are some core practises here. The XP team members should be colocated. They should all be in one spot. We need generalising specialists, not role specialists. We talked about this earlier. It means that a person can participate in more than one activity in a project. that you don't have to be just a developer or just a tester. That you can play multiple roles, which helps eliminate bottlenecks and promotes efficient and effective information sharing. Now in XP, when we go about planning, we call it a planning game. So planning games are just planning activities. It just sounds more fun. Release planning involves the release of new functionality. Typically, no more than one or two releases per year occur. The customer will outline the functionality that they want from the next release. Developers will then estimate the difficulty of building in that functionality. So it helps to create an estimate of time, energy, and effort to create that thing that the customer expects from the next release. Iteration Planning It's really similar to Sprint planning. Iteration planning you do atthe beginning of every iteration. The customer defines the functionality they want to see. By the end of the iteration, the development team will estimate the difficulty of building in that functionality in the current iteration. So you have requirements from the customer, and notice that it's the team responding on the feasibility. So how much and how long will it take to create that thing and create that functionality? Small releases are another core practice. You take your release and put it into a test environment. So the sandbox or whatnot, it increases visibility for the customer because you can say, "Look what we've done." We have these increments here. It may not be ready for an actual release, but we're getting there, and it shows progress. And then it helps to deploy working software to end users because you are integrating that code as you create new features throughout the iteration. Customer Test: This is really the definition of the required functionality. It's a description of one or more test criteria for the software to be considered working. It's like the idea of what is done is that we all agree this is what it takes to pass the test. And so it's the test criteria that will equal working software. And remember, working software has value. Collective code ownership is the idea that anybody on the development team can improve or make changes to the code. So multiple people are working on the code throughout the iteration. So this helps with defect resolution in discovery. Knowledge is shared. It's not isolated. So we get rid of those silos, and we have a collective of developers. A collective ownership of the developers' code standards is defined by the development team. It's a way for the team to say, "This is how we're going to develop." This is the approach that we'll take, and we will all adhere to this standard. So because so many people are involved in writing the code, this gives some consistency when you go about writing the code because you want everybody to have the same approach and probably the same feel to how the code is developed. And so this is the idea of a code standard: it provides consistency as you develop and integrate code throughout each iteration. And the thing about code standards is that they are truly for the entire project; they should not change from iteration to iteration. So it's defined upfront, kind of like part of that architectural spike could be defining code standards. But if you've been doing this for awhile, maybe you have a code standard that you use in all of your XP projects. So it could vary for each projector or it could be a universal standard. It just depends on how your team is formed, if they've worked together before, and what you're developing; that could influence your code standard. We have this concept in XP, as well as the sustainable pace that we discussed previously. We don't overwork the team. We can't say everyone has to work twelve hours every day for the next six months. That's not sustainable. So productivity is optimised at a sustainable pace. That consistent overtime over long hours is just going to burn people out. It's really not sustainable. It's not conducive to a good XP environment. Metaphor. We talked about this earlier. Metaphors and similes help explain designs. So metaphors help communicate the software to the customer. You could say this transport is like when the mailman delivering the message takes it to a central location and then another mailman delivers it to the address you want. Whatever, I just made that up. but it's a metaphor to help communicate what's going on in the software so the customer gets it. They don't need to know all the intricacies of what you do as a developer or what your team does as a developer. But a metaphor helps explain it. probably going to see that on your test. Little hint. Continuous integration. This is the idea behind checking in your code frequently throughout the day. So you compile code frequently. Then it's compiled and checked into a code repository. That collective code ownership kicks in here, and then you have an integration test that is run automatically. Does it pass or fail? So will it integrate? and those are good for immediate feedback. And if it fails, you've got a problem. You need to go through your code, fix it, and check it in again. Acceptance tests are written first in test-driven development. So you write down what the acceptance tests are prior to developing the new code. Now here's a shocker. Your initial test will fail because your code hasn't been completely written yet. So when the code has been written correctly, then it will pass the test. And this is the idea of test-driven development. I mentioned this term a couple of times, the idea of "refactoring." It just means you clean up the code—you get rid of waste, any type of duplicate code—to get rid of things like lowering your coupling or increasing cohesion. That's all there is to cleaning up code. You won't need to know the terms coupling and cohesion for your exam; just know that refactoring is the process of cleaning up your code before checking it in. It adheres to that code standard. So this is something you'll most likely see on your exam. So here's a little exam tip. Embrace the idea of refactoring. It cleans up the code. It makes it simpler, easier to understand, helps you adhere to standards, and then it helps with future work. You may have to come back and edit and update this code someday. So it's nice and clean and easy to work with. This is also part of getting rid of waste on value-added. A real theme in XP, though, is simple design. Remember the question: What is the simplest thing that could work? Now as I mentioned, simple doesn't mean easy really. It means clean, precise, and exact. Simple design is also a risk mitigation approach. Now risk mitigation, just so we're all clear, mitigationis anything that you do to reduce the probabilityand or impact of a risk event. So by making a simple design, you are reducing the probability, or impact, of your code failing. If you've got really messy code, it's going to be hard to figure out what's wrong with it when the code fails. But if it's clean, simple, and direct, it's easier to fix; it's easier to see what the problems are. And then finally, just to revisit this very important topic here about pair programming, One person writes the code while the second person reviews the code. These two people can change roles frequently, and then the pair will catch mistakes more quickly, which speeds up productivity. So pair programming is index p. It's a sign of bravery; it's a sign of collective code ownership. Pay attention to that guarantee. You're going to see it on your exam.

8. Lean in Software Development

Another Agile approach that you should be familiar with for your ACP exam is Lean. You've probably heard of Lean manufacturing, but we can apply some of the same principles to Agile. Now, I don't expect you to have a lot of questions about Lean on your exam. You've probably got to have just a few where the bulk of your questions are going to be more about Scrum and XP. But lean is still pretty popular. So you are going to have some questions, and it's not a difficult concept to learn. So let's hop in and talk about lean. Lean, as I mentioned, really began in the manufacturing environment. It's really from Toyota. In fact, it was once called the Toyota Production System. The main principle of Lean is visual management. So we use visual management tools. Lean is a great example of low-tech, high-touch because it's visual and easy to do, as you're going to see. And it's all about seeing what's happening with the project right now. What's on the agenda? What's currently in the works? So it's just a real quick way of seeing what's happening. We'll talk more about that later in this lecture. Lean is based on customer requirements, customer desires, or customer feedback. It's all about customer-defined value. Another facet of Lean is learning and continuous improvement, where we learn what is or is not working and adjust accordingly. So if something is working, how can we repeat that process and get more of it? If something is not working, we find some waste. How do we remove that non-value-added activity? There are seven lean core concepts. There are two slides in this lecture that I really want you to pay attention to, and this is the first of two. And then the next slide we look at will be the second. If you really want to kind of conquer Lean for your exam, these are the two slides you need to know. So, seven lean core concepts. Eliminate waste, empower the team, deliver fast, optimize the whole process, the whole team, and the whole project. Improve quality by deferring decisions and amplifying learning. So those are the seven Lean Core Concepts. Now there are two of these that you might have some questions about. Maybe you have questions on all of them, but most people have questions on two of them. What does it mean to optimise the whole Optimizing the whole implies that you are constantly improving, that you are constantly looking for opportunities. As I mentioned, if something's working, how do we get more of that into the project? And if something is not working, how do we get it to? How do we take out things that aren't working or improve our velocity and get rid of bottlenecks, or at least improve the bottleneck? The second thing is to defer decisions. Well, what do you mean by defer decisions? Why would you put off a decision? Well, to defer a decision means that you wait until the last responsible moment to make a decision, because we know change is going to happen. We know there are going to be fluctuations in the project. And so by waiting until the last responsible moment to make a decision, it avoids having to deal with that change or be constantly adapting. So here's a great example. Imagine you're going to redesign your kitchen. There are all sorts of decisions to be made in the kitchen. So on day one, you begin doing the demo, and you're going to tear down a wall, and on and on it goes, and the tile, and so on. Well, on day one, you don't need to know what the pools are for, the cabinet door, or those handles on your cabinets. You don't need to know that today. Now we have to know it, let's say, by day 15, or else it's going to cause the project to be backed up. So rather than deciding and going out and purchasing the handles for the door on day one, you wait until, say, day 13, for example, a couple of days before to make sure you can get the handles that you want. If you decide and go by the handles on day one for something you won't need until day 15, the project work or cabinet configuration may change, or your significant other may decide, "You know what, instead of these white handles, I want these brushed nickel handles." So now you've got a decision that's been changed. So by waiting until the last responsible moment, you can then make a decision and go with that decision at that time. So, yes, you know, you need the handle, but you don't have to make a decision on what that handle is until the last responsible moment. And yes, that's a key phrase there. All right, so these are the seven Lean Core Concepts you need to know for your exam. Now, the second most important thing about Lean is: what are the seven wastes that you find within Lean? I suppose we don't find them in Lean. You're finding them in your project. These are things that we want to get rid of. So really pay attention to these as well. partially done work, extra processes, extra features, task switching, waiting motion, and defects. All right, let's talk about these seven ways of looking at partially done work in Lean. There is only value in working software. Remember that the same is true here in Lean. So there's no value until something is done. So half-finished work is truly waste. So those parts of your system, or of the app that you're developing, or whatever you're creating in your project, have no value until each of those is done. So maybe you've seen this where you have some pieces of the software puzzle that are waiting for a decision, or you put those away and move on to a different priority in the project. Well, that's wasteful. so you want to start and finish the work as planned. So partially done work has no value; it's just extra processing. I don't know about you, but this is my number one pet peeve in project management. Our organisation has processes that we all have to adhere to, but no one knows why we do it. So why do we have a pre-kick-off meeting? Why don't we just have a kickoff meeting? Why do we have to fill out all these forms that go in a folder and are then archived so no one ever looks at them? So any type of process that really has no value and is just extra is a waste. Extra features. So if you're building a piece of software by adding in extra buttons, features, and capabilities that the customer did not request, that's gold plating or scope creep; basically, it's nonvalued and a waste. The customer did not ask for it. It wasn't in the original requirements. It's not in our product backlog. That is a waste. Task switching, where your project team switches from one task to another, either within your project or from your project to outside your project, So task switching stops the momentum of the project. And then when you come back to doing that task, you have to think, What was I doing here? And then pick it up again and get moving. You know, the idea of multitasking is wasteful. There's no such thing as multitasking. You can really only do one thing at a time. Have you ever tried to talk on the phone and send an email? Neither one is really good. When you switch tasks, you are not present in the task. and that's wasteful. Waiting, of course, is just a waste of time. If you're waiting on a colleague to make a decision or to finish the puzzle piece, that's a waste of time. Motion is a waste of time. So motion is any type of activity, like a handoff or a transfer, or if you have to physically take something somewhere or upload something, who knows? So a lot of those motions are wasteful. Don't add value. Defects, of course, are a waste. So a defect is an error that causes rework and can cause confidence to wane in your stakeholders. If the defect escapes all the way through testing, it is an escaped defect. So defects are wasteful. We want to get rid of defects. So those are the seven Lean wastes. On the previous side, we had these seven Lean Core concepts for your exam. When it comes to Lean, these are the two things I would focus on. Let's take a look at what lean looks like. So every Lean project is going to be different, of course, but this is just an example of a timeline or a product development in Lean. So you have these different phases where they have a project sprint and you have the alpha, the beta, and the floor release notice. Within each one of these phases, we have these blue and yellow iterations here. So this shows the involvement between the project team and the client team. So we have the people developing the work and then reviewing the work. And then you notice we have some client QA. Well, PMI calls that our stakeholder validation, where they inspect the work, and so that's why the client is doing that here. So you are going to be tested on this. It's just to kind of give you an idea of what Lean looks like—that you're removing waste through phases, but there are iterations of activities in each phase to allow the product that you're creating to move forward in your production. A can band board is primarily used in Lean, but it is very similar to what we have in XP and Agile. The idea of a "ban board" is a Japanese word that means a sign board. And then what happens on the sign board? There are categories of work for each stage of the production. So here's what a Canband board looks like. So it goes from left to right, and it's colour coded.The best way to do this is to imagine a big white board and having these little sticky notes, where each colour of the sticky note represents a different component. So you can see in the to-do, we have a feature, a user story, a task, and a defect. So just by colour coding, and then as it moves through the various stages of this particular project, they're doing planning, developing, testing, and deploying all the way to completion. So as an activity, I shouldn't say an "activity," as one of these components is complete. If it's done with planning, then it moves on to development. When a component is done in development,it gets pulled into test, done withtesting, it gets pulled to deploy. When it's actually done, it gets pulled into being done. So a Canban board also uses that term about being pulled along. So as vacancies open in each one of these categories, the next available item, user story, defect, feature, or what have you gets pulled into that category so it can go on the ban board. I can very quickly look and see, okay, what's in development right now. Now what's on these sticky notes? You can't really see it here. It's not written on them, but imagine these are different-colored sticky notes. If we walked up to this whiteboard and looked at it, each one of those would have a little written thing about—well, what is this task? What is this defect? So it's more than just a colour code, actually. You would write on there what that feature is and stick it in the to-do category. And again, this is prioritised like we saw in Agile, and it moves along all the way into Done. So this is where we begin to get the idea. We're going to see more about this idea of your velocity—how quickly you can do something—and we're going to talk about your throughput. How long does it take to go from "to do" all the way to "done"?So we'll have some terms coming up that are tied to this. But this is a really great example of low tech.So there's no technology, there's no software, and it's high touch because you're touching these to move them along. so it's very simple to use. Everybody can use this. You don't have to have a copy of Microsoft Project or Visio or whatever. It's all just a big whiteboard. There are five Can Ban principles, and you probably already know what they are. You can visualise the workflow; you can just look at this and see you go from left to right. It limits the work in progress. The whip, because we don't want to have too much stuff in development, manages the flow as one activity moves along. When it's done with the planning, then it can move into development. When you're done with development, it moves into testing. So you can manage the flow of each component all the way to done.It makes process policies explicit. This is the process to do, plan, develop, test, deploy, and be done. That is the process. It's very simple, it's not complex, it's very easy for anyone to grasp, and it allows us to improve collaboratively. So what's the collaboration here? We're collaborating with our product owner, customers, and any stakeholder so that we can show what's going on in the project at any given time just by looking at this. So this is a key thing that you want to know for your exam. You're probably going to have a few questions about CanBan boards. Now just to recap, according to Ban, it's a full system that moves work through development. The development team completes an item, and then the next item in queue is pulled into the next stage of the process. Nobody can box and ban. It's just you finish it and move on. You finish it and move on. Each stage of the project can only have a limited number of items. So if we go back and look at our Can-Ban board, we might say you can only have six items at a time in development or maybe two items at a time in planning. So it helps to limit the work in progress. It will also help us see whether there are bottlenecks; if we say there can only be six items in development and there can be 20 items in planning, well, then planning is not the bottleneck. Development is. As things begin to pile up against the next stage, it either hints, doesn't hint, or shows us where the bottleneck may be. But this is good, though. It limits the whip, which is what we want to do, because there are only so many items we can do before the work moves from left to right. Here's an exam tip for you. Banana boards are pull systems; they pull items from left to right, and they help to visualise the project. We can see from that board exactly what's happening in the project. Can-ban boards are sign boards. And again, Kanban in Japanese means cards you can see, which is what we've experienced here. Now, within Lean, there's a law that you'll run into from time to time. It's called Little's Law. Basically, what Little's Law tells us is that the duration of a queue is proportional to its size. So the more things you have to do in the queue, the longer that queue will take. Make sense? I think that's pretty obvious. You want to go onto the highway at rush hour; you've got cars backed up forever. You get on the same highway at three in the morning; there's nobody around, and it's much easier to fly through that interstate. So by limiting the work in progress, then, teams will actually complete their work faster. So the more things that are on the list, the longer it will take to get everything done. If you limit the items in Whip, then you're going to move through those items more quickly. This is a real study. I'm not going to go into the whole picture here. But this is from the Wall Street Journal that they got this idea from about Little's Law, which basically says how many people are online will reflect how long you have to wait in line. And so the same idea is work that enters the queue. The more items you have in a queue, the longer it takes to do each item. All right, so on your exam, you're probably going to have maybe one question about Little's Law. Basically. No. The longer a queue is, the longer it will take to complete the items within that queue.

9. Other Agile Approaches

in the PMI ACPE exam objectives. You'll see there are some other methods of Agile approaches other than just Agile, XP, and Lean, and that's what we're going to look at in this lecture. Now, you probably aren't going to have very many questions at all about these different approaches to lean. You're going to have some, but not many. So these are pretty easy to grasp. So we're going to walk through these. Now, the first is feature-driven development. So feature-driven development is an approach to developing software where the development team creates a model for the product and then creates a feature list and a plan on how they'll implement and create those features. The team moves through the design phase, where they'll build the directions for the product features, and then they actually go into development, where they're going to design the features in builds by features. In other words, the design will be done feature by feature. So it's incremental, much like Agile is, but the focus is more on the features of that piece of software they're creating. So some characteristics here of feature-driven development are: domain object modeling; developing by features; individual class codes; ownerships; feature teams. We still have inspections and UAT and things like that. So we're testing configuration management, so we have a little bit more documentation and consistency. You have regular builds so that you compile your code to make sure it's working. But we also need visibility. So it's kind of like a can board for visibility of progress and results. Now they may not use the Canvan board; they may be using what's called an information radiator. So it's a term we really haven't seen before. Information radiators are things like signs or posters. even be a monitor that gives a quick report on what's happening in the project. So how many activities are we done with? How many do we have left to do?What's our work in progress? What's our risk? Burn down. So things like that are in an information radiator, but they're visible; anybody can walk by and look at them. So a lot of times these are printouts. They just stick them up on the wall, and anybody can see them. Here's a quick example of a feature-driven development: You can see that you develop that overall model. Then, based on that model, you have your features list, you plan each feature, and then you go into designing and building. And then you can see there are iterations design by feature" and "build by feature." In a way, this is kind of a hybrid between a predictive and an agile approach. So it's not just a waterfall approach because we have these iterations, but a lot of it is because it's featured and it's planned up front. It's not something you're going to have a whole lot of test questions on, but you should be familiar with it. Our next flavour to look at here is the dynamic systems development method At DSDM, we prioritise business requirements. Why are we developing this solution? Our goal is to deliver on time. We collaborate with the customer and end users. Any stakeholder really never compromises quality, and quality is defined by business needs. Why are we doing this? We build incrementally from the foundations we develop iteratively, with constant communication and clear communication. We should say honest communication, and then I want to demonstrate control by showing that work is getting done, that we're chipping away, and that we're burning up on the number of activities we have to do in order to meet the business need satisfaction.Here's a little model of a business need. You can see all these different arrows going different ways, but you can see the business need based on the feasibility study or a business study is at the top, and then it's going to go to the left. So we have our functional model iteration, and you can see those iterations there, and then it's going to come down to design and build iteration. Now notice you can go back and forth between our functional model and our design and build, and at some point we go to the upper right with implementation and then we come back if we need to. We can go back into our planning, so there's an opportunity here for a cycle, but at some point we go back and prove that what we've created is what was promised. Now Crystal is you might have a couple ofquestions about Crystal but it's something you're not goingto see a whole lot of it's methodologies thatare colour coded and so we'll look at thesecolor coding in just a moment. The methodologies are appropriate for different criticalities andhow big your team size is means youhave to have a more methodology. Criticality is also about the impact of a product's design. So the Crystal methodology is really one of the most lightweight, adaptable approaches to software development. Crystal is really comprised ofa family of agile methodologies. We have these different flavours crystal clear, crystal yellow, crystal orange, and on and on. So, why are you using Crystal Clear, Yellow, Orange, or Red, or whatever the factors like team size, system criticality, and project priorities all drive which flavour of Crystal you are using? So here's what I was talking about thesedifferent colours The Crystal Family addresses the realisation that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project's unique characteristics. You may have a couple of questions, or maybe just one question on Crystal, so you don't have to study this one. Familiar with what I've shared here?

10. Putting the Agile Process in Action

In this lecture, we're going to take a look at how Agile works. so agile in action. Now this is just a really vanilla approach to Agile. Your organisation may have done some process tailoring, so this may not look exactly the way that you do it, but it gives us a good idea of what expectations are for your exam. So let's hop in and just take a quick look at how Agile works. We begin by creating a product vision. So this product vision is how the product owner sees the end result of the project. So what is the thing that we are creating? The product, of course, has to be in alignment with the company strategy. And so what we're going to create, the organisation wants it; they need it, and we can visualise it. This helps us to have a shared vision of what we are about to create. From the product vision, we'll create a product roadmap. It's a visualisation of product features. So the product roadmap is really the product division. If we were to decompose that as a whole again, this is done by the product owner. So here's an example. I just found online a product roadmap that has some different deliverables. What these various color-coded items are for, and when we can expect these deliverables and features to be completed Now again, that's a really high level. It's not something you have to do. This is more of a high-tech tool. You could do this just on a whiteboard as well. But what I want you to take away from this is the product roadmap. It shows the product that visualizes, based on big categories or priorities, how we're going to get to the end and actually create this thing. Release planning is something we do in Agile as well because it specifies what we'll be releasing in the project as it progresses. So it's all about product functionality, and then priorities are assigned to the product features from most important to least important. And then those features, that'swhat becomes the product backlog. that queue of items that we prioritise and then go about creating. Again, this is owned by the product owner. Iteration planning is where the Agile project manager and the project team begin to get involved. They begin to take ownership of the backlog features. So goals are established for the current spirit, or iteration goals are based on the product backlog that has been prioritized. And then we pull from that prioritised list of items that we'll do in the current sprint. The product owner and the development team work together to prioritise features, and this is done at the start of each sprint. So we do iteration planning before we go in and get to work. That makes sense. The Daily Scrum This is that stand-up meeting that we talked about earlier in this section. So they meet each day. It's a 15-minute meeting each day. And then they answer three questions. You being the development team, what have you done since the last daily scrum? What will you do today? And are there any impediments in your way? The Sprint review is where the development team provides a demo of the product. So this happens in the Sprint review. at the very end of the sprint. The development team shows what they've created so far. This is being discussed with the product owner and the development team. So they own the stage. They're doing the presentation. Now. The Sprint Retrospective is where the development team and the scrum master master that. They look back at the last sprint. So what did we do well? How can we improve upon that? How can we maximise the good thing that we've done and continue this good thing into the next sprint? But also, what didn't work well? So how do we refine our work in the next sprint? Now they're going to try to trip you up on review and retrospective. A retrospective is a look back. So we're looking back at the last sprint, which was done with the development team and the scrum master. The Sprint review is about reviewing the work that you've done. So retrospectively, you look back at the review by Scrub Master and the project team or the development team review.You're reviewing the work that's been created and that was done with the product owner in the retrospective. This is also an opportunity to consider any feedback you received from the product owner about the demonstration. So typically, well, not typically, the review happens first. Then you have the retrospective, and then you go into the sprint planning for the next iteration. At some point, we will have the release product. The product is released according to your release plan.

ExamCollection provides the complete prep materials in vce files format which include PMI-ACP certification exam dumps, practice test questions and answers, video training course and study guide which help the exam candidates to pass the exams quickly. Fast updates to PMI-ACP certification exam dumps, practice test questions and accurate answers vce verified by industry experts are taken from the latest pool of questions.