Free Practice Questions for PMI DASSM Exam

In the context of the Disciplined Agile (DA) framework, if a team is about to begin work on a project where releases are expected only every six months or so, and the team does not have an agile mindset or desire to release often, the "Traditional" lifecycle is most appropriate. The Traditional lifecycle, also known as a predictive or waterfall lifecycle, is suitable for teams or projects that require extensive planning and where changes are infrequent or less welcome. This approach matches well with a mindset that is not inclined towards frequent releases or iterative development, allowing for longer, planned intervals between releases, which aligns with the six-month release cadence described in the scenario.

The statement "The implementation of this blade will be standard across domains" isfalseabout the Business Operations process blade. In Disciplined Agile (DA), the Business Operations process blade involves strategies for providing services to the business and ensuring operational effectiveness, but its implementation will vary depending on the specific context, domain, and organizational needs. DA emphasizes tailoring practices to fit the unique circumstances of the organization, so a one-size-fits-all or standard implementation is not appropriate.

Options A (collaboration with Sales and Marketing), B (providing services to the business), and D (focusing on delighting customers) are true aspects of the Business Operations process blade.

References:

PMI’s Disciplined Agile Senior Scrum Master (DASSM) curriculum materials.

"Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working (WoW)", PMI.

The FLOW view in Disciplined Agile does not mean that there are no starts and stops in any DA project. Rather, it emphasizes optimizing the flow of work through the system by minimizing delays, reducing bottlenecks, and removing unnecessary handoffs. However, starts and stops may still exist due to various factors such as dependencies, changing priorities, or external constraints.

In the Disciplined Agile (DA) framework, the Iteration Demo is the ceremony where the team presents the work completed during the iteration to stakeholders and other team members. This is the primary opportunity to obtain feedback on the increment of product or work that was developed. The feedback gathered during this demo is crucial for making any necessary adjustments in subsequent iterations. Other ceremonies like Daily Stand-up (B), Iteration Planning (C), or Retrospective (D) have different focuses. For example, Retrospective (D) is used for process improvement feedback, not product feedback.

The "Plan the Release" process goal in Disciplined Agile is most likely to offer potential techniques for providing a cost estimate for the project while recognizing that requirements will evolve over time. This goal involves determining the scope of the release, estimating the effort and cost, and planning for future iterations. It accounts for the fact that Agile teams work in environments of uncertainty and helps them create realistic plans that can adapt as requirements change. Options A (Project Management), C (Explore Scope), and D (Address Changing Stakeholder Needs) are relevant for Agile projects, but "Plan the Release" specifically focuses on creating estimates and planning in an Agile context.

The primary purpose of a Community of Practice (CoP) in the Disciplined Agile (DA) framework is to share knowledge among a group of like-minded people. CoPs bring together people who share a common interest or practice, enabling them to exchange insights, experiences, and best practices to enhance their collective expertise. Options B (bringing all the experts together) and D (mentoring, coaching, and guiding others) are secondary benefits but not the primary purpose. Option C (selling a competency) does not align with the purpose of a CoP.

The Architecture Owner is a primary role on a Disciplined Agile Delivery (DAD) team. This role is responsible for guiding the team in making architectural decisions and ensuring the architectural integrity of the solution. The Architecture Owner works closely with the team to balance the need for emergent design and intentional architecture. The other options (Domain Expert, Specialist, and Integrator) are roles that can exist on an agile team but are not primary roles defined within the DAD framework.

The first step in deciding the team's way of working (WoW) in Disciplined Agile is toanalyze the context. Understanding the context includes assessing the team's current situation, the organization's culture, available skills, tools, stakeholder expectations, and project goals. This analysis helps determine which practices, tools, and techniques are most appropriate for the team’s unique environment. Based on this understanding, the team can make informed decisions on their WoW.

References:

PMI’s Disciplined Agile Senior Scrum Master (DASSM) curriculum materials.

"Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working (WoW)", PMI.

Disciplined Agile Delivery (DAD) defines a delivery life cycle consisting of three phases: Inception, Construction, and Transition. Inception focuses on initial project planning, stakeholder alignment, and getting the team ready to work. Construction is the phase where the team builds the solution in iterations, delivering incremental value. Transition involves preparing the solutionfor release, including final testing, deployment, and user training. The other options (A, B, C) do not accurately reflect the terminology and phases used in the DAD life cycle.

When analyzing a team’s context for tactical scaling, Disciplined Agile (DA) considers factors such as "Team Size" and "Dynamics." "Team Size" affects communication, coordination, and overall team performance, while "Dynamics" refers to how well the team members work together, the existing relationships, and the level of trust and collaboration within the team. Options A (Demographics) and B (Best Practices) are not primary tactical scaling factors. Option C (Budget) is an important project consideration but not specifically a tactical scaling factor within the DA framework.

Top of Form

Bottom of Form