agile certified practitioner (acp) exam prep course 3b ...€¦ · agile certified practitioner...

Agile Certified Practitioner (ACP) Exam Prep

Course 3b - Agile Principles & Mindset Part 2

Agile Principles & Mindset

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development (DSDM)

• 1994 in order to add discipline to RAD.• Designed to be compatible with ISO 9000 & Prince2• Is iterative & incremental• Fixes cost, quality & time at project outset.• 2007 rebranded DSDM Atern.• 2014 went back to just DSDM.• Often used to provide overall project framework in

conjunction with Scrum.

© Copyright and all rights reserved – Looking Glass Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method

Feasibility

Business

FunctionalModel

IterationImplementation

Design & Build

Iteration

Post-ProjectPre-Project


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development MethodPrerequisites for Using DSDM

• Acceptance of the Atern philosophy before starting work.• Appropriate empowerment of the Solution Development

Team.• Commitment of senior business management to provide

the necessary Business Ambassador involvement.• Incremental delivery.• Access by the Solution Development Team to business

roles.• Solution Development Team stability.• Solution Development Team skills.• Solution Development Team size.• A supportive commercial relationship.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

DSDM – Atern Philosophy


Any product must be aligned to clearly defined strategic goals & focus upon early delivery of real benefits to the business. This is best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level & collaborate in order to deliver the right solution. The solution will be delivered in the agreed timescale, according to the priorities set by the business. The stakeholders must be prepared to deliver a fit-for-purpose solution. They must also be prepared to accept that change is inevitable as they understand more about the solution being developed.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method


ProjectManager

TeamLeader

BusinessVisionary

TechnicalCoordinator

BusinessSponsor

SolutionDeveloper(s)

SolutionTester(s)

BusinessAmbassador(s)

BusinessAnalyst(s)

BusinessAdvisor(s)

WorkshopFacilitator

AternCoach

ProjectSolution Developm

entO

ther

The Atern Team Model

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development MethodDSDM Eight Principles

• Focus on the business need.• Deliver on time.• Collaborate.• Never compromise quality.• Build incrementally from firm foundations.• Develop iteratively.• Communicate continuously & clearly.• Demonstrate control.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method1. Focus on the Business Need

• The main acceptance criteria is delivering something that addresses the defined business need.– Clearly define the scope of the system.– Understand the true business priorities.– Establish a sound business case.– Seek continuous business sponsorship & commitment.– Guarantee the minimum usable subset of features.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method2. Deliver on Time

• Timebox the work.• Focus on business priorities.• Always meet deadlines.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method3. Collaborate

• Decisions must be made with users and developers working together quickly.– Involve the right stakeholders, at the right time,

throughout the project.– Ensure that the members of the team are empowered

to make decisions on behalf of those they represent without waiting for higher-level approval.

– Actively involve the business representatives.– Build a one-team culture.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method4. Never Compromise Quality

• Set the level of quality at the beginning.• Ensure that quality does NOT become a

variable.• Design, document, & test appropriately.• Build in quality by constant review.• Test early & continuously.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method5. Build Incrementally from Firm

Foundations• Strive for early delivery of business benefit

where possible.• Continually confirm the correct solution is

being built.• Formally re-assess priorities & ongoing project

viability with each delivered increment.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method6. Develop Iteratively

• Focus on frequent delivery of products, with assumption that to deliver something “good enough” earlier is always better than to deliver everything “perfectly” in the end. – Do enough design up front to create strong foundations.– Take an iterative approach to building all products.– Build customer feedback into each iteration to converge on

an effective business solution.– Accept that most detail emerges later rather than sooner.– Embrace change – the right solution will not evolve

without it.– Be creative, experiment, learn, evolve.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method7. Communicate Continuously & Clearly

• Communication & Cooperation among all project stakeholders is required to be efficient & effective.– Run daily team stand-up sessions.– Use facilitated workshops.– Use rich communication techniques such as modelling &

prototyping.– Present iterations of the evolving solution early & often.– Keep documentation lean & timely.– Manage stakeholder expectations throughout the project.– Encourage informal, face-to-face communication at all

levels.© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Dynamic Systems Development Method8. Demonstrate Control

• Use an appropriate level of formality for tracking & reporting.

• Make plans & progress visible to all.• Measure progress through focus on delivery of

products rather than completed activities.• Manage proactively.• Evaluate continuing project viability based on

the business objectives.© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Crystal Overview• An entire family of methodologies.

• Developed by Alistair Cockburn in mid-1990s.

• Based on observations of successful teams that did not follow formal methodologies.

• Avoids strict or rigid processes found in other methodologies.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

CrystalCockburn Differentiated Between…

• Methodologies – Sets of elements (e.g. practices or tools).

• Techniques – Skill areas (e.g. developing Use Cases).

• Policies – Dictate organizational musts.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

CrystalCrystal Methods Focus on…

• People• Interaction• Community• Skills• Talents• Communications


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Crystal• Versions scale according to team size.• The color denotes the weight:• Crystal Clear - 2-6 people• Crystal Yellow – 7 – 20 people• Crystal Orange – 10 – 40 people• Crystal Orange Web• Crystal Red - up to 80 people• Crystal Maroon• Crystal Diamond• Crystal Sapphire


Lightweight, not mission critical

Heavy, mission critical

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

CrystalCommon Crystal 7 Properties

• Frequent delivery• Reflective improvement • Close or osmotic communication • Personal safety• Focus• Easy access to expert users• Automated tests, configuration management,

frequent integration© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

CrystalFrequent Delivery

• Software released in iterations weekly or quarterly.

• Possible to have multiple iterations per release.

• Problems found and fixed early on.

• Customers get to ensure the project is going the way they want it to go.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

CrystalReflective Improvement

• Developers dedicate time to improving the development process.

• Reflection workshops are held every few weeks to help find processes that are working & which ones need to be modified.

• Iteration helps determine if a process is working or not.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

CrystalClose or Osmotic Communication

• Development teams MUST be in the same room.– Developers do not need to break concentration to

move somewhere else.

– Information flows quickly through the team.

– Communication overhead is reduced.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

CrystalPersonal Safety

• Team members must be able to speak freely in a group without being ridiculed.

Focus• Focus on a task long enough for progress to be

made.– 2 hour periods where the developers have no

interruptions.– Developer assigned to a project for at least 2

complete days.• Clear definition and goals of the project.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Crystal

Easy Access to Expert Users• Developers work with experts in the field of

the project who will also be end-users.

• Expert will answer questions and suggest solutions or improvements.

• Minimum: meet once a week for 2 hours and be reachable by phone.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

CrystalAutomated Tests, Configuration

Management Frequent Integration• Spot errors and problems that arise from

changes being made.

• Done regularly– Problems spotted early on.– Problems are less likely to grow.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Lean Software Development (LSD)1. Eliminate

Waste

2. Amplify Learning

3. Defer Decisions

4. Deliver as fast as

possible

5. Empower the Team

6. Build Integrity In

7. See the Whole


1. Eliminate WasteYou must first recognize waste before eliminating it.• Unnecessary code and functionality.• Delay in the software development process.• Unclear requirements.• Avoidable process repetition (often caused by insufficient testing).• Bureaucracy.• Slow internal communication.

2. Amplify Learning• The accumulation of defects is prevented by running tests as soon

as the code is written.• More time is spent trying new ideas than writing documentation.• Mockups and prototypes are regularly presented to the customer

to gather requirements.• The use of short iterations is key and done in conjunction with

refactoring and integration testing.• Set-based development concentrates on communicating the

constraints of the future solution and not the possible solution promoting the solution birth via dialogue with the customer.

3. Decide as Late as PossibleThe best results are achieved with an options-based approach using facts instead of assumptions or predictions.• Planning focus is on the different options and adapting to the

current situation.• Planning focus includes clarifying confusing situations and

establishing rapid action patterns.• The team must decision options as soon as information is

available.

4. Deliver as Fast as PossibleTo survive you often must be the fastest. The sooner a product is delivered without major defects, the faster customer feedback is obtained and incorporated into the next iteration.• Customers value rapid delivery of quality products.• The JIT ideology applies to software development.• The customer provides stories based on need, the developer

estimates time by story.• This changes the organization into a self-pulling system.

5. Empower the TeamThe most effective teams use a Work-Out Technique when the managers do NOT tell workers how to do their job.• Find good people and let them do their own job.• Encourage progress, catching errors, and removing impediments.• Discourage micro management.• People are more than just resources. They require motivation and

a higher purpose.• The developer should be given access to the customer.

