MOC EXAM 25Q Agile 88% 126->150 Flashcards
For Kanban or “Flow based” Agile, iterations follow the number of story cards in the Work in Progress limit, shown on the visual or virtual board. The team pulls cards from the backlog column on the Kanban board based on their capacity. These story cards provide an increment of value and are:
- the primary driver of executive behaviour
- the primary measure of progress
- the primary way to pay for the cost of an Agile team
- the primary enabler of people’s engagement
The key to Kanban is making progress visible. Progress naturally improves team engagement (no one likes being stuck, and blockers are clear for people to see and assist with).
Continuous Integration wraps software build, deployment, and testing into a single, automated, repeatable process. This merges all changes made to the software and:
- separates each feature into its own development pool
- ensures no code is changed, to avoid complication
- integrates all changed components regularly, at least once a day
- enables new features for the product backlog
Continuous integration is designed to merge all changes made to the software and test them automatically, discovering any defects or issues on a daily basis.
You have just come on board an Agile team and a decision needs to be made about product requirements. The scrum master asks the team to show either thumbs up, down or sideways. What does a thumb sideways mean?
- The team member doesn’t mind about the decision either way.
- The team member has a concern or conflict that needs further discussion.
- The team member defers to the executive sponsor to decide.
- The decision is outside of the team member’s expertise and they choose not to vote.
💡 When voting in an Agile team, members who vote with a thumb sideways have a concern or conflict with the decision and would like to discuss it further.
You are an Agile project manager on a software project that needs to be delivered quickly. You would like to shorten the time for identifying and resolving defects as they arise. What will you implement with the team?
- Continuous integration
- Daily build and smoke tests
- Usability testing
- Exploratory testing
Continuous integration aims to merge code and have a working build once a day, then executes automated tests quickly to see if anything is broken. This frequent checking ensures less time passes before a problem is identified.
You are an Agile project manager working with the project sponsor in the beginning stages of an Agile project. The project sponsor mentions that they would like help creating the Project Charter. You tell them you will also do a Team Charter for your Agile team, that will include the project sponsor. What does this mean?
- You will capture the Team values, Communication guidelines and Decision-making process separately to the project purpose, requirements and summary schedule.
- You will create a project plan with Scope, Schedule, Cost and Quality outlines to follow.
- You will take over from the project sponsor and direct the team on future customer requirements.
- You will defer to the team for all queries in the way of a servant leader.
An Agile project manager charters both the project and the team:
A project charter focuses on the business case, project purpose, high level requirements, stakeholders and risks.
A Team Charter focuses on the agreements in how the team will operate, and is created as a team.
You are an Agile project manager and your organization is moving away from waterfall to an Agile way of work. After reading the Agile manifesto, the functional manager you are working with mentions “individuals and interactions over processes and tools” and asks how you will do it. What do you tell them?
- Create ceremonies such as the daily stand-up, iteration planning meeting, demos & reviews and retrospectives that encourage team interaction.
- Create a process for the team to review that shows the way of work.
- Ask the project sponsor to interact with the team by sharing some of their journey.
- Ensure the tools the team have to work with are state of the art software solutions.
Many Agile practices are based on a collaborative approach, which enables fast decisions and ownership of the work. One way to do this is co-locate the team, but others are the daily stand-up, team planning of the next iteration, and retrospectives to improve the way of work moving forward.
An executive in your organisation approaches you about working in an Agile team. They have heard about Feature Driven Development and would like to try it as a “test and learn” in your team. What do they mean by this?
- Your team will rely on previous feature designs for your work.
- Your team features certain abilities, and showcases them to other teams.
- Your team enjoys the feature of working with Agile in an Agile organisation.
- Your team will trial developing an overall model, then planning, designing and building by those features.
Agile Feature Driven Development AFDD starts with an overall feature model, then plans, designs and builds by those features. Once a feature is complete, the process can begin again, complete with any learning from the previous feature.
You are at the beginning of a new iteration and about to plan and decide what gets worked on in the upcoming sprint. You decide to invite all project stakeholders to the planning meeting to decide what to work on next. Why is it important that all stakeholders are involved in decision-making?
- So you can keep an eye on what they are doing
- So business representatives can report back to their managers on the project
- So the team feels important, with lots of stakeholders present
- So the project stakeholders don’t reject a decision that wasn’t theirs
Giving ownership of decisions to the team and stakeholders is one way to gain their buy-in.
If stakeholders are involved in decision-making, they will be more committed to any decision made and to the project.
