4 is correct because there is no best method of implementing agile. 1, 2, and 3 are incorrect. 1 is incorrect because it is recommended that new teams generally want to follow a methodology more strictly, but we do not know the maturity of Christopher’s team. 2 is incorrect because there is no single right way to implement agile. 3 is incorrect because most teams end up customizing their approach as they mature in their understanding and practice of agile. However, that does not make their practice better than a team that strictly follows the methodology.

4 is correct because transparency is focused on the full team having visibility and agreement regarding work within a sprint. 1, 2, and 3 are incorrect. 1 is incorrect because although the description is correct, visibility is not the appropriate term for the Scrum pillar. 2 and 3 are incorrect because inspection and adaptation are not the focus of the definition of done, which is more about openly setting expectations.

The most likely scenario (and correct answer) is that the team breaks down the larger user story into segments that span releases, which couldn’t be tested until the end. The other responses are incorrect because it’s not necessary to make a user story simpler or to reassess; there’s nothing wrong with a complicated user story crossing iterations. However, the functionality won’t be usable until all segments are complete. Lastly, the break down of a user story has no effect on how it fits into an iteration.

The correct answer is the cost of change can be expected to increase as the project moves closer to a production release; it does indeed increase as it moves closer to production. The other responses are incorrect because they are inaccurate statements for this scenario. As stated, the cost of change will increase as the project moves closer to release; so will the likelihood that a change may affect everything that was developed prior.

The correct response is finding defects through pair programming. By dealing with issues found the earliest, which is through pair programming, great cost can be saved. The other responses are incorrect because they are representative of cost savings later in the agile process, so their impact is less.

The correct answer is incorporating refactoring into every estimate; Agile estimates should include refactoring as part of every user story. The other responses are incorrect because they are not appropriate ways for technical debt to be handled. Technical debt should be dealt with as part of each item delivered, not after the fact or scheduled separately.

The correct answer is in the team’s retrospective meetings. The best example of the kaizen principle’s small incremental improvements method is shown in the team’s retrospective meetings; retrospective meetings are focused on improvement. The other responses are not the best examples of the kaizen process and are incorrect. Sprint, daily standup, and release planning meetings are not focused on improvement.

Backlog refinement is the correct answer. Backlog refinement is just a review and prioritization of what is in the backlog; it doesn’t focus on continuous improvement. The other responses are incorrect because they demonstrate times in the project when continuous improvement is a primary focus.

The correct answer is to investigate the cause before tailoring the process; the primary focus is to find out why there is a need to increase the WIP limit. (It’s likely due to the number of open items being worked on simultaneously). The other responses are incorrect. Because too many items in WIP often lead to a bottleneck, the team should first understand why an increase in WIP limits is being requested. In addition, there’s no need to require a change in communication, nor to calculate throughput or cycle time.

The correct answer is having complex technology and complex requirements. Although Agile projects have complex technology and requirements, they do not have technology or requirements that are near chaotic. The other answers are incorrect because they are not accurate depictions of highly successful agile projects. The most successful are neither high nor low, but somewhere in the middle of the complexity standards.