6. Build Quality In• The customer needs to have an overall experience of the system.

This is called perceived integrity. How it is being advertised, delivered, deployed, accessed, how intuitive is it to use, what is its price, and how well does it solve problems.

• Conceptual integrity means the system’s separate components work well together as a whole with balance between flexibility, maintainability, efficiency and responsiveness.

• Refactoring is about keeping simplicity, clarity, minimum amounts of features in the code.

• Integrity is verified through testing to ensure the system does what the customer expects.

7. See the WholeSoftware systems are a product of their interactions and not just a sum of parts.• Defects accumulate during the development process.• By decomposing big tasks into smaller ones and standardizing the

stages of development defect root causes can be found and eliminated.

• Think big, act small, fail fast, learn rapidly.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Lean Software Development (LSD)Key Tools & Concepts

• Translation of Lean Manufacturing to IT.• Originated by Mary & Tom Poppendieck.• Pull Systems - Kanban• Queuing Theory - The mathematical study of waiting

lines, or queues. In queueing theory a model is constructed so that queue lengths and waiting time can be predicted.

• Value Stream Mapping• Set-Based Development• Seeing Waste • Motivation• Measurements


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Lean Software Development (LSD)Seven Wastes (TIMWOOD)

• Transportation – Each time a product is moved it stands the risk of being damaged, lost, or delayed.

• Inventory – Raw materials, WIP, or finished goods represent capital outlays that have not yet produced an income.

• Motion – Refers to the damage that the production process inflicts on the entity that creates the product.

• Waiting – Whenever goods are not in transport or being processed, they are waiting.

• Over-Processing – Occurs any time more work is done on a piece than is required by the customer.

• Over-Production – Occurs when more product is produced than is required at a time by the customer.

• Defects – Whenever they occur, extra costs are incurred reworking the part, rescheduling production, etc.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Kanban

• Means signboard in Japanese.

• It is a scheduling system used in Lean Production to improve the JIT flow.

• Kanban limits WIP by defining the maximum number of stories to be worked at a time.

• Typically, it uses a series of columns showing value being added to work flowing left to right.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Kanban• Best used when a team or organization is in need

of:– Flexibility – The team is NOT bound by timeboxed and

will work on the highest priority item in the backlog.– Focus on continuous delivery – Teams are focused on

flowing work through the system to completion and NOT beginning new work until WIP is completed.

– Increased productivity and quality – Both factors are improved by limited WIP.

– Increased efficiency – checking each task for value adding or non-value added activities and remove all non-value added activities.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Kanban• Best used when a team or organization is in

need of:– Team member focus – Limiting WIP allows the

team to focus on the current work.– Variability in workload – When there is

unpredictability in the way work arrives teams cannot make predictable commitments therefore it becomes critical to manage WIP.

– Reduction in waste – Transparency makes waste visible so it can be removed.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Kanban

• It’s a pull system to take work when capacity is available instead of pushing work.

• Taiichi Ohno developed Kanban at Toyota in 1953.

• Best book is KANBAN – Successful Evolutionary Change for Your Technology Business by David J. Andersson.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Task/Kanban Board

BacklogSelected

(5 Max) Ongoing DoneAcceptance

(Max)Deploy

(Max)

Develop (3 Max)

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

Story

StoryStory Story

Story

Story

Story

Story

Story

Story


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

KanbanFive Core Principles of Kanban

• Visualize the Workflow – Have some way to visualize the workflow.

• Limit WIP – Keep the amount of WIP low.• Manage Flow – Track the flow through the

system.• Make Process Policies Explicit• Improve Collaboratively


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Scrum vs. KanbanScrum

• Scrum Boards reset before each sprint.

• Scrum Boards typically have To-Do, In Progress, Validate, Impeded & Done.

• Scrum Boards change infrequently.

Kanban• Kanban doesn’t use

timeboxed iterations (sprints) so it uses a continuous flow of work with new work added when there is capacity.

• Kanban Boards tend to have more columns.

• Kanban Boards change frequently.


Teams often start with Scrum and add Kanban which leads to them not doing Scrum “by the book” any longer.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Test Your Assumption• You must know which methodology is best for which

situation:– Scrum as a basic Agile starting point.– XP is ruthless in testing.– FDD offers robust & specific modeling techniques– DSDM offers suitability filters for how well a process fits a

project.– Crystal works on projects of different sizes & complexities.– Kanban for modification & adaptation.– Cockburn’s Shu-Ha-Ri Model

• Shu - Obey the rules • Ha - Consciously move away from the rules• Ri - Unconsciously find your own path

• Critical to align team size & methodology• Project visibility


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Scaling Agile• Most Agile life cycles are designed for small

teams and projects.• Several techniques are available to scale Agile:

– Scaled Agile Framework (SAFe)– Nexus– Large Scale Scrum (LeSS)– Disciplined Agile Delivery (DAD)


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

SAFe 3.0

• Interactive knowledge base for implementing agile practices at an enterprise scale.

• NOT for corporate IT environments, is designed for BIG software products.

• 3 levels for SAFe: Team, Program, Portfolio.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

SAFe 3.0SAFe Core Values

• Alignment – to a common mission using 3 tools:– Release Planning – Each PI begins with a Release

Planning Meeting with all teams together.– Scrum of Scrums – RTE & Scrum Masters meet twice

weekly in front of the Program Board to discuss progress, risks & dependencies.

– System Demo – Assisted by Systems Team @ end of every iteration to show working solution.

• Visibility• Program Execution• Code Quality


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

SAFe 3.0Level I - Portfolio

• Strategic themes connect portfolio or organizational strategic objectives.

• Budgeting for each ART or Program done at this level.

• Epics are created to fund cross ART training or deliverables.

• Use Kanban system at this level to represent ARTs.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

SAFe 3.0Level II - Program

• 50 – 125 people called an Agile Release Train (ART) is the specific program. If team misses one train they can catch the next one.

• Program Increment (PI) are the timeboxed increments.• Each PI is 5 iterations by default. 4 are focused on the backlog,

1 is IP Iteration for Planning. This is used to deal with the unexpected or creative. Run Inspect & Adapt Workshop where the team works to improve process.

• Has a separate Program Backlog that represents larger features that are broken down to create the team backlog. Owned by Product Manager.

• Guided by a Release Train Engineer (RTE) is program manager.• Train System Architect facilitates process of developing

infrastructure for future PIs.© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

SAFe 3.0

Level III Team• Uses Kanban, Scrum or Scrumban.• 2 week iterations.• Not every sprint produces a potentially

shippable increment.• Changes some terms which Schwaber &

others don’t like.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

NexusWhat is Nexus?

• Nexus – Is a unit of development in Scaled Professional Scrum.

• Nexus – Is also a framework consisting of roles, events artifacts, and techniques that bind the work of 3 to 9 Scrum teams.

• Nexus – Is an exoskeleton that rest on top of multiple Scrum teams to create an Integrated Increment.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

NexusNexus Consists of…

• Roles are the same as Scrum.• Adds one new role the Nexus Integration

Team:– Product Owner(s)– Scrum Master(s)– Nexus Integration Team Members


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

NexusNexus Consists of…

• All Scrum teams use the same, single product backlog.

• Nexus events:


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

NexusNexus Process Flow

• Refine the product backlog.• Nexus Sprint planning

– Backlog items reviewed– PBIs assigned to teams & they create their Sprint

backlog.– Each Scrum team plans its own sprint.– Teams align sprint goal(s) to Nexus goal(s).

• Team develops features.© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________


• Nexus Daily Scrum:– Was the previous day’s work successfully

integrated? If not, why?– What new dependencies have identified?– What information needs to be shared across

teams in the Nexus.– Each team then holds its own Daily Scrum.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________


• Nexus Sprint review – All teams meet with Product Owner to review the integrated increment. Adjustments may be made to the backlog.

• Nexus Sprint retrospective– Shared challenges are discussed. – Each team holds its own retrospective.– Teams meet & agree on how to visualize & track

the identified actions.© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

NexusEach Retrospective Should…

• Was any work left undone? Did the Nexus generate technical debt?

• Were all artifacts, particularly code, frequently (as often as every day) successfully integrated?

• Was the software successfully built, tested, & deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

NexusRefinement Meetings

• The greater the complexity & dependencies, the more the Product Backlog items must be refined to remove dependencies.

• Helps to forecast which team will deliver each item.

• Identifies dependencies across teams.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

LeSSOverview

• Large-scale Scrum is regular Scrum applied to large-scale development.

• Created by Craig Larman and Bas Vodde.• There are two frameworks depending on

project size:– Framework 1 – Projects up to 10 teams.– Framework 2 – Larger projects.

• Is an organizational design framework.© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

LeSSLeSS / Scrum Commonalities

• A single Product Backlog (because it’s for a product, not a team).

• One Definition of Done for all teams.• One Potentially Shippable Product Increment at

the end of each Sprint.• One Product Owner.• Many complete, cross-functional teams (with no

single-specialist teams).• One Sprint.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

LeSSLeSS / Scrum Differences

• Sprint Planning Part 1: In addition to the one PO, it includes people from all teams. Let team members self-manage to decide their division of Product Backlog Items. Team members also discuss opportunities to find shared work and cooperate.

• Sprint Planning Part 2: Held independently (and usually in parallel) by each Team, though sometimes for simple coordination and learning two or more Teams may hold it in the same room.

• Daily Scrum: This is also held independently by each Team, though a member of Team A may observe Team B’s Daily Scrum, to increase information sharing.

• Overall PBR: There may be an optional and short overall Product Backlog Refinement (PBR) meeting that includes the one PO and people from all teams. Purpose is to decide which teams are likely to implement which items and therefore select those items for later in-depth single-team PBR. It is also a chance to increase alignment with the Product Owner and all teams.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

LeSSLeSS / Scrum Differences

• Product Backlog Refinement: The only requirement in LeSS is single-team PBR, the same as in one-team Scrum. But a common and useful variation is multi-team PBR, where two or more Teams are in the same room together, to increase learning and coordination.

• Sprint Review: In addition to the one Product Owner, it includes people from all teams, and relevant customers/users and other stakeholders. For the phase of inspecting the product increment and new items, consider a “bazaar” or “science fair” style: a large room with multiple areas, each staffed by team members, where the items developed by teams are shown and discussed.

• Overall Retrospective: This is a new meeting not found in one-team Scrum, and its purpose is to explore improving the overall system, rather than focusing on one Team. The maximum duration is 45 minutes per week of Sprint. It includes the Product Owner, Scrum Masters, and rotating representatives from each Team.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Disciplined Agile DevelopmentOverview

• A people-first, learning-oriented, hybrid agile approach to IT solution delivery.

• Makes use of Scrum, Agile Modeling, XP, UP, Kanban, Lean Software Development, Outside In Development & others.

• Looks at full, end-to-end delivery life cycle from project initiation to solution delivery.

• Provides technical practice advice like XP as well as modeling, documentation, & governance.

• Less prescriptive than Scrum by being more goal-driven. Provides significant advice & alternatives.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Disciplined Agile DevelopmentOverview

• Draws from UP.• Projects divided into three phases:

– Inception– Construction– Transition

• Scott Ambler creator


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Disciplined Agile DevelopmentThe Backlog

• Go beyond functional requirements. Teams often must complete non-requirement related work such as take training, review products of other teams, address defects. These need to be on the backlog.

• Take a risk-value approach. Common risks include the need to come to stakeholder consensus early in the project, or the need to prove that your architecture strategy, actually works. DAD teams look at their work item stack early in the project, typically during the Inception or iteration 0 to identify requirements which exhibit these technically risky features.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Disciplined Agile DevelopmentThe Backlog

• Model a bit ahead. What if a work item is very complex, requiring a bit more thinking that what generally occurs in an iteration planning session? DAD teams adopt the Look-Ahead Modeling practice and look ahead an iteration or two and invest the time to explore complex upcoming items to reduce the overall project risk. Modeling a bit ahead is called backlog grooming in Scrum.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Disciplined Agile DevelopmentLifecycle Versions

• Agile/Basic – Based on Scrum, but extended to provide a streamlined strategy from beginning to end.

• Lean/Advanced – Based on Kanban.• Continuous Delivery – Stable team based on

Kanban and Lean.• Exploratory/Lean Startup – Base on Lean

Startup strategies© Copyright and all rights reserved – Looking Glass

Development, LLC.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Disciplined Agile Development

Primary Roles:• Team Lead• Product Owner• Architecture Owner• Team Member• Stakeholder

Primary roles occur on all DAD projects regardless of scale.

Secondary Roles• Specialist• Independent Tester• Domain Expert• Technical Expert• Integrator

Secondary roles only occur at scale & sometimes are only temporary.


Roles

Team

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Disciplined Agile DevelopmentDAD vs. Scrum

• DAD places more emphasis on architecture & technical risk reduction.

• Adds the role of Architecture Owner.• Changes names in Scrum such as Scrum

Master becoming Team Lead.• Is far les prescriptive


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Disciplined Agile Development

DAD vs. Scrum


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

PMOsProject Management Office (PMO) —Centralizes the management of projects. Typical 3 structures:Supportive – Providing a consultative role by

providing templates, best practices, training, access to information, & lessons learned.Controlling – Provide support & require compliance.Directive – Take control of the projects by directly

managing the projects.An Agile PMO is value-driven based on a

customer collaboration mindset and is invitation-oriented.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

PMOsOften, Agile PMOs become centers of excellence providing:Development and implementation of

standards.Training, mentoring and organizational

learning.Multi-project management.Stakeholder managementRecruiting, selecting, and evaluating team

leaders.Executing specialized tasks for projects.


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Organizational Structure


Differentiation vs. IntegrationThe need for specialized areas ofexpertise (Production,Marketing, Finance, etc.). Thelevel of differentiationhinges on the needs of theorganization.

The need for coordinated andcross-functional efforts to accomplish organizational tasks.

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Organizational StructureMany factors influence structure including:GeographyFunctionalize structureSize of project deliverablesAllocation of people to projectsProcurement-heavy organizations


_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Organizational Structure


Weak Matrix

Balanced Matrix

Strong Matrix

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

_____________________________________________________________________________________

Review Questions:

1. Which of the following is at the heart of FDD? A. Users B. Customers C. Features D. Releases

2. The visualization for the DSDM lifecycle is sometimes referred to as the ___________?

A. Agile Triangle B. Cheese and Pizza Diagram C. The Agile DSDM Pyramid D. The Meat and Cheese Diagram

3. Which of the following is not a common objective of the feasibility phase found in DSDM?

A. To identify information used, created and updated by the proposed solution.

B. To describe the organization and governance aspects of the project. C. To state first-cut estimates of timescale and costs for the project overall. D. To plan and resource the Foundations phase.

4. Which of the following is NOT a potential outcomes in DSDM from deployment?

A. All requirements have been satisfied. Hence, no further work is currently needed – and no returning arrow.

B. Completion of state first-cut estimates of timescale and costs for the project overall.

C. Features that were already planned for the next increment are now to be added, so the process returns to exploration.

D. The next increment will solely address areas of technical concern, so the process returns to engineering.

5. Which of the following is NOT a prerequisite required for using the Dynamic Systems Development Method?

A. Acceptance of the Atern philosophy before starting work. B. Appropriate empowerment of the Solution Development Team. C. Commitment of senior business management to provide the necessary

Business Ambassador involvement. D. Access by the Business Team to the Solutions Development Team.

6. Within DSDM which of the following roles is responsible for the business case? A. Business Sponsor B. Business Visionary C. Project Manager D. Team Leader

7. Which DSDM role provides the business perspective for all decisions related to

the way the solution’s fitness for business purpose is defined and implemented? A. Business Sponsor B. Business Visionary C. Business Ambassador D. Team Leader

8. Who within a DSDM team is responsible for interpreting the needs of the

Business Sponsor, communicating those to the team and, where appropriate, ensure they are properly represented in the business case?

A. The Business Sponsor B. The Business Visionary C. The Project Manager D. The Technical Coordinator

9. Which of the following DSDM roles provides the business perspective for all

decisions related to the way the solution’s fitness for business purpose is defined and implemented? Working closely with the rest of the Solution Development Team, this role guides the evolution of the solution, bringing other users’ input and ideas to the project as required. As a true ambassador, the role is responsible for the day-to-day communication channels between the project and the business.

A. Business Sponsor B. Business Visionary C. Business Ambassador D. Team Leader

10. Which of the following is NOT one of the eight principles of DSDM?

A. Focus on the business need. B. Deliver on time. C. Build incrementally from firm foundations D. Communicate vigorously and assume positive intent

11. Your team is using DSDM and is using modeling and iterative development. The team is currently working out what needs to be done by whom to meet the current objective. In what stage of the iterative cycle is the team currently?

A. Identify B. Plan C. Evolve D. Review

12. Your team is using MoSCoW Prioritization to evaluate project requirements.

Which of the following represents the W in MoSCoW? A. Will have B. Want to have C. Won't have this time D. None of these apply as MoSCoW is not an acronym.

13. Within the DSDM model, which of the following stages accounts for the largest

amount of time? A. Investigation B. Refinement C. Consolidation D. Kick-off

14. Which of the following is not a core area of focus for Crystal?

A. Processes B. People C. Interaction D. Talents

15. Within Crystal, which color is used for teams of 7 to 20 people?

A. Crystal Clear B. Crystal Yellow C. Crystal Orange D. Crystal Maroon

16. Which of the following is NOT a common practices or properties found in

Crystal? A. Personal safety B. Reflective improvement C. Incremental delivery D. Close or Osmotic Communication

17. Which of the following is NOT a core principle that provides the foundation of Lean Software Development?

A. Eliminate waste B. Amplify learning C. Decide as late as possible D. Deliver as often as possible

18. Each of the following are keys to seing the whole EXCEPT:

A. Defects accumulate during the development process. B. By decomposing big tasks into smaller ones and standardizing the stages

of development defect root causes can be found and eliminated. C. Be fair but decide quickly. D. Think big, act small, fail fast, learn rapidly.

19. Which of the following is one of the three types of deviation from optimal

allocation of resources according to the Toyota Production System or TPS? A. Mumu B. Muda C. Muki D. Moori

20. Which of the following teams is a lean-manufacturing method for analyzing the

current state and designing of a future state for the series of events that take a product or service from its beginning through to the customer?

A. Value stream mapping B. Product flow mapping C. Integration and value mapping D. State and design mapping

21. Which of the following is NOT a tool or Lean software practice emphasized by

the Poppendiecks? A. Seeing waste B. Value stream mapping C. Set based development D. Constraints management theory

22. According to the Poppendiecks' model, there are seven fundamental types of waste that includes each of the following EXCEPT:

A. Transportation B. Motion C. Missed production D. Over processing

23. Which of the following statements concerning Kanban is NOT true?

A. Using Kanban does not require immediate changes to the team board. B. Kanban is part of an approach where the "pull" comes from demand. C. To be effective, Kanban must follow strict rules of use. D. Reducing the number of Kanban increases the sensitivity.

24. When using Kanban for Agile development, there are several rules that must be

applied. Which of the following is not one of those rules? A. Visualize the workflow B. Limit WIP C. Make process policies explicit D. Improve constantly

25. When evaluating which agile method is best which method represents the best

starting point for those new to agile development where its rules, roles, and constructs are usually the easiest to teach and execute?

A. Scrum B. Extreme Programming C. Feature Driven Development D. Kanban

26. Which of the following is NOT a common framework used to scale agile beyond a

single project? A. SAFe B. NeXT C. DAD D. LeSS

27. A release train engineer is approached by a resource who missed the current ART and wants to be part of the team. What guidance should they provide?

A. Join the team at the next daily scrum and begin helping. B. They must wait for the next sprint to join the team. C. Join the team when the next release train is preparing to leave the station. D. Join another team until the next release.

28. Which of the following is a core value of SAFe?

A. Alignment B. Integration C. Continuous improvement D. Constant testing

29. SAFe is governed by nine principles that can be thought of as extensions of the

12 Principles found in the Agile Manifesto. Which of these principles represents the idea that resources must understand the basics of how and organization delivers business value?

A. Take a systems view. B. Manage risk, efficacy and predictability with fast, synchronous learning. C. Synchronize with cross-domain planning and collaboration. D. Understand the economics of the value chain.

30. Which of the following is not fixed at project outset when using DSDM?

A. Cost B. Quality C. Scope D. Time

31. Which of the following is often used in conjunction with DSDM?

A. Scrum B. PMP C. FDD D. XP

32. Which of the following was DSDM specifically designed to be compatible with?

A. PMBOK Guide B. ACP C. Extreme Programming D. Prince2

33. Which of the following terms is commonly used in conjunctions with DSDM that is central to its philosophy?

A. Atern B. Agile C. Complex D. Extreme

34. Which of the following is a prerequisite for the Dynamic Systems Development

Methodology? A. A development team that controls all aspects of the project process. B. Acceptance of the Agile Principles C. Acceptance of the Atern Philosophy D. A sponsor who will pay for DSDM

35. Which of the following is a prerequisite for DSDM?

A. Commitment of senior business management to provide the necessary team size.

B. Commitment of senior business management to provide the necessary Business Ambassador involvement.

C. Commitment of the development to the technical solution. D. A focus on iterative delivery.

36. Which of the following is NOT a prerequisite for DSDM?

A. Access by the Solution Architect to business roles. B. Acceptance of the Atern Philosophy before starting work. C. Solution Development Team stability. D. A supportive commercial relationship.

37. When using DSDM, which of the following is NOT critical to achieving a solution

that provides real business benefit? A. By having key stakeholders understand the business objectives. B. By having key stakeholders empowered to an appropriate level. C. By having key stakeholders collaborate to deliver the right solution. D. By having key stakeholder agree to a timescale and accurate solution.

38. Which of the following must the key stakeholders be to accept when using DSDM?

A. An incremental solution. B. A fit-for-purpose solution. C. A complete solution. D. A tested solution

39. In DSDM and the Atern Team Model, who is NOT part of the Project Team?

A. The Business Visionary B. The Business Sponsor C. Business Advisor(s) D. The Technical Coordinator

40. In DSDM and the Atern Team Model, who is NOT part of Solution Development?

A. Team Leader B. Solution Developer(s) C. Business Ambassador(s) D. Technical Coordinator

41. Which of the following roles is grouped as “OTHER” in the DSDM Atern Model?

A. Atern Coach B. Project Manager C. Business Visionary D. Solution Tester(s)

42. Which of the following is NOT one of the eight core DSDM principles?

A. Focus on the business need. B. Work in small teams. C. Deliver on time D. Demonstrate control.

43. Which of the following is not one of the eight core DSDM principles?

A. Never compromise quality. B. Communicate continuously & clearly. C. The team must work together as one. D. Build incrementally from firm foundations.

44. Which of the following DSDM principle includes guaranteeing the Minimum Usable Subset of features?

A. Demonstrate control B. Deliver business value C. Focus on the business need. D. Build incrementally from firm foundations.

45. Which of the following is NOT part of the DSDM principle of delivering on time?

A. Timebox the work B. Develop iteratively C. Focus on business priorities D. Always meet deadlines

46. When discussing the DSDM principle of Collaborate which of the following is

NOT true? A. It is key to build the correct culture. B. You must involve the right stakeholders, at the right time, throughout the

project. C. It is important to ensure that team members are empowered to make

decisions for those they represent without waiting for higher-level approval.

D. You must actively involve the business representatives

47. Which of the following is NOT a key to the DSDM principle of Never Compromising Quality?

A. Design document & test appropriately B. Test early & continuously. C. Quality must be considered a variable. D. Set the level of quality at the beginning.

48. Which of the following is a key to the DSDM principle of Building incrementally

from firm foundations? A. Strive for early delivery of business benefit where possible. B. Continually confirm the correct solution is being built. C. Formally re-assess priorities & ongoing project viability with each delivered

increment D. All of the above

49. Which of the following DSDM core principles is defined as a focus on frequent delivery of products, with assumption that to deliver something “good enough” earlier is always better than to deliver everything “perfectly” in the end.

A. Collaborate B. Develop iteratively C. Never compromise quality D. Build incrementally from firm foundations

50. Which of the following is not part of the core DSDM principle where

communication and cooperation among all project stakeholders is required to be efficient and effective?

A. Use facilitated workshops. B. Present iterations of the evolving solution early & often. C. Build customer feedback into each iteration to converge on an effective

business solution. D. Keep documentation lean & timely.

51. Which of the following is not part of the DSDM core principle of Demonstrating

Control? A. Present iterations of the evolving solution early and often. B. Measure progress through focus on delivery of products rather than

completed activities. C. Manage proactively. D. Evaluate continuing project viability based on the business objectives.

52. Which of the following does Alistair Cockburn define as a set of elements e.g.

practices and tools? A. Techniques B. Methodologies C. Policies D. Frameworks

53. Which of the follow is a core focus of Crystal Methods?

A. People B. Teams C. Community D. Talents

54. Which of the following Crystal Methods would be best for a team with eight people on the team?

A. Crystal Clear B. Crystal Clean C. Crystal Yellow D. Crystal Magenta

55. Which of the following Crystal Methods is best for projects that are ongoing?

A. Crystal Clear B. Crystal Orange Web C. Crystal Red D. Crystal Diamond

56. Which of the following is the heaviest Crystal Method designed for the most

mission critical projects? A. Crystal Sapphire B. Crystal Red C. Crystal Maroon D. Crystal Diamond

57. Which of the following is NOT one of the common seven Crystal properties?

A. Reflective improvement B. Close or osmotic communication C. Personal safety D. Common retrospectives

58. Which of the following is a core part of Crystal’s concept of frequent delivery?

A. It is possible to have multiple iterations per release. B. Each release it two weeks in length. C. Each release focuses a single function of real value to the business. D. The business controls the features delivered in each iteration through

systematic retrospection.

59. Which of the following is NOT a core component of Crystal’s concept of Reflective Improvement?

A. Developers dedicate time to improving the development process. B. Reflection workshops are held every few weeks to help find processes

that are working & which ones need to be modified. C. Sprint Retrospectives are held at the end of each iteration to ensure the

customer is satisfied with the processes being used. D. Iteration helps determine if a process is working or not.

60. Which of the following is a reason the Crystal Methods recommend collocation of

the team? A. Developers do not need to break concentration to move somewhere else. B. Team size is easier to control which improves communication. C. It reduces project cost. D. Management function improves and overhead is reduced.

61. Which of the following core Crystal properties directs the team to use two hour

periods where the developers have no interruptions and are assigned to the project for two consecutive days at a minimum?

A. Reflective Improvement B. Frequent Delivery C. Easy Access to Experts D. Focus

62. When defining Crystal’s core property of easy access to expert users, how often

is it required to meet with the experts? A. Once a week for two hours and be reachable by phone. B. Twice a week for one hour and be reachable by phone. C. Every other week for two hours and be reachable by phone. D. Three times a week and be reachable by phone.

63. Which of the following is NOT a LSD common example of waste?

A. Avoidable process repetition (often caused by insufficient testing). B. Bureaucracy. C. Defects accumulated during the development process. D. Slow internal communication.

64. Which of the following is a key element of LSD’s concept of empowering the team?

A. Encourage progress, catching errors, and removing impediments. B. The customer needs to have an overall experience of the system. This is

called perceived integrity. C. How it is being advertised, delivered, deployed, accessed, how intuitive is

it to use, what is its price, and how well does it solve problems. D. The customer provides stories based on need, the developer estimates

time by story. Think big, act small, fail fast, learn rapidly.

65. Which of the following is not one of Lean Software Development’s Seven Wastes?

A. Transportation B. Motion C. Under-processing D. Over-processing

66. Which of the following is one of the five core principles of Kanban?

A. Work collaboratively B. See the whole C. Improve incrementally D. Visualize the workflow

67. When comparing Scrum to Kanban, which of the following statements is true?

A. Kanban boards reset before each sprint. B. Kanban board columns change frequently. C. Teams rarely start with Scrum and add Kanban later. D. Scrum uses a continuous flow of work with new work added when there is

capacity.

68. Which of the following Agile methodologies is the most common Agile starting point?

A. Scrum B. Extreme Programming C. Kanban D. Crystal

69. Your project sponsor has given you latitude in the development methodology used for an upcoming project. However, you also know that testing the application will be critical, which of the following do you select?

A. Scrum B. Extreme Programming C. Feature Driven Development D. Kanban

70. When using SAFe, at what level is budgeting completed for each ART?

A. The organizational level B. The portfolio level C. The program level D. The team level

71. How many people are typically involved in an Agile Release Train?

A. 25-50 B. 50-75 C. 75-100 D. 50-125

72. How many iterations is the typical PI when using SAFe?

A. 3 B. 4 C. 5 D. 6

73. When using SAFe and within a PI, how many iterations are focused on delivering

features in the backlog? A. 2 B. 3 C. 4 D. 5

74. Within SAFe, what is the title given to the meeting where the team works to

improve its process? A. Retrospective B. Sprint review C. Inspect and adapt workshop D. Guided improvement session

75. Within SAFe, what is the title of the person who acts as the Program Manager? A. Program Manager B. Agile Train Engineer C. Release Manager D. Release Train Engineer

Answer Key:

1. C LGd course manual p. 64 - As you can tell in the name of the methodology, features are at the heart of the methodology. A feature is a small, client valued function that can be implemented in two weeks. Any function that is too complex to be implemented within two weeks must be further broken down until it meets the definition of a feature. Features are grouped based on business relationships, and those groups are called a Feature Set.

2. B LGd course manual p. 65 - The visualization for the DSDM lifecycle is sometimes referred to as the “Cheese and Pizza Diagram.” At the top of the diagram are the project’s upfront work of feasibility and foundation. This is where the team understands the nature of the business problem and determines the feasibility of the solution. Beginning with the Feasibility, this is all about the organization deciding whether a proposed project is viable both from a business AND a technical perspective by means of a high level investigation of the potential solutions, costs, and timeframes.

3. A LGd course manual p. 66 - DSDM Feasibility typically has six objectives that include: To establish whether there is a feasible solution to the business problem described in the Terms of Reference defined during Pre-Project; To identify the benefits likely to arise from the delivery of the proposed solution; To outline possible approaches for delivery, including strategies for sourcing the solution and project management; To describe the organization and governance aspects of the project; To state first-cut estimates of timescale and costs for the project overall; And to plan and resource the Foundations phase.

4. B LGd course manual p. 66 - There are four potential outcomes in DSDM from deployment. These include: All requirements have been satisfied. Hence, no further work is currently needed – and no returning arrow; A major change of scope was discovered during development that had to be ignored for the time being in order to deliver on the required date. This means returning to the foundations and taking the process on from there; Features that were already planned for the next increment are now to be added, so the process returns to exploration; And the next increment will solely address areas of technical concern, so the process returns to engineering.

5. D LGd course manual p. 66 - There are a number of prerequisites required for using the Dynamic Systems Development Method. These include: Acceptance of the Atern philosophy before starting work; Appropriate empowerment of the Solution Development Team; Commitment of senior business management to provide the necessary Business Ambassador involvement; Incremental delivery; Access by the Solution Development Team to business roles; Solution Development Team stability; Solution Development Team skills; Solution Development Team size; and a supportive commercial relationship.

6. A LGd course manual p. 67 - DSDM advocates 13 specific roles within a project. These roles have varying degrees of importance. However, a key differentiator of DSDM compared to other Agile Methodologies is how detailed these roles are and how much emphasis is placed on them. These roles include: Business Sponsor; Business Visionary; Project Manager; Technical Coordinator; Team Leader; Business Ambassador; Business Analyst; Solution Developer; Solution Tester; Business Advisor; Workshop Facilitator; Atern Coach; and Specialist Roles

7. C LGd course manual p. 69 - The Business Ambassador generally comes from the business area being addressed and provides business-related information from the perspective of those who will ultimately make direct use of the solution. The role provides the business perspective for all decisions related to the way the solution’s fitness for business purpose is defined and implemented. Working closely with the rest of the Solution Development Team, the Business Ambassador guides the evolution of the solution, bringing other users’ input and ideas to the project as required. As a true ambassador, the role is responsible for the day-to-day communication channels between the project and the business. The Business Ambassador must have the desire, authority, responsibility and knowledge to be able to ensure that the right solution emerges to meet the business need. This does not necessarily imply a senior position within the organization, but a level of empowerment during the project to fulfil the role and an allocation of time to fully participate in the project as required.

8. B The Business Visionary is responsible for interpreting the needs of the Business Sponsor, communicating these to the team and, where appropriate, ensuring they are properly represented in the Business Case. The Business Visionary

remains involved throughout the project providing the team with strategic direction and ensuring that the solution delivered will enable the benefits described in the Business Case to be achieved.

9. C LGd course manual p. 69 - The Business Ambassador generally comes from the business area being addressed and provides business-related information from the perspective of those who will ultimately make direct use of the solution. The role provides the business perspective for all decisions related to the way the solution’s fitness for business purpose is defined and implemented. Working closely with the rest of the Solution Development Team, the Business Ambassador guides the evolution of the solution, bringing other users’ input and ideas to the project as required. As a true ambassador, the role is responsible for the day-to-day communication channels between the project and the business. The Business Ambassador must have the desire, authority, responsibility and knowledge to be able to ensure that the right solution emerges to meet the business need. This does not necessarily imply a senior position within the organization, but a level of empowerment during the project to fulfil the role and an allocation of time to fully participate in the project as required.

