Hi everyone, welcome back to this series of Agile PMP questions or Agile Certified Practitioner questions ideal for preparing for your exam or just for checking your knowledge of Agile within your teams and having a little bit of fun. We've got 10 wonderful questions for you today, let's get into them. You are helping the organisation set up a new Agile team and making sure they consider the whole team approach.
What is not correct when regarding the whole team approach? And this is where we get everyone that we need for our project within our own team, instead of having to go to other teams and waste time. trying to get responses from other areas.
So this is a really good way to do agile. The whole team approach means involving everyone with the knowledge and the skills necessary to ensure project success. Well, that pretty much answers that one, doesn't it? Let's see what else we've got. The team should be relatively small as the whole team.
Successful teams have been observed with as few as three people and as many as nine. That's a correct statement, but not necessary. Oh, okay.
So for the whole team approach, without our agile team, team? Yes, we're looking for what's not correct, I guess. So that can be correct as well. Teams are often 100% dedicated to delivery because when switching or multitasking, people make more mistakes. This is context switching and people experience between 20 and 40% loss of productivity.
So this has been proven through studies in multitasking that it's actually not more productive. And that's why we have everyone in the one team. So this is a really important important thing as well. So last one, teams should not be multi-skilled as this can distract from the clarity of the role.
Okay, and that's incorrect because in the whole team approach we want our generalizing specialists or T-shaped people with a wide range of knowledge but also one deep specialty area and that's our cross-functional person. So the incorrect answer here is answer D. The whole team approach ensures that team members are multi-skilled and have at least one deep specialty.
That was really good. All right, let's get into the next question. You're having trouble selecting team members for your new Agile team in a new organization.
What is not true about the cross-functional team member in the whole team approach? And this is so great. If you are hiring, this is a good thing to know. It's exactly, we are always looking out for the person with a wide range and a deep specialty at the same time.
Cross-functional teams consist of team members with all the skills necessary to produce a working product. That's true. We want that.
Everyone can be in the one team. Teams do not need to use visual management because they're already good at what they do. Incorrect. We still want to use the agile practices, visual management like a Kanban board and a burndown chart and team velocity chart. We still want all of those things.
So that's incorrect. That's probably going to be our guy there. In software development, cross-functional teams are comprised of designers, developers, testers, and... And any other required roles?
Yes, very true. Cross-functional team members are critical because they can deliver finished work in the shortest possible time with higher quality, but most importantly, without external dependencies. So that's also true.
So the incorrect answer for our purposes here is answer B. And there it is. Agile teams use visual management no matter how good they are. Methods like Kanban, stand-ups, retrospectives, burn-down charts are used to increase better team working regardless of skill and that's absolutely true that's a really good question to start off as well let's get into the next one we're doing great there are three main types of role in an agile team the team includes representatives for the product owner cross-functional team members and the team not creator not runner not necessarily enabler although that's part of what their role is we're removing blockers that sort of enables the team but mostly the team facilitates or agile coach or scrum master or agile project manager or anything that you want to call them they facilitate problem solving and discussion within the team let's go with answer b the team facilitator also known as here we go also known as scrum master team coach iteration manager project manager servant leader or any other agile name there their role is to help raise and remove blockers for the team ensure an active flow of work, very important, and problem solve with the team when needed.
And this role, because of that, even though it may seem like an extra role, it's extremely important. Helps that flow of work and removes those blockers. Really, really great. All right, good one.
Let's get into the next question. We are flying through them today. Amazing stuff.
All right, you are working through the iteration with your Agile team. and having some trouble completing one of the story cards in the sprint. It is dependent on something else being done and the contact is away. What will you do next? Okay, so the contact's away and we need something to be done.
Razor blocker at the next daily... stand up so the team can swarm around the problem and solve it quickly. Yeah, wow, I really love that. And that shows the power of Agile because we can raise that blocker, the team can swarm around it and problem solve, and we may not need that contact to be...
be here. So that's actually quite good. Bring the piece of work in-house so you don't have to worry anymore. Wow, that's also pretty good.
But maybe not the most immediate answer. May not always be possible. It also does meet the whole team approach though, which is good. Ask the product owner to remove that feature for now. You can revisit it later.
Ideally, no, like that's not the ideal situation here. We still want to prioritize value based on the product. on its normal priority and add costs to the budget and find a third party to complete the work definitely that would be the last preference there even though you might do it definitely not not our first way to go so i think you know like that one's a maybe uh but i think raising the blocker is definitely where people can swarm around the problem that's probably going to be our best bet let's go with answer a problem solving is done with the agile team blockers are raised as soon as possible at least once a day during the daily stand-up so the team can swarm around the problem get help for any experts needed and then move on and that's a great way to do it all right good stuff next question for us we are up to number five doing great the product owner representing the business on your agile project is used to a more dictatorship style of leadership so they're telling people what to do specifically you explain that server Servant leadership is used in Agile to ensure a safe and an open environment.
Why is this important to product development? And this is so important to product development. So the Agile team lead knows who to blame? No, when things go wrong. We're not blaming people.
What we're trying to do is remove blockers so people can do their best work. That's our main thing. So the team can accurately count the defects?
Not necessarily. They should be available for everyone to see anyway as well. So the team... feels free to ask for help, admit to problems or failures, and to improve.
Yes, that's exactly it. If we have a dictatorship style of leadership, you know, getting down on people when they make a mistake, then what's going to happen? They're going to stop telling people about their mistakes.
And what's going to happen? Those mistakes are going to be hidden. And then we're going to find them when we release the product.
And it's going to be a much worse experience for everyone involved. We want transparency. We need people to be open.
And we need the environment to be safe so people can be open. And last one, so the entire team can push work on each other if they know they have time. Again, not necessarily. We have the Kanban board so everyone can see where the work is, and it's transparent as well.
So I think the correct answer for us is answer C. Psychological safety is one of the most important parts of a high-functioning team. And this is so true.
Which means having the safety. to be vulnerable, admit to problems, ask for help, and improve. It starts with the leader, and servant leadership contributes to this. And that's just a great way to put it.
So yeah, really good question for us. All right, let's get into the next one. Feedback in many different forms is one of the most important parts of a successful agile product delivery. Which of the below is an agile method for gathering and using feedback to improve? oh, this is good.
And agile is all about feedback and also about improving. So this should be fairly easy. Let's see how we go.
Having a once weekly working group meeting. No, we want daily meetings. We want more collaboration. We want more communication. So not one once a week is not enough for us.
Conducting sprint reviews or demonstrations that include all stakeholders. Yes, because that's gathering feedback on the working increment or the feature. and we're using it and the stakeholders can say, oh, yes, this is exactly what we wanted. Thank you very much. Or, oh, I didn't think this did, you know, something is wrong here.
So we're getting feedback. Sending out project reports to project stakeholders to view. No, I mean, that's a report, but it's not necessarily getting feedback, is it?
So not that one. Asking stakeholders for feedback only when development is blocked. No. No, not again. We want feedback all the time, just to make sure we're always checking in, to make sure that things are on track.
So the correct answer for us, I think, is answer B. Demonstrating the usable increment developed during an iteration... to the customer or product owner ensures feedback is gathered more quickly than only at the end of a project.
And retrospectives are another way to do it, so that's really good to know as well. Alright, great job guys! Only three questions to go I think, three or four.
I mean, we're doing so great, so really well done. And this is great practice, so keep going. You're working on an Agile project where the product business representative is pushing for more and more features to be delivered in each iteration. You know what they are asking is not possible based on your team's current velocity.
What will you do next? Oh, this is a great question. This is a great scenario-based question, and you might see this in the real world too.
So let's see what we've got. Show them the team velocity and the points allotted to the cards in the backlog, and then ask them to prioritize the features at the next sprint planning. Yes, yes, yes. This gives the business representative control.
So they have control over what's delivered. However, it's within certain boundaries. So it's just a beautiful way to do it. We're saying we can deliver this much, but you have control over what is actually delivered.
And what is the highest value to? you. Wonderful way to do it.
I think that's going to be our answer. Add more members. No.
Ask for another business representative who understands the technology better. Sometimes that would be nice, but we don't, you know, that's not the way. We want to educate and work within a beautiful system that actually works, which is agile.
Remove some of the features yourself and see if anyone notices. Oh yes. Wouldn't we love to do that sometimes, but maybe not. the best answer for us.
So let's go with answer A. An agile team ultimately serves the customer exactly right. And in many cases, the customer is the business or the business owner or the representative who we're delivering value to.
So who are we delivering this value to? If they're not also the product owner and familiar with that way of work, then you should show them the team velocity versus how many points are allotted and ask them to prioritize based on that. And this is a very important point. This gives them control and makes everyone feel a lot better about what's happening. So I think it's a wonderful way to do it.
As we've seen, great question that one. Let's get into the next one. You're working on a traditional waterfall project. Oh, yes. And the organization wants to move to an agile way of work.
Oh, even better. The functional manager wants to get the benefit of certain agile tools that they've heard about to uncover potential problems before they occur. What will you do next?
Okay, we know the things here. Yeah, visual management, you know, asking for feedback and all of these things that we've spoken about. Write the change into your project management plan and circulate it with project stakeholders. Not really agile, no. Set a weekly working group meeting to discuss the project.
Not really agile as well. Iteration planning, maybe, but just jumping straight into iteration planning will probably scare a lot of people. So that might not be the best. Make the product backlog. iteration Kanban board and velocity chart all visible in a co-located team area.
I think that's probably the best answer and these things can really integrate with a normal project quite seamlessly. You can have a Kanban board with the cards on the board. You can have a velocity chart to see how much work is going through the team on a fortnightly basis or per sprint and you can have the product backlog which is what we're wanting to deliver. the features, the tasks. So all of that is still possible even in a waterfall environment.
And I've seen this happen many, many times. It's a hybrid approach. And you'll see this on the exam as well.
So let's go with answer D. There are many agile tools to detect and prevent problems. Visual management is our best tool here. Kanban board, so visible backlog and velocity chart.
Everyone can see what the team is up to. If things are going off course, we can also see that as well if there are any blockers we can also see that and putting it in a co-located place having daily stand-ups team iteration planning before our iteration putting those features according to the prioritized business value retrospectives demos and reviews all of these things are designed to uncover problems and solve them early and that's part of the power of an agile way of work all right last two questions guys Well done. We've got this.
The Agile Manifesto has 12 clarifying principles added to it to help projects and teams understand the Agile values. Which of the below is a correct clarifying principle? Tailor the project approach to suit the project and the team.
Yes, I love that one. Ensure executive buy-in. Not necessarily. So we can make managers and executives part of the team. team by inviting them to our daily stand-up, inviting them to our demos and reviews, inviting them to our retrospectives if we really, really want to.
We're transparent enough and we're, you know, let's share the information so that they have that access to that information quickly as well. Deliver working software frequently from a couple of weeks to a couple of months with a preference to the shorter time scale. Right, this is about the 12 clarifying principles.
I forgot. Yes, so I didn't read the question correctly, but this is exactly. one of our 12 clarifying principles.
So you've got the Agile Manifesto, which is people interactions over processes and tools and stuff like that. And this is our 12 clarifying principles. This is definitely it. Last one, ensuring complete planning.
That's more of a waterfall approach. So let's go with answer C. Deliver working software frequently from a couple of weeks to a couple of months.
And that's one of our Agile clarifying principles. A great way to add more meat. and more information to an Agile approach.
Really well done. And also really well done is the last question, which we're up to, and you've done an amazing job. Here we are. The Agile, oh, and it's another clarifying.
This is great. Now we get to get more information from the actual source. This is a 12 clarifying principles.
What is a correct 12 clarifying principle here? So business people should dictate to the development team what to do. We don't want to dictate, do we? So we want to serve.
leadership not the same as dictatorship style developers can code and release products at a schedule that suits them for complete autonomy also no because we may actually have items or schedules that we need to meet and that's why we time box everything two week iterations you know spike cards for researching things that we're uncertain of so that's it anyway that's a slight sidebar business people and developers mustn't work together No, we want them to work together. So that's not correct. Business people and developers must work together daily throughout the project.
And when this happens, you will see a little bit of magic start to occur and the project will start to pick up speed. Engagement will start to increase. This is one of the most powerful things that you can do.
And when you get it right and when it starts to happen, wow, that's when the magic really happens. Let's go with answer D. As you will know from the various Agile approaches, business people our product owner who represents the business or the customer.
They must work together with the developers daily throughout the project and that's a wonderful way to do it. And also a wonderful way to do it is to practice your agile questions by going through these videos with me and spending a little bit of time through your day and preparing for your exam. I think you've done an amazing job and I also truly believe that with this practice and with your dedication you absolutely can pass the exam. I truly truly believe in you and I know you can. I'll see you in the next few videos.
Bye for now.