10. D LGd course manual p. 70 - The Dynamic Systems Development Method is governed by eight principles. These principles establish the overarching rules every DSDM team must follow as they progress through the project. The eight principles of DSDM include: Focus on the business need; Deliver on time; Collaborate; Never compromise quality; Build incrementally from firm foundations; Develop iteratively; Communicate continously and clearly; and Demonstrate control.

11. B LGd course manual p. 73 - The Iterative Cycle is as follows: Identify — The team agree the objective of the next evolution of whatever is being developed at the moment; Plan — The team work out what needs to be done by whom to meet the current objective; Evolve — The planned activities take place in the agreed timescale; and Review — The results of the activities are checked to see if the objective has been achieved.

12. C LGd course manual p. 73 - In a DSDM project where time has been fixed, understanding the relative importance of things is vital to making progress and

keeping to deadlines. Prioritization can be applied to requirements, tasks, products, use cases, user stories, acceptance criteria and tests. MoSCoW is a technique for helping to understand priorities. The letters stand for: Must Have; Should Have; Could Have; And won’t Have this time

13. B LGd course manual p. 75 - Every Timebox can be begins with a Kick-off and ending with a Close-out meeting. The Timebox itself comprises three main stages or Iterations – Investigation, Refinement, Consolidation. Each stage represents a pass through the Iterative Development cycle. The longest cycle is the refinement stage.

14. A LGd course manual p. 79 - The core areas of focus for Crystal include: People; Interaction; Community; Skills; Talents; and Communications.

15. B LGd course manual p.79 - Cockburn developed different methods within the Crystal family to suit projects of varying team size that naturally required different strategies to deliver business value. The family uses colors to denote the “weight” of the methodology being used. As the project becomes larger, with more team members and is more mission critical to the organization the appropriate version adds more process.

16. C LGd course manual p. 80 - The seven common properties or practices of Crystal include: Frequent delivery, Reflective improvement, Close or osmotic communication, Personal safety, Focus, Easy access to expert users, and Automated tests, configuration management, frequent integration.

17. D LGd course manual p. 83 - There are seven principles that provide the foundation of Lean Software Development. These principles include: Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower the team, Build quality in, and See the whole.

18. C LGd course manual p. 83 - Only when all of the lean principles are implemented together, combined with strong "common sense" with respect to the working environment, is there a basis for success in software development. There are

three keys to seeing the whole: Defects accumulate during the development process; By decomposing big tasks into smaller ones and standardizing the stages of development defect root causes can be found and eliminated; Think big, act small, fail fast, learn rapidly.

19. B LGd course manual p. 85 - Muda is a Japanese word meaning "futility; uselessness; idleness; superfluity; waste; wastage; wastefulness", and is a key concept in the Toyota Production System (TPS) as one of the three types of deviation from optimal allocation of resources (muda, mura, muri).

20. A LGd course manual p. 86 - Value stream mapping is a lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from its beginning through to the customer. At Toyota, it is known as "material and information flow mapping". It can be applied to nearly any value chain.

21. D LGd course manual p. 85 - The Poppendiecks describe a number of Lean Software Practices they call tools that vary slightly from their equivalents in Agile Software Development. These tools include: Seeing waste; Value stream mapping; Set based development; Pull systems; Queueing theory; Motivation; and Measurement.

22. C LGd course manual p. 87 - The Poppendiecks created a unique model of waste know by the acronym TIMWOOD. It represented seven fundamental types of waste including: Transportation; Inventory; Motion; Waiting; Over-Processing; Over-Production; Defects

23. A LGd course manual p. 88 - Kanban, by contrast, is part of an approach where the "pull" comes from demand. Re-supply or production is determined according to the actual demand of the customer. In contexts where supply time is lengthy and demand is difficult to forecast, often, the best one can do is to respond quickly to observed demand. This situation is exactly what a Kanban system accomplishes, in that it is used as a demand signal that immediately travels through the supply chain. This ensures that intermediate stock held in the supply chain are better managed, and are usually smaller. Where the supply response is not quick

enough to meet actual demand fluctuations, thereby causing potential lost sales, stock building may be deemed more appropriate, and is achieved by placing more Kanban in the system. Taiichi Ohno stated that, to be effective, Kanban must follow strict rules of use.

24. D LGd course manual p. 87 - When using Kanban for Agile Development, there are several rules that must be applied. These include: Visualize the workflow; Limit WIP; Manage flow; Manage process policies explicit; Improve collaboratively.

25. A LGd course manual p. 90 - Kanban, by contrast, is part of an approach where the "pull" comes from demand. Re-supply or production is determined according to the actual demand of the customer. In contexts where supply time is lengthy and demand is difficult.

26. B LGd course manual p. 92 - SAFe or the Scaled Agile Framework, Disciplined Agile Delivery or DAD, LeSS and Nexus all represent common tools for scaling agile.

27. C LGd course manual p. 93 - The Agile Release Teach is guided by a Release Train Engineer who acts as the program manager. Additionally, the various teams are supported by a Train System Architect who facilitates the process of developing infrastructure for future program increments. Imagine three, four or five Scrum Teams who each have a backlog with four two week iterations defined, as these teams work on their backlog there is an additional, very senior technical resource working ahead of these teams so that when it is time for the next ART the architecture and Program Backlog is defined and ready for the team to begin work. At this time any new resources can jump on the new release train and the process begins. Therefore, the best advice is join the team when the next release train is preparing to leave the station.

28. A LGd course manual p. 94 - SAFe focuses on four core values. These values include: Alignment is a position of agreement or alliance. Visibility or transparency; Program Execution — It is not enough for an individual team to perform well. That still allows for the overall program to fail. Success is defined

by everyone focusing on the overall program; and Code Quality — The team must define what quality means for the program and then deliver that measure.

29. D LGd course manual p. 95 - SAFe is governed by nine principles that build on Lean, Systems Thinking, and Agile Development. In many respects these can be thought of as extension of the 12 Principles found in the Agile Manifesto. They include: Take a systems view; Understand the economics of the value chain; Develop systems iteratively and incrementally; Integrate and test frequently and adapt immediately; Manage risk, efficacy and predictability with fast, synchronous learning cycle; Limit work in process. Reduce batch sizes. Manage queue lengths; Synchronize with cross-domain planning and collaboration; Base milestones on objective evaluation of working systems; and Decentralize decision-making. Understand the economics of the value chain represents the idea that resources must understand the basics of how and organization delivers business value.

30. C LGd course manual p. 64 - DSDM is both iterative and incremental. This means it is just like every other Agile methodology. It fixes cost, quality, and time at the beginning of the project. This makes it somewhat unique. Most Agile methodologies play an interesting game with the traditional Triple Constraints of Project Management.

31. A LGd course manual p. 64 - DSDM is most often used to provide an overall project framework in conjunction with Scrum. DSDM advocates it is the ideal wrapper for more limited Agile frameworks, and DSDM provides the full project focus while a method like Scrum focuses on the product development process.

32. D LGd course manual p. 64 - DSDM was created in 1994 to add discipline to Rapid Application Development. It was originally designed It was originally designed to be compatible with both ISO 9000 and Prince2.

33. A LGd course manual p. 64 - DSDM has gone through a number iterations beginning with its first rebranding in 2007, when the name was changed to DSDM Atern. The addition of Atern was a reference to the Artic Tern, a collaborative bird that can travel distances and epitomized many parts of the

method in its natural behavior such as prioritization and collaboration. In 2014, the framework was revised again and the name changed back to just DSDM. Today, DSDM is most often used to provide an overall project framework in conjunction with Scrum. DSDM advocates argue it is the ideal wrapper for more limited Agile frameworks. Advocates argue DSDM provides the full project focus while a method like Scrum focuses on the product development process.

34. C LGd course manual p.66 - There are a number of prerequisites required for using the Dynamic Systems Development Method. One of these is the acceptance of the Atern philosophy before starting work. This philosophy is relatively simple. A project must be aligned to clearly defined strategic goals of the organization. The team must then focus on the early delivery of real benefits to the business. According to the philosophy, this is best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level and collaborate to deliver the right solution. This solution must be delivered in the agreed timescale and according to the priorities set by the business.

35. B LGd course manual p.67 - There are a number of prerequisites required for using the Dynamic Systems Development Method. One of these is the commitment of senior business management to provide the necessary Business Ambassador involvement. Stakeholders are not allowed to assign work to the team and walk away from the project. It is assumed that a Business Ambassador will be involved daily with the project team.

36. A LGd course manual p.66 - There are a number of prerequisites required for using the Dynamic Systems Development Method. These include: Acceptance of the Atern philosophy before starting work; Appropriate empowerment of the Solution Development Team; Commitment of senior business management to provide the necessary Business Ambassador involvement; Incremental delivery; Access by the Solution Development Team to business roles; Solution Development Team stability; Solution Development Team skills; Solution Development Team size; And a supportive commercial relationship.

37. D LGd course manual p. 66 - This philosophy is relatively simple. A project must be aligned to clearly defined strategic goals of the organization. The team must then focus on the early delivery of real benefits to the business. According to the

philosophy, this is best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level and collaborate to deliver the right solution. This solution must be delivered in the agreed timescale and according to the priorities set by the business. The stakeholders must be prepared to accept a fit-for-purpose solution. They must also be prepared to accept that change is inevitable as the team comes to understand more about the solution being delivered.

38. B LGd course manual p. 66 - This philosophy is relatively simple. A project must be aligned to clearly defined strategic goals of the organization. The team must then focus on the early delivery of real benefits to the business. According to the philosophy, this is best achieved when key stakeholders understand the business objectives, are empowered to an appropriate level and collaborate to deliver the right solution. This solution must be delivered in the agreed timescale and according to the priorities set by the business. The stakeholders must be prepared to accept a fit-for-purpose solution. They must also be prepared to accept that change is inevitable as the team comes to understand more about the solution being delivered.

39. C LGd course manual p. 70 - DSDM advocates 13 specific roles within a project. These roles have varying degrees of importance. However, a key differentiator of DSDM compared to other Agile Methodologies is how detailed these roles are and how much emphasis is placed on them. Atern identifies roles in three categories: Project, Solution Development and Other. The business interests are represented by the Business Sponsor, Business Visionary, Business Ambassador, Business Analyst and Business Advisor. The solution/technical interests are represented by the Technical Coordinator, Team Leader, Solution Developer and Solution Tester. Management and ‘other’ interests are represented by the Project Manager, Workshop Facilitator and Atern Coach. On an Atern Project, one role may be taken by several people, or one person may take several roles.

40. D LGd course manual p. 70 - DSDM advocates 13 specific roles within a project. These roles have varying degrees of importance. However, a key differentiator of DSDM compared to other Agile Methodologies is how detailed these roles are and how much emphasis is placed on them. Atern identifies roles in three categories: Project, Solution Development and Other. The business interests are

represented by the Business Sponsor, Business Visionary, Business Ambassador, Business Analyst and Business Advisor. The solution/technical interests are represented by the Technical Coordinator, Team Leader, Solution Developer and Solution Tester. Management and ‘other’ interests are represented by the Project Manager, Workshop Facilitator and Atern Coach. On an Atern Project, one role may be taken by several people, or one person may take several roles.

41. A LGd course manual p.70 - DSDM advocates 13 specific roles within a project. These roles have varying degrees of importance. However, a key differentiator of DSDM compared to other Agile Methodologies is how detailed these roles are and how much emphasis is placed on them. Atern identifies roles in three categories: Project, Solution Development and Other. The business interests are represented by the Business Sponsor, Business Visionary, Business Ambassador, Business Analyst and Business Advisor. The solution/technical interests are represented by the Technical Coordinator, Team Leader, Solution Developer and Solution Tester. Management and ‘other’ interests are represented by the Project Manager, Workshop Facilitator and Atern Coach. On an Atern Project, one role may be taken by several people, or one person may take several roles.

42. B LGd course manual p. 70 - The Dynamic Systems Development Method is governed by eight principles. These principles establish the overarching rules every DSDM team must follow as they progress through the project. The eight principles of DSDM include: Focus on the business need; Deliver on time; Collaborate; Never compromise quality; Build incrementally from firm foundations; Develop iteratively; Communicate continuously and clearly; and demonstrate control.

43. C LGd course manual p. 70 - The Dynamic Systems Development Method is governed by eight principles. These principles establish the overarching rules every DSDM team must follow as they progress through the project. The eight principles of DSDM include: Focus on the business need; Deliver on time; Collaborate; Never compromise quality; Build incrementally from firm foundations; Develop iteratively; Communicate continuously and clearly; and demonstrate control.

44. C LGd course manual p. 70 - Focus on the business need — The main acceptance criteria for every project is delivering something that addresses the defined business need. This principle includes several components: Clearly define the scope of the system; Understand the true business priorities; Establish a sound business case; Seek continuous business sponsorship and commitment; Guarantee the minimum usable subset of features.

45. B LGd course manual p. 71 - I am sure that this is news, but delivering on time is kind of a big deal. There are many situations where delivering a project late can undermine the very reason for doing the project in the first place. DSDM focuses the team on this principle by: Timebox project work. This means that the end date of each iteration is fixed. Focus on business priorities. Technology is not an end unto itself. The product of the project must serve a business need And, always hit deadlines. This should be obvious, but it doesn’t happen very often.

46. A LGd course manual p. 71 - Decisions must be made with users and developers working together quickly. When a team works collaboratively they almost always outperform groups of individuals working independently. Components of collaborate include: Involve the right stakeholders, at the right time, throughout the project; Ensure that the members of the team are empowered to make decisions on behalf of those they represent without waiting for higher-level approval; Actively involve the business representatives and build a one-team culture.

47. C LGd course manual p. 71 - Never compromise quality — The level of quality must agreed upon at the beginning of the project. Quality cannot be a variable thing. The measure of quality must be quantitative and objective so that both the business and the development team can agree when the features that are part of the minimum usable subset is complete. In order to achieve this result the team must: Set the level of quality at the beginning. Make sure everyone involved in the project understands what success looks like and how it will be measured. Once missed, expectation can lead to disaster. The components of never compromising on quality include: Ensure that quality does NOT become a variable. Quality must be binary. It cannot be a sliding scale. The team must have a clear cutoff; Design, document, & test appropriately. The team must use the appropriate level of design, testing and documentation for the complexity and

importance of the project; Build in quality by constant review. Every Agile project makes use of an iterative process. These loops allow the team to constantly evaluate their output to ensure it correctly meets the quality standards; Test early and continuously; and testing cannot be something done only at the end of the project. The team must test early to catch errors when they are small and never assume they have tested enough.

48. D LGd course manual p. 72 - Incremental delivery provides a number of advantages. An easy way to understand incrementalism is to think about bite-sized chunks. It is much easier to swallow a small bite as opposed to a large one. It also give you confidence that you actually like what you are eating. It is the same for the customer of a software project. Constantly seeing working software confirms the team is building what they want gives them confidence in the team. It also provides a primary point of feedback for the team. Finally, when these increments are regularly deployed, the organization gains early business value. Keys to this principle include: The team striving for early delivery of business benefit wherever possible; The team continually confirming the correct solution is being built; And formally re-assess priorities and ongoing project viability with each delivered increment.

49. B LGd course manual p. 72 - As we have already learned, iterative development is very closely related to incremental development. Both are also key to Agile. Iterative development is a fancy way of saying short, repeating or looping cycles. The premise is that rarely does a team get things perfect the first time. In most cases, the team needs several cycles with repeated feedback from the customer to get it right.

50. C LGd course manual p. 72 - One of the biggest causes of project failure is poor communication. DSDM uses a variety of techniques to improve overall communication for both teams and individuals. DSDM focuses the team on the value of human interaction through the Daily Standups, Facilitated Workshops, and clearly defined roles and user involvement. The extensive use of modelling and prototyping help to ensure the product of the project is available for early scrutiny. This principle requires the team: Run daily team stand-up sessions; Use facilitated workshops; Use rich communication techniques such as modelling and prototyping; Present iterations of the evolving solution early and often; Keep

documentation lean and timely; Manage stakeholder expectations throughout the project; and encourage informal, face-to-face communication at all levels.

51. A LGd course manual p. 72 - A DSDM team needs to be proactive when monitoring and controlling progress in line with the Foundations Phase products, especially the Business Case. You need to be able to prove you are in control. In order to fulfil this principle, Atern teams, especially the Project Manager and Team Leader, will: Use an appropriate level of formality for tracking and reporting; Make plans and progress visible to all; Measure progress through focus on delivery of products rather than completed activities; Manage proactively; and evaluate continuing project viability based on the business objectives.

52. B LGd course manual p.78 - Crystal is usually described as a “light-weight methodology”. The use of the word Crystal comes from the gemstone where, in software terms, the faces are a different view on the “underlying core” of principles and values. The faces are a representation of techniques, tools, standards and roles. The methodology tends to avoid any strict or rigid processes found in other methodologies.

53. A LGd course manual p. 79 - Cockburn define the core areas of focus for Crystal. These are as follows: People, Interaction, Community, Skills, Talents, Communications.

54. C LGd course manual p. 79 - The table at the bottom of the page defines the team size for each version of Crystal: 2-6 people Crystal Clear; 7-20 people Crystal Yellow; 10-40 people Crystal Orange; Crystal Orange Web; Up to 80 people Crystal Red; Then Crystal Maroon; Crystal Diamond; Crystal Sapphire.

55. B LGd course manual p. 79 - The table at the bottom of the page defines the team size for each version of Crystal: 2-6 people Crystal Clear; 7-20 people Crystal Yellow; 10-40 people Crystal Orange; Crystal Orange Web; Up to 80 people Crystal Red; Then Crystal Maroon; Crystal Diamond; Crystal Sapphire.

56. A LGd course manual p. 79 - The table at the bottom of the page defines the team size for each version of Crystal: 2-6 people Crystal Clear; 7-20 people Crystal Yellow; 10-40 people Crystal Orange; Crystal Orange Web; Up to 80 people Crystal Red; Then Crystal Maroon; Crystal Diamond; Crystal Sapphire.

57. D LGd course manual p.80 -The various versions of Crystal share seven common properties or practices. Like the other Agile methodologies we have already covered, these can be thought of as general rules Crystal expects to be followed. These properties include: Frequent delivery; Reflective improvement; Close or osmotic communication; Personal safety; Focus; Easy access to expert users; Automated tests, configuration management and frequent integration.

58. A LGd course manual p. 80 - Frequent delivery is the regular releasing of iterations of the software program. This idea comes from the 12 Principles of Agile Development. Designers and developers decide what features to include in each release and they design and test for each release. With Crystal Methods, iterations are to be released in short iterations with the timescale being somewhere between weekly to quarterly. By releasing iterations, stakeholders are able to spot problems earlier in the project which saves a lot of hassle later on. Another point on this is that if the end users decide that the project does not do things the way they’d like it to be done, then steps can be taken to resolve this before it is too late. With Crystal Methods, there can be more than one iteration in a release. This is because it may not be feasible to release every iteration, so a collection of iterations are gathered and delivered in a single release.

59. C LGd course manual p. 80 - Reflective improvement involves the Development Team periodically taking a break from regular coding efforts to focus on finding ways to improve their processes. Iterations help with this by providing feedback on whether or not the current process is working. Crystal Methods, uses Reflection Workshops that meet every couple of weeks. These workshops focus on finding processes that are and are not working well then helping the team to modify those processes so they improve.

60. A LGd course manual p. 80 - With regards to larger teams (over 8 or so), where distraction can arise, Close Communication is used. The team must be in the

same room for this to work. This is because if the developer has to break concentration to move somewhere else to ask a question then his or her thought process will is often lost. By using this type of communication, information flows quickly throughout the team. Questions can be rapidly answered and all the team members know what is going on as well as having the ability to correct any misconceptions that may arise. By listening to the others in the team, a developer can pick up on what the others are doing, gain experience and develop new ideas. Developers working near each other can help with problems that the other is encountering. Communication overhead is greatly reduced by using this type of communication. The need for email updates, extra documentation, etc. is lowered. By having the team together, each member knows what the others are doing so they should be able to take over their teammate's parts of the project as required.

61. D LGd course manual p. 81 - Focus in crystal refers to two things; firstly focusing on an individual task in a project for enough time that progress will be made and secondly, it refers to the direction of which the project is heading. With the first, the flow of progress is taken into account while thinking of issues that affect it such as interruptions, meetings, long questions, phone call, etc. It can take a while to get back into the flow again so this delays completion of the current task. Crystal defines two rules for dealing with issues that may interrupt focus. One is to set a two-hour period where the developer is to have no interruptions. The other one is to assign a developer to a project for at least two days before being switched to another project. With the second meaning of focus, issues such as definition of goals are discussed. The definitions should be clear and the developers should know exactly what the goals of the project are. The project leader should prioritize the goals which will allow developers to focus on particular areas.

62. B Lgd course manual p. 81 - Easy access to expert users involves the developers working with a person of expertise in the project area so that the expert can answers any questions, suggest solutions to problems, etc. The expert user should be an actual/real-life user and not just a tester from the development team. The more involved the expert user is (in practical terms), the better since they would have more hands-on experience. The more time that the expert user can give will greatly help the overall project but this is not always feasible. There should be a minimum of a once a week, two-hour meeting with the expert user, and the ability to make phone calls to the expert user too.

63. C LGd course manual p. 82 - The Lean Philosophy regards everything not adding value to the customer as MUDA or waste. This waste comes in several forms: Unnecessary code and functionality; Delay in the software development process; Unclear requirements; Avoidable process repetition (often caused by insufficient testing); Bureaucracy; And slow internal communication.

64. A LGd course manual 84 - The Lean approach focuses on the simple rule, find good people and then trust them to get the job done. Good managers encourage, remove impediments and avoid micro-managing. The developers should be given access to the customer; the team leader should provide support and help in difficult situations, as well as ensure that skepticism does not ruin the team’s spirit. The most effective teams use a Work-Out Technique when the managers do NOT tell workers how to do their job. The guidelines include: Find good people and let them do their own job; Encourage progress, catching errors, and removing impediments; Discourage micro management; People are more than just resources. They require motivation and a higher purpose; and the developer should be given access to the customer.

65. C LGd course manual p. 82 - The Lean Philosophy regards everything not adding value to the customer as MUDA or waste. This waste comes in several forms: Unnecessary code and functionality; Delay in the software development process; Unclear requirements; Avoidable process repetition (often caused by insufficient testing); Bureaucracy; and slow internal communication.

66. D LGd course manual p. 89 - When using Kanban for Agile Development, there are several rules that must be applied. These include: Visualize the workflow; Limit WIP; Manage flow; Make process policies explicit; and Improve collaboratively.

67. B LGd course manual p. 90 - Scrum Boards tend to change infrequently. Once the Development Team builds the Board they do not typically add or delete columns. The tool is so simplistic that doing so seldom makes sense. Kanban Boards DO change frequently. A Kanban Board is supposed to reflect the process being used. As the process evolves and changes the Board must change with it.

68. A LGd course manual p. 90 - Scrum often represents the best starting point for those new to Agile Development. Its rules, roles and constructs are usually the easiest to teach and execute.

69. B LGd course manual p. 91 - XP is all about testing. If the team is already experienced with Scrum or some other Agile Methodology and is focused on improving product quality this is a great choice, but remember XP is truly ruthless in its testing mantra. If the team lacks the tools or skills in this area XP won’t give you the tools, but it will quickly point out the problem.

70. B LGd course manual p. 93 - SAFe begins with level I. This is the portfolio level. At the portfolio level, strategic themes are used to connect the portfolio of projects to the organizational strategic objectives. This level also requires budgeting be completed for the entire program. Remember, programs represent groups of related projects managed in a coordinated way to obtain a shared value for the organization. Each program is referred to as an Agile Release Train or ART in SAFe. Then, Epics are created to fund cross ART training or deliverables. SAFe makes use of Kanban at the portfolio level to represent Agile Release Trains.

71. D LGd course manual p. 93 - Each ART is made up of between 50 and 125 people. Within each Train are groups of related project teams. Individual resources are not trapped, if they miss an Agile Release Train they are able to catch the next one because they occur at regular intervals.

72. C LGd course manual p. 93 - In the SAFe the increments of a Release Train are called Program Increments or PIs. Each PI is made up of five timeboxed iterations by default. The length of time these iterations take is dependent on the methodology used by the team specifically executing the project.

73. C LGd course manual p. 93 - Four of these iterations are focused on the delivering features found on the Product Backlog, and one iteration is used for incremental planning. This single iteration allows the team to deal with unexpected issues or generate previously un-thought of creative solutions to issues.

74. C LGd course manual p. 93 - 4 of these iterations focus on the delivering features found on the Product Backlog, & one iteration is used for incremental planning. This single iteration allows the team to deal with unexpected issues or generate previously un-thought of creative solutions to issues. Through this process the team makes used of a session called the Inspect and Adapt Workshop designed to allow the entire ART to come together and improve the overall operation of the program.

75. D LGd course manual p. 93 - The Agile Release Teach is guided by a Release Train Engineer who acts as the program manager.

agile certified practitioner (acp) exam prep course 3b ...€¦ · agile certified practitioner...

Documents