PMI DASSM

Module 1 – Team Development for High Performance Teams

 Provides knowledge to properly address conflicts that may arise +
to learn to grow the team overall
 DASSM
o Requires superior people skills to be effective
o Responsibilities fall somewhere between Functional Manager || DASM
o Leads implementation/development team
o Guides team through joint decision-making
o Has knowledge on how to work with upper management levels
o Equipped to deal with more complex work challenges than a DASM
o Requires more skills in planning + metrics + reporting
o Takes an active role in team development
o How DASSM serves Team:
 Coaches team members in self-organization + cross-functionality
 Helps team focus on creating high volume increment to meet the
DoD (Definition of Done)
 Helps remove impediments
 Ensure that events are positive productive within a time box
o How DASSM serves PO:
 Find techniques for effective product goal definition + backlog
management
 Helps the team to understand the need for clear & concise backlog
items
 Facilitates stakeholder collaboration as requested/needed
o How DASSM serves Organisation
 Leads + trains coaches & assists in agile adoption
 Plans, advises & assists agile implementation
 Help employer & stakeholders understand and work in complex
environments
 Remove barriers between stakeholders and the team
 DA Mindset
o Based on a combination of agile + lean thinking

1|Page
 o
 Flow
 Life cycles  Started pack for teams that provide them
with a foundation for their WoW
 People
 Roles, Responsibilities & Team Structures
 Practices
 Goal Diagrams
 Agile Manifesto

o
 Lean Principles
o Eliminate waste
o Build Quality In
o Create Knowledge
o Defer Commitment
o Deliver Quickly
o Respect People
o Optimize the whole
 Principles (WHY we do what we do) – 8
o Delight Customer
o Be Awesome
o Context Counts
o Be Pragmatic
o Choice is good
o Optimise Flow
o Organise around Products and Services
o Enterprise Awareness
 Promises (HOW we work together) – 7
o Create psychological safety & embrace diversity
o Accelerate value realisation

2|Page
 o Collaborate productively
o Make all work and workflow visible (work in progress and work in
process)
o Improve predictability
o Keep workloads within capacity
o Improve continuously (GCI – Guided continuous improvement)
 Guidelines (WHAT makes us effective) – 8
o Validate our learning
o Apply design thinking
o Attend to relationships through value stream
o Create affective environments that foster joy
o Change culture by improving system
o Create semi-autonomous, self-organising teams
o Adopt measures to improve outcomes
o Leverage unenhanced organisational assets
 Team Development
o 3 Aspects of Team Development:
 Context (What the team does)
 Process (How the team works towards its objectives)
 Feelings (How do team members relate to one another)
o Bruce Tuckman Team Development Model (5 stages):
 Forming
 Members trying to identify who is who and where they fit
into the plan
 Team:
 very polite + reluctant to share thoughts
 Leader:
 Guide to create atmosphere of safety and
acceptance that avoids controversy and fosters team
building
 Involved in directing a number of tasks
 Context:
 Members may attempt to define the job to be done
 They may ask what their work/goal is
 Process:
 Some members might feel the need to look outside
the team for guidance & direction
 Feelings:
 People feel anxious and unsure of their role
 Most looking for leadership in the group to get
guidance
 How to foster team building

3|Page
  Provide security by communicating goals +
expectations
 Carry out activities to get the team acquainted &
build community to create atmosphere of safety +
acceptance
 Have team identify their areas of commonality
 Storming
 Introduces conflict + competition
 Team:
 Argues about work items + experiences tension
 Leader:
 Does not need to interfere in debates about work
 Should address interpersonal conflict
 Should practice coaching + conflict management 
Acknowledge conflicts and openly discussed issues
 Encourages conflicting opinions if expressed
appropriately
 Have each team member think about their
experiences with conflict and then meet in groups to
share + analyse experiences (have a couple of
groups share their insights with bigger group)
 Context:
 Members may become more resistant to demands as
work-related conflict and competition arise
 Process:
 Members may disagree on how to proceed with
certain tasks. They may refuse tasks or will find
reasons not to complete them as a way of protesting.
 Feelings:
 Team members are still trying to find their place in
the team and may feel uncertain. Some may express
concern about the structure of the team’s hierarchy.
 Norming
 Things start to normalize
 Team:
 Working out issues. Not quite high performing.
 Leader:
 Should demonstrate support and active participation
 Context:
 More open discussions around the team’s
challenges (smoother communication +
strengthened relationships)
 Process:

4|Page
  Team works to set up standards and procedures for
tasks
 Feelings:
 Members ignore individual differences + become
more accepting of each other’s ideas // appreciating
each person’s strengths and skills
 How to help team realize their full potential
 Provide opportunities to share skills + build trust.
They benefit from efforts to build team cohesion.
 Sharing, trust building & skill building activities are
optimal
 Have team members think about skill, hobby or
talent they know well + let them teach a group of
team members about it.

 Performing
 Provides feelings of unity, group identity, interdependence
& independence
 Team:
 Difficult to reach this stage
 May revert to Forming or Storming if resources
change
 Leader:
 Ensure the team stays intact and uninterrupted.
Fosters enthusiasm.
 Context:
 Tasks among members are allocated efficiently and
processes are in place
 Process:
 Team has confidence and experience to solve
problems and can use lessons learned to
 Feelings:
 Members share a common focus + enhanced
communications. More efficient team.
 How to motivate members:
 Delegate tasks and projects to empower + engage
team members’ increased motivation with more
responsibilities and opportunities to grow.
 Adjourning
 Team:
 Leader:
 Context:

5|Page
  Process:
 Feelings:
 Decision Making
o Involve all team members
o Avoid alienating team members (will miss an important opinion or
perspective)
o Group decision-making involves reaching consensus on the final solution
 Group Voting Methods
o Simple Voting
 Quick but misses opportunity for decision refinement
o Thumbs up/down/sideways (explain why they could not make a decision)
o Highsmith’s Decision Spectrum
 Members indicate with tick marks along a spectrum how they feel
about the decision
 “Fully in favour”, “Mixed Feelings”, “Veto”
 Allows people to air reservations
o Fist of Five
 Five fingers ranging from full support to full objection
 Allows people to air reservations

6|Page
Module 2 – Emotional Intelligence for High Performing Teams
 Use emotional intelligence to interact with + support the team
 Emotional Intelligence
o Ability to assess and manage emotions and influence and guide the
emotions of others
o 5 Components (Daniel Goleman)
 Emotional Awareness – knowing what one is feeling and its impact
on others
 Self-regulation – controlling one’s emotions
 Motivation – using emotional factors to achieve goals
 Empathy – sensing the emotions of others
 Social skills – managing relationships + inspiring others
o Benefits:
 A leader must know how to manage emotions in a positive,
constructive way before they can effectively lead others
 Allows you to provide better support so team members have what
they need to be successful
 Fosters open + transparent communication  members feel safe
expressing themselves
 Leads you to consider team adversity
 Fosters a sense of trust + safety (members feel like they belong)
 Means trusting team members and empowering them to make their
own choices
o 4 Quadrants Model:


 Quadrant 1 – Self-Awareness
 Ability to recognize your own emotions and how they
affect your thoughts and behaviour
 Self-confidence
 Emotional self-awareness

7|Page
  Accurate self-assessment
 Quadrant 2 – Self-Management
 Manage your emotions in a productive + healthy way.
Follow through, adapt to change, take initiative, continue to
persevere
 Self-Control
 Conscientiousness – promoting the greater good
 Adaptability
 Drive & Motivation
 Quadrant 3 – Social Awareness
 Ability to connect with others. Showing empathy for
others’ emotions and concerns helps establish relationships
 Empathy
o Cognitive Empathy – mentally putting yourself in
their position
o Emotional Empathy – feel the emotion for another
person’s feelings
 Organizational Awareness – ability to recognize the
organizational environment in which team members work
 Understanding the Environment – Considering today’s
work environment before attempting to interact
 Quadrant 4 – Social Skills
 How we affect others
 Influence
 Inspirational Leadership
 Developing others
o Psychological Safety
 Subset of emotional intelligence that correlates to Social Skills
 Effective leaders strive to create a psychologically safe
environment where members are comfortable asking questions and
expressing their opinions
 Safety Types:
 Inclusion
o Embraces diversity by accounting for different
personality types, communication styles and making
team members feel welcome
 Learner
o Encourages team members to learn + grow
 Contributor
o Allows for creativity
 Challenger
o Team members feel confident to challenge status
quo

8|Page
 Emotional Quotient (EQ)
o Measurement of one’s ability to identify, assess and manage emotions and
then influence + guide the emotions of others.
 IQ (technical aptitude to perform your job) peaks in our 20s but EI develops
through adult life, can improve with practice and benefits us in many areas of our
life
 Effectively managing your emotions will positively impact your performance and
make you a more valuable team lead.
 Neuroplasticity
o Brain’s ability to form new bonds and pathways and change how its
circuits are wired when learning something new
 Teamwork & Collaboration
o Working together toward a common goal
o Ways of building consensus:
 Roman voting (thumbs up/down)
 Fist of Five
 Planning Poker – used for team estimation (work items are
estimated based upon relative points)
 Retrospective Action Dot-Voting – coloured dots used to vote on
the action items that are more important

9|Page
Module 3 – Business Agility & Tactical Scaling
 Business Agility
o Organization ability to rapidly adapt to market + environmental changes in
a productive + cost-effective way
o Focuses on value by having stakeholders identify, prioritize and sequence
the work to be done + allocate it appropriately
o Enables the realization of the highest value in a shorter amount of time,
predicably, sustainably and with high quality.
o By working in small delivery increments, we continuously adjust to what
is needed, enabling the org to change directions at low cost
o Also referred to as Organizational/Enterprise Agility
 Rolling Wave planning
o Planning technique where the near-term work is planned in detail, while
far-term work is planned at higher level
 DA Tool Kit
o Choose the way you work based on the situation you face
o Make decision based on team’s context
o Choose the lifecycle
o Pull from variety of proving strategies from multiple frameworks and
practices
o 4 Levels of Detail:
 Process Goals (Process capability)
 Captures the detailed, process-related decisions and options
for a cohesive subset off a team’s WoW
 Provides guidance so that a team can tailor and scale agile
strategies to the context of the situation they face
 Grouped according to the life-cycle phase where they occur
 Goal Diagrams
 List of Options
 Options Descriptions & Trade-offs
o 4 Layers:
 Foundation
 Process Blades:
 Mindset
 People
 Agile
 Lean
 Serial

10 | P a g e
  WoW
 Disciplined DevOps
 Process Blades:
 DAD (Disciplined Agile Delivery)
DAD Roles:

 Security
 Data Management
 Release Management
 Support
 IT Operations
 Value Stream
 Disciplined Agile Enterprise
 Tactical Scaling
o Requires a clear sense of where the team falls in each Scaling Factor (The
level of complexity will have an impact on a variety of DAD process
goals)
o How to Choose/Evolve WoW:
 Analyse Context
 Essential 1st step in making any lifecycle or process
decision
 Select best fit lifecycle
 Connect the dots
 Given your context on lifecycle, identify the process goals
+ diagrams you should consider first
 Make some choices

11 | P a g e
  Within the most relevant goal diagrams make some choices
for the team’s WoW. Choose 1+ decision points and then
options within them you like to try
 Practice Continuous Improvement
 With the WoW established, create the habit of continuously
improving  if an option chosen does not work for you,
experiment, go back and try another until you get what you
want

o 2 Primary Scaling Types:

 Tactical Agility at Scale
 Application of Agile + Lean strategies on individual
discipline, agile delivery teams
 Strategic Agility at Scale
 Application of Agile + Lean strategies broadly across the
entire organization
o Scaling Factors
 Aspects of a team’s context that range in complexity
 By analyzing SFs, you can better understand your team’s context +
what to consider when improving your processes
 Spider Diagram:

 Team Size
 2 to 250+ people

12 | P a g e
  Affects how you organize the team and how you
coordinate within the team
 Geographic Distribution
 The more members dispersion the more difficult to
coordinate  more sophisticated communication
and coordination methods required
 Organizational Distribution
 How homogeneous the team is (What
organizational unit or company do people come
from?)
 Compliance
 Conforming to financial, privacy or even life critical
regulations require extra documentation, reviews
and reporting
 Technical Complexity
 The greater it is, the greater the need for more
upfront modelling or more sophisticated testing
throughout the lifecycle
 Domain Complexity
 Area the team will be working in
 The more complex, the more upfront modelling,
planning and sophisticated testing are required

13 | P a g e
Module 4 – Optimizing How We Work with the Disciplined DevOps
Layer

 Disciplined DevOps Layer in the DA Tool Kit

 6 Process Blades
o Disciplined Agile Delivery (DAD)
 People 1st
 Learning oriented
 Hybrid agile approach
 Risk value oriented delivery
 Goal driven
 Enterprise aware
 Scalable
o Security
 Focuses on how to protect your organization from information and
virtual + physical threats
 Policies will affect org strategies around:
 Change management
 Disaster Recovery & business continuity
 Solution delivery
 Vendor management
 Goal Diagram:

14 | P a g e
o Data Management
 Development, execution and supervision of plan, policies, program
and practices that control, protect, deliver and enhance the value of
the data and the information assets
 Optimise the entire workflow
 Support the overall need of your organization
 Provide the right data to the right people at the right time
 Goal Diagram:

o Release Management
 Encompasses planning, coordinating and verifying the deployment
of IT solutions
 Requires collaboration by the delivery teams and the people
responsible for the organization’s operational IT infrastructure
 Goal Diagram:

o Support (Help desk or end user support)

15 | P a g e
  Support activities help end users to work with solutions produced
by delivery
 Last line of defence in efforts to delight customers
 Goal Diagram:

o IT Operations
 Run trustworthy IT ecosystem  Challenge for older orgs due to
multiple legacy systems hindered by technical debt (result of
cutting corners on quality to deliver product faster)
 Tech Debt comes in the form of:
 Poor quality data
 Inadequate automated regression tests
 Insufficient expertise
 Different versions of the same system
 Numerous technology platforms
 Several systems offering similar functionality
 Goal Diagram:

16 | P a g e
 Working with the Disciplined DevOps Layer:
o Allows for continuous delivery model  New features, config changes,
bug fixes and experiments get in the hands of users safely, quickly and in
a sustainable way
o Goal is to make deployments predictable, low risk and routine affairs that
can be performed on demand
 DA Supports 2 Continuous Delivery Lifecycles:
o Agile
 Common for stable/long-lived teams
 Iterations are typically 1-2 weeks – At the end of each iteration,
you release into prod
 More like a very regular delivery lifecycle than a continuous
delivery

o Lean

17 | P a g e
  Delivers increments more frequently (several times in a day in
some cases)


Requires a mature set of practices around continuous integration and

deployment in order to be practical.
 Also requires technical infrastructure and advanced practiced

 Allies – work with the other teams that are part of the same value stream as your
projects and share your team’s interests.
 BizDevOps – Brings business into DevOps
 DevSecOps – Brings information security into DevOps. Security strategies
include:
o Collaborative security engineers
o Exploit testing
o Real time security monitoring
o “Rugged software” that has built in security controls
 DataDevOps – Brings data management issues into DevOps.
o Streamlines data management process and enables faster release of
database changes

18 | P a g e
 Dealing With Defects
o At each stage in the development and employment process, detecting a
defect is possible using common code completion, compiling and loading
tools and processes (e.g. Intellisense, dynamic loading…)
o Cannot prevent defects but can detect them earlier
 Test Driven Development (TDD)
o Process that relies on iterations
o Software requirements are turned into very specific test cases
o Code is written and refined until it passes the test
o Allows devs to detect defects during development
 Capturing Quality Requirements
o Acceptance Criteria – Motivates teams to think through detailed
requirements but many quality requirements cut across several functional
stories and relying on acceptance criteria alone risks missing requirements
later identified in development
o Technical Stories
 Works well for point specific requirements but most quality
requirements are applicable to multiple functional requirements
o Explicit list
 One single place for all quality requirements but you need a
strategy (search acceptance criteria) to ensure the quality
requirements are implemented for each appropriate functional
requirement
o Definition of Done (DoD)
 Common quality verification method
 Defines minimum criteria that a work item must meet before our
stakeholders accept it as completed
 Should be readily available to all team members
 Include it in Accelerated Value Delivery goal / Verify Quality of
Work decision point

19 | P a g e
  Challenges:
 What a dev considers done might not be what a stakeholder
considers done
 Different stakeholders will have different “Doneness”
criteria
 Potential Criteria:
 Sufficient unit/integration/user tested
 Documented
 Under configuration management
 Deployment scripts written + tested
 Passed peer/automated preview

Module 5 – Optimizing How We Work with the Value Stream layer

 Value Stream
o Set of actions that take place to add value for a customer from the original
request through the realization of value by the customer
o Each team is part of a VS, but for it to be truly effective all the parts
must be aligned to maximize realization of value
o Visualize the work being done so you can understand and avoid
challenges across the value stream.
o Sequence of activities an org undertakes to deliver a product or service or
family of related products and services to a customer
o Begins + ends with a customer  What problems or needs do they have?
What can we do to fulfill them? How can we delight the customer and
how do we do so? How can we do better?
o Most org structures and management impede the flow of value. At a team
level:
20 | P a g e
  Minimize impediments
 Make sure improvements made do not make things worse for other
teams
 Focusing on the throughput of value
o Agile helps:
 Better deal with handoffs, miscommunications, bottlenecks and
silos
 Avoid handoffs through better collaboration and dependency
management
 Brings together the front + back of the organization
 Value Stream Impedance
o Measure of resistance faced by work in the VS. Impediments create delays
+ lead to more work and more delays
o Causes:
 Team factors
 Workload on its relation to capacity
 Level of collaboration
 Degree of customer focus
 Sequence the work is done in (testing first lowers this)
 How people are both geographically and managerially
located
 Value Stream factors
 VS efficiency
 Batch size (how big is the amount of work to be done in the
VS)

 Product factors:
 Visibility of the work and the workflow (profile of the
work within the enterprise)
 Quality of the product
 Blocker factors:
 Number or size of the work in progress
 Too much work in progress (overloaded team)
 Handoffs and hand-backs in the workflow (causes of team
delays)
 Too little automation
 Long feedback cycles (can cause rework delays)
 Structure/work disparity (disparity between management
structure and the way real work takes place
 What makes an ineffective VS?
o Handbacks / Handoffs / Rework / Integration errors / Multitasking / Poor
quality
21 | P a g e
 o Delays in workflow – getting feedback
o Waiting for people on your team (indicates poor process)
o Waiting for people on other teams (indication of poorly formed teams,
poor management of dependencies or workload or poor visibility of work
between teams)
 Understanding the VS

o Customer is at the top of the VS sharing their needs with your org
o Portfolio management examines the need to see how it fits in the org
strategies, goals and initiatives as part of the Discovery phase. The need
ends in the business backlog and passes to Product Management.
o Product Management analyzes + refines the need and uses it to identify 1+
MBIs (Minimum Business Increment). These MBIs are prioritized and
placed in the Development Intake queue (prior to implementation).
o The DASSM comes into place for the next phase, implementation. When
the team has capacity to begin work on a MBI the Product Owner moves it
to the development backlog and works with the DASSM to divide the
MBI into smaller pieces that are placed in the appropriate team backlog
o The team members work with the DASSM for development, integration,
deployment and support. Then it returns back to the customer for revisions
or additional work and the process starts all over again
 VS layer

22 | P a g e
o 1 of 4 layers of the DA landscape
o DA Toolkit:
 Foundation
 Provides the conceptual underpinnings of the DA toolkit
 Disciplined DevOps
 Nested inside of the VS and is composed of the TI process
blades
 Value Stream
 Nested inside of the DA Enterprise and contains the
capabilities that make up a VS. The top row 7 process
blades are shared with DA Enterprise, while the next
row contains blades solely applicable to the VS layer
 DA Enterprise
o VS Layer Process Blades:
 Research & Development
 Exploring ideas for new products and services
 Business operations
 Providing services for customers and to support your
products
 Business operations include helpdesk and support services
– integrated with IT support where appropriate – and
technical sales support activities like training, product
installation and product customization
 Strategy

23 | P a g e
  Identifying, measuring, evolving and communicating the
org’s desired outcomes
 Governance
 Monitoring and guiding teams, enabling them by removing
or at least reducing any barriers they might experience
 Marketing
 Successful interactions between the org and outside world
 Continuous improvement
 Easily systematically sharing improvement learnings,
creating feedback loops between teams through which a
learning culture emerges, increasing the chance that you are
learning at both the team and org levels
 Sales
 Selling the org products and services to customer
 Portfolio Management
 Identifying, prioritizing, organizing and governing various
endeavors. Disciplined Agile portfolio management seeks
to do this in an effective and streamlined manner that
maximizes the creation of business value in a long-term
sustainable manner
 Product Management
 Identifying, prioritizing potential products and services
(offerings) to support the organization strategy including:
o Formulating the vision for each offering
o Working with customers to understand their high-
level needs
o Identifying, prioritizing and allocating Minimum
Business Increments (MBIs)
o Identifying and managing functional dependencies
between offerings
o Marketing offerings to potential customers
o Monitoring the marketplace to identify future
customer needs
 Program Management
 Large team composed of 2+ sub-teams (squads)
 Coordinates the effort of the squads to ensure they work
together effectively towards the common goal of producing
a consumable solution for the stakeholders
 MBIs & MVPs
o The way to optimize your VS is to release the smallest amount of work
possible while still realizing value
o MBI

24 | P a g e
  Allow you to release a piece of work
 When you use incremental releases to expand or enhance an
existing product or service you use an MBI to figure out what each
of these releases should contain
 Smallest releasable chunk of value that makes sense from a
business perspective
 Figure out an MBI by answering these questions:
 Who is it for?
 Do use cases exist? (Have you developed cases to describe
the value?)
 Does it meet your DoD?
 What is needed to develop it?
 What teams will be involved?
 Are there any systems or application architectural issues
that need to be explored?
 Will you need documentation?
 Will you need marketing?
 Building the smallest enhancement to an existing product
(Investment made to build revenue)
o MVP (Minimum Viable Product)
 Allow you to experiment + learn what the product should do
 Useful for:
 Early experimentation
 Start-up situations
 Innovation
 Discovering what early adopters might want
 Helpful when:
 Value is not yet known
 You are building a new product or service
 You need to test the market for viability
 You don’t fully know what the customer needs
 You have a small, focused team to run experiments and
pivot when needed
 Smallest step to determine viability of new product without a
customer base (investment made for discovery)
 Developing & Delivering Value
o Activities:
 Implementing appropriate intake processes
 Using design thinking during development
 Carefully considering the user experience
o Intake Processes
 Should lead to one of several outcomes based on where you are in
your VS

25 | P a g e
  Discovery Intake: Well-defined development intake and planning
process that should focus on the most valuable items
 Planning & Allocation Intake: Should lead to planning based on
maximizing the realized value
 Development Intake: Should lead to teams working in common
cadence, coupled with frequent integration
 Portfolio Management
o Addresses how an org identifies, prioritizes, organizes and governs their
endeavors in an effective and streamlined manner
o Maximizes the realization of business value in a long-term sustainable
way
o Achieving successful Portfolio Management:
 Aligh teams to Value Streams  High performing agile teams
reliably deliver value frequently to their business stakeholders
 Rolling Wave over Annual Planning  Make planning a
continuous rolling wave activity year-round with more detail
devoted to planning initiatives no longer than 6 months out
 Optimize the whole  Strategy that makes it easier to manage
your portfolios but could inflict undue costs and bureaucracy on
the teams you are funding
 Govern by Risk, not by artifacts  Agile governance focuses on
addressing common risks, verifying that the architectural strategy
as been proven to be viable early in the life cycle, and ensuring the
team has proven to be viable early in the life cycle, and ensuring
the team has produced enough business value for the stakeholders
 Prefer small initiatives over large initiatives (easier to plan, lower
risk to execute)
o Rules for successful Portfolio Management:
 Keep it simple
 Focus on value over cost
 Reduce the cost of delay
o Achieving successful portfolio management within teams:
 Prefer a stable team over project teams  long lift stable teams,
whose membership evolves, have significant advantages over
short-lived project teams
 Enable diversity  Team must be allowed to organize themselves
and tailor their process to meet the context of the situation they
face
 Trust but verify  Effective teams monitor themselves using
automated dashboards technology and close collaboration, on the
metrics that teams collect should be made visible to senior
management and other stakeholders so that they may monitor what
is happening

26 | P a g e
  Invest in streamlining the creation of value  we sometimes need
to invest in ourselves through the process or environment
improvements
 Invest in quality  Allow IT teams to make investment in quality
to ensure the long-term sustainability of these IT teams
o Organizing around Products + Services
 It is critical to organize around offerings that we provide to our
customers
 Doing so enables us to identify and optimize the Value Streams,
thus delighting our customers
o Build cross-functional teams
 We build dedicated teams focused on delivering and offering.
These teams will be cross-functional and include people with:
 Sales skills
 Management skills
 Business analysis skills
 Dedicated cross-functional product teams that stay together over
time are the most effective in practice
o Process Blade
 Looks at one cohesive aspect of the overall organizational process
 Each PB addresses a specific organizational capability through the
following aspects:
 Mindset – each PB extends the DA Mindset with
philosophies that are specific to that blade
 People – each PB addresses specialist roles and sometimes
potential team structures which are specific to that blade
 Flow – each process blade describes the business process,
which is a common starting point for orgs new to agile
Ways of Working in that area
 Practice Options – DA provides a collection of process
options such as practices and strategies
 High level overview of Portfolio Management:

27 | P a g e
 Organizational Allies
o Helpful to know whom to talk to if you need help getting things done
 Enterprise Architecture
 Addresses strategies for supporting stakeholders
 Supporting delivery teams
 Evolving and capturing the enterprise architecture
 Governing the enterprise architecture efforts
 Governance
 May be called an oversight, audit or control
team/tribe/group/function – will monitor and guide teams
throughout your org
 Product Management
 Addresses strategies for managing a product, including:
o Allocating features to a product
o Evolving the business vision for a product
o Managing functional dependencies
o Marketing the product line
 Program Management
 Addresses strategies for managing large product / project
teams:
o Allocating requirements between sub teams
o Managing dependencies between sub teams
o Coordinating the sub teams

28 | P a g e
 o Governing a program
 Release Management
 Addresses strategies for planning the IT release schedule:
o Coordinating releases of solutions
o Managing the release infrastructure
o Supporting delivery teams

29 | P a g e
Module 6 – Coordinating and Collaborating Across Teams
 Leading teams to optimize flow
o Create an environment where teams can work efficiently
 Focus on crating flow with as little delay as possible. Doing so will
enable your workers to do their best and optimize value realization
for your customer and org
 Optimize Flow
 Where Lean meets Agile, as expressed in one of the
principles of DA
 Looking at the flow of value enables teams to collaborate in
order to effectively implement their org’s Value Streams
 Although each team may be only part of the Value Stream,
they see how they might align with others to maximize the
realization of value
o Leading teams in a Complex Adaptive System (CAS)
 Your team affects other teams and vice versa
 This complexity can be dealt with and the team’s workflow
optimized by trying out coordination strategies under the
“Coordinate Activities” process goal

o Coordinate Activities
 Ongoing process goal, hence it is relevant and helpful to consider
at any time
 Provides options to coordinate and optimize Value Streams:
 Internally with the team
 With other teams within a program
 With teams across the org
 Between physical locations
30 | P a g e
  Supports the following aspects:
 Effective collaboration – By improving our coordination
strategies we can reduce or eliminate waste, especially wait
time and rework
 Autonomy – Work as autonomously as possible, yet still
collaborate effectively with others
 Working Agreement with Team – How we intend to
coordinate our activities internally
 Working Agreement with All the Teams – How others will
interact with our team. Having effective coordination
strategies in place enables our team to collaborate
effectively with others
 The corporate activities process goal helps answering some key
questions:
 How will we share info within the team?
 Who is allowed to update artifacts created by the team?
 How will we coordinate within the team?
 How can we facilitate working sessions (potentially with a
large or diverse group)?
 If we are part of a larger team, how will we coordinate
within it?
 How will we coordinate with other teams within our org?
 How will we coordinate with our release/deployment with
the rest of the org?
 How will we collaborate with geographically distributed
team members?
 Goal Diagram:

o Decision Points:

31 | P a g e
 Share Info – the more flexible and open the easier to coordinate
our efforts
 Non solo work (pairing, mob programming, modelling with
others)
 Informal reviews
 Formal reviews
 Individual (solo) work
 Artifact Ownership – helps determine rules regarding who is
allowed to access and update certain artifacts (the more flexible,
the less effort to coordinate usage and evolution of artifacts)
 Collective Ownership (XP) – Everyone may access and
update these artifacts
 Disparate Ownership – Access and update rights to certain
artifacts are restricted (i.e. only the DB admin may update
the data model)
 Coordinate Within Teams – two ways: continuous manner or as a
by-product of working together collaboratively
 Timeframes:
 Look Ahead
Team thinks about the future to identify
potential problems. Addressing these in
advance may avoid unnecessary waste
 Just In Time (JIT)
Members naturally coordinate conversations
/ non solo work
 Look Back
Via status meetings, status reports and
trailing metrics
 Options:
 Coordination Meetings
SCRUM meetings
 JIT Modelling
PO gives requirements & team gather
around the whiteboard to share ideas.
Known as JIT analysis or JIT design
 JIT Planning
Perform as needed, typically for small
batches of work
 Look Ahead Modelling/Planning
As above
 Regular Conversations

 Status Meetings

32 | P a g e
 Team gathers to share status, typically
discussing what has been accomplished
recently
 Visualize Work
Using KANBAN board – type of
information radiator

 Facilitate a Working Session

 Addresses the common need to:
 Gather a large or diverse group of people
 Model or plan together in a face-to-face manner
 Without effective facilitation, the working sessions
risk devolving into an unorganized mess
 Options:
 Agile Modeling Session
Can be applied to explore a stakeholder’s
needs, architectural or design strategies
Key stakeholders and the team meet in a
modeling room to work through the issues
being explored collaboratively and visually
 Open Space
Facilitated meeting or multi-day conference
to focus on a specific task or purpose
Participant-driven with the agenda created at
the time by people attending the event
Also known as Open Space Technology
(OST) or “unconference”
 Big Room Planning
Typically, every quarter a team of teams
comes together to create a high-level plan
This allows planning coordination for teams
working on the same solution
May utilise agile modelling or other
strategies

 Joint Application Design (JAD) sessions

33 | P a g e
 Formal modelling sessions led by a skilled
facilitator with defining roles for how people
interact with one another
Can be applied to explore requirements as
well – Joint Application Requirements
(JAR)
 Coordinate Across Program
Common to organize large effort into a team
of teams
Only applicable to a team of teams
Divided into sub-teams (or squads)
Team size depends on the context of the
situation although we have Miller’s Law (7
+/- 2) and the 2 Pizza rule
Role Related Options:
 Architecture Owner team –
architecture owners from each sub-
teams work together to guide the
development of the architecture for
the overall program
 Product Coordination team – team
leads from each sub team work
together to drive team coordination
efforts (daily Scrum of Scrums/SoS)
 PO team – PO from each sub-team
work together to manage
requirements and workout
dependencies across sub-teams.
Large programs may have a Chief
PO to lead the PO Team
 Program Manager/Coordinator –
oversee and guide the entire
program. They will typically
coordinate the efforts of all the other
teams and mange relationships with
vendors as well as monitor overall
budget and schedule
 Management Team – the program
has a team of managers overseeing
and guiding the Agile/Lean sub-
teams

34 | P a g e
  Leadership Team – self-organized,
they plan and estimate the work they
do instead of being assigned work

Meeting Options
 Coordination meetings / Scrum
meetings
 Facilitated working sessions –
working sessions to explore
stakeholder needs, work through
architecture or designing strategies,
or plan the next increment of work
 Open species
 Scrum of Scrums (SoS) – someone
from the coordination meeting of a
sub-team attends the coordination
meeting across all teams within the
program
Other Options:
 Common cadences – squads have
iterations or Sprints that are the same
length (i.e. 2 weeks) where they can
choose to coordinate the next batch
 Divisor cadences – squads have
iterations or sprints that are divisors
of a larger coordination cadence

35 | P a g e
  Visualize work – using Kanban
board
 Coordinate Teams across the Enterprise
When we adopt existing organizational
guidance and leverage existing
organizational assets we operate more
effectively
Working on an enterprise-aware manner
requires collaboration with other teams and
coordination of efforts across the enterprise
Options:
 Enterprise professional as a team
member
 Enterprise roadmaps (detailed) –
the organization’s vision is captured
in detail as key diagrams
overviewing the vision/detailed
descriptions/detailed implementation
plans/guiding principles and the
thinking behind them
 Enterprise roadmaps (light) –
Technical or business vision capture
in a concise manner – key diagrams
overviewing the vision/high level
plans and priorities/principles meant
to guide the org
 Facilitated working sessions –
enterprise teams will run modelling
and planning sessions and
occasionally will involve their
stakeholders
 Coordinate Release Schedule
For orgs with multiple solution delivery
teams working in parallel
Continuous Deployment / release stream
Regular releases / release train
Release windows (slots)
Unique project releases

 Coordinate Between Locations

Geographically distributed teams (different
building/cities/offices)

36 | P a g e
 Accomplished by:
 Move to single location
 Gather physically at critical times
 Ambassadors – someone who
travels between locations
 Boundary spanners – responsible
for coordinating communications
between sites, working with other
boundary spanner
 Adopt collaboration tools – to
interact
 Coordinating to Achieve Results
 Coordinating activities to produce value  look at
the VS to determine which decision points provide
strategies that can be used to simplify and speed up
our processes
 Where to start? Ask about team’s workflow as it
relates to other teams in the same VS
 Which issues cause waste or delay?
 Delays in workflow/integration errors/poor
quality/multitasking/rework/handoffs/handbacks
 How to optimize flow:
 Coordinate work between teams
Can improve communication, align
cadences, provide visibility and enhance
collaboration
 Eliminate Dependencies
Can simplify the VS and remove delays that
occur when a team working on one
component has to wait for another team’s
component to be completed
 Organize People around Workflow
 Work on how people are organized instead of trying
to manage the pieces flowing through a poor
structure
 Lower the number of interactions and make
coordination easier

37 | P a g e
 Borrow a team member

 Utilize core teams

38 | P a g e
Module 7 – Conflict Management for High Performance Teams
 Healthy Conflict
o Minor disagreements that occur in the pursuit of a better solution
o Positive and welcome
o Recognizing Healthy Conflict
 5 Disfunctions of a Team (Patrick Lencioni)


 Unhealthy Conflict
o Persistent bickering & personal attacks are destructive and impede
progress
o Needs to be addressed
 5 Levels of Conflict Model
o Problem to Solve
 Nobody takes things personally
 People are optimistic & collaborative
 Language is clear, specific and adult
 People understand one another & honestly disagree
 Actions to de-escalate:
 Build & strengthen collaboration
 Look for win/win outcomes
o Disagreement
 Team still wants to solve the problem but the desire for self-
protection has crept in
 People become cautious but not hostile
 Language begins to reflect the desire for self-preservation
 Hostile humour

39 | P a g e
 Distancing comments
Withholding info
Actions to de-escalate:
 Focus on keeping the team together
 Remain close enough to work through differences rather
than withdrawing or turning aggressive
 Empower people to respond to the problem
 Establish ground rules and work on solving problems
collaboratively with thought negotiation, rather than
appealing to authority
o Contest
 Objective shifts to winning but hasn’t reached the level of wanting
to hurt the opponent
 Dynamic changes to win or lose
 2 Distinct Sides
 Communication can become threatening
 People resist attempts to make peace
 Limited social contact
 Language becomes distorted and over-generalized (“you always”,
“everyone”
 Exaggerated claims as they attempt to make a case
 Actions to de-escalate:
 Reduce fear and distorted thinking
 Accommodate, negotiate and get the facts
 Structure the process, maintaining a sense of order and
direction
 Carefully manage contact between parties
 Give each person an opportunity to express their feelings
and clarify their interests
o Crusade
 Fight or Flight response in some team members
 Objectives shift to hurting or getting rid of the other side
 Behaviours become inflexible
 Clear lines between the 2 groups
 Language turns ideological & shifts to talk of principles, truth and
rights
 Parties become detached, losing some sense of the pain they cause
 Party members may attempt to enlist outsiders into the “cause”
 Actions to de-escalate:
 Require safe structures and diplomacy (external mediator)
 Communication through 3rd party as you look for possible
areas of agreement
 Decisions may need to be made by formal authority

40 | P a g e
 o World War
 Situation is intractable & can no longer be managed
 Objective is to destroy the other
 Attempt to do serious damage to the other’s reputation, position or
well-being
 May continue after parties have been separated
 Actions to de-escalate:
 Do whatever is necessary to prevent people from hurting
one another
 Bring in an outside authority to make difficult decisions
 Some relationships may need to be terminated
 Protecting Yourself & Your Team
o Dual Concern Grid
 Part of Thomas-Kilmann conflict resolution model

 Assertiveness = extent of one’s efforts to satisfy their own

concerns
 Cooperativeness = extent of one’s efforts to satisfy the concern of
others
 Problem-solving steps
o 3 Step approach:
 Define the problem
 Get the parties to acknowledge the conflict and agree on the
situation that needs to be addressed
 Establish common ground or shared goals. Without this
step there will be no effective communication

41 | P a g e
  Separate the problem and people, defining the problem in
functional terms rather than in terms of ego or a personality
 Explore & evaluate alternatives
 Diverge phase, where we explore and discuss many
alternatives
 As a group, search and define possible solutions
 Then we need an analytical approach to evaluate the
alternatives – ideally come up with a win/win strategy
 Select the best alternative
 This is the Reconverge phase where we agree on the best
step forward

42 | P a g e
Module 8 – Pragmatic Planning for Agile Teams
 Module focuses on release planning
 No real and concrete way to determine the actual value of planning since most of
its benefits are qualitative
 Traditional Belief
o The more effort into planning the more value we get
 Undisciplined Agile Belief
o Value remains unchanged no matter the effort in planning
 DA Belief
o Avoid both extremes

 Agile Modeling (AM)

o Practice-based method for effective modeling and documentation of
software-based systems
o Answers the following questions:
 What is the reality of the situation?
 How much do we need to plan?
 What is the best way to plan?
 How can we figure out what to do?
o Organized by categories:

43 | P a g e
o Modeling Techniques
 Active stakeholder participation
 Having access to people who can provide information
about the system being built and decisions regarding it
 Greater level of involvement by project stakeholder is
required  domain and technical experts should be
actively involved with modelling
 Multiple models
 Agile modelers should know a wide variety of modelling
techniques to have the skills and knowledge to apply the
right artifacts to the situation at hand
 Just Barely Good Enough (JBGE)
 Concept underlying the practice of developing artifacts just
to the point where they fulfill the task at hand, and no more
 Assumes that the models we use:
 Are the most effective possible
 Are situational
 Do not imply low quality
 Change over time
 Are ready sooner than you think
 Inclusive tools and techniques
 One of the hurdles modelling presents is that some
stakeholders don’t understand / want to learn about the
diagrams they are seeing
 As a result, devs need to work with models that include
more context for their tasks
o Modeling Sessions
 Agile modeling sessions – slightly formal approach to modelling
or planning
 Facilitated – effective facilitator should have a background
in agile modelling, have facilitator skills and a stake in the
outcome
 Collaborative – Everyone involved in the modelling effort
 Inclusive – Adopt simple techniques (free form sketches)
and tools (whiteboard/paper) that allow everyone to
collaborate
 Evolutionary – The answer (if you find one) emerges over
time through discussions
 Sufficient Formality – The level of formality varies with the
context of the situation
 Look-ahead modelling
 Someone on the team gathers info, explores requirements
and thinks through the design before implementing the

44 | P a g e
 solution in parallel to the dev effort (often a few days or a
week before the info is needed)
 JIT Model storming
 Modelling when you identify an issue to resolve, grab a
few templates, explore the issue, and then go back to work
o Session Types
 Requirements Envisioning
 Figure out, on a high level, what the requirements are early
in the project to help come to a common understanding of
the scope
 Architecture Envisioning
 Figure out on a high level what the requirements are early
in the life cycle to communicate a common vision of your
technical strategy with the team and your critical
stakeholders
 Iteration Modelling
 At the start of the Construction phase, teams typically plan
(estimate and schedule) the work that they will do in that
iteration
 Provides the analysis and design of the requirements being
implemented
o Specification Strategies
 Single Source Information
 Choose the nest artifact to record info once so it can be
used in multiple places and referenced from any other
artifact as appropriate
 This reduces your maintenance and traceability burdens
and increases your consistency of information
 Document continuously
 If you want to have a potentially consumable solution every
iteration, the deliverable documentation must be in sync
with your solution throughout the project
 Executable specifications
 Make sure your quality tests are well written and provide
working specifications of your tasks so they will become an
important part of your requirement documentation
 Document late
 Defer the creation of all deliverable documentation as late
as possible – creating them just before you need to deliver
them
 Wait until the info has stabilized before you capture it in
the documentation
o Related Techniques

45 | P a g e
  Prioritized requirements
 This is the order in which your work drives your plan
 Implement the highest priority requirement first to
maximize stakeholder return on investment
 Use practices such as product backlog (SCRUM), work
item list (DA), option tool (Lean)  helps avoid having to
plan in detail too far in advance
 Test-Driven Development (TDD)
 Evolutionary approach to development that combines test-
first development and refactoring
 Leads to more focused work and less need for validation
o Value of Modelling:

 Effective Planning
o Should plan to the point of being JBGE

o Planning considerations

46 | P a g e
  What trade-offs do you need to make?
 What kind of teams are you working with?
 Where will they land on the curve?
 Why are you planning?
 What do you intend to do as a result of the planning?
o Zones of Planning – best approach = under plan
 Efficient
 Under plan because you can always update later if
necessary
 Comfortable (but wasteful)
 This is what many new to Agile aim for
 Insufficient (risky but addressable)
 Agile purists often under plan, have issues and discover
they need to invest in more planning
 Wasteful and Risky
 Traditionalists often over plan, which makes the team less
flexible to respond to change
o Planning Types

o What are you planning for?

 New Product  MVP Path (prototype) – investment for discovery
 Existing Product  MBI Path  Smallest releasable chunk of
value that makes sense from a business perspective – investment
for revenue
o Dependencies
 Internal
 Within the team’s control
 External

47 | P a g e
  Out of the team’s control
 Classes of dependencies:
 Mandatory
 Things you must have
 Discretionary
 Things you should have (if you don’t, there might
be a costly or time-consuming way forward)
 Types:
 Finish to Start (FS)
 Successor cannot start until predecessor is finished
 Finish to Finish (FF)
 Successor cannot finish until predecessor has
finished
 Start to Start (SS)
 Successor cannot start until predecessor has started
 Start to Finish (SF)
 Predecessor activity cannot finish until the
successor has started
 Causal Dependencies – one activity cannot start without the other
being finished
 People-based Dependencies – a particular person is needed to do
something
o Sources – Functional dependencies occur between requirements due to:
 Customer Driven
 Functional dependencies occur naturally in the domain
because of customer activities
 PO is responsible
 Requirements Decomposition
 Large requirement decomposed into smaller ones
 Dependencies carried over from large req. to small req.
 PO is responsible
 Technology Driven
 Some teams will choose to identify requirements for a
given platform, subsystem or architectural layer
 AO works with PO

48 | P a g e
o Options for maintaining a Functional Dependency
 Physical Dependency Map
 User stories or features are captured on paper and placed on
a whiteboard, cork board or table
 Dependencies can be indicated via physical placement
 Simple Electronic Tool
 Dependencies are managed using tools such as
spreadsheets, word processors or wikis
 Backlog/work item management tools
 Products like Trello, Jira, Rally, Version One
 Requirement management tools
 Products like Blueprint, Enterprise Architect or DOORS
NG
o Managing Dependencies between Agile and Lean
 Agile teams pull from the stack of work to reflect what can be
done in a single iteration
 Scrum teams prioritize by business value
 Lean teams prioritize work items on a JIT basis
 DA teams are more likely to consider a combination of business
value and risk
 Agile team that depends on Lean team – the dependency can be
avoided by letting the Lean team know about the dependency so
they can prioritize their work
 Lean team that depends on Agile team – dependencies can be
avoided using modelling and negotiation with agile team to help
prioritize, so that the team can schedule the work into appropriate
iteration

49 | P a g e
  Managing dependencies between Agile/Lean and Traditional
teams

Managing dependencies between Traditional and Agile/Lean

teams
 Traditional teams may not understand how a DA team
works
 Traditional teams may want traditional deliverable from the
agile team (DA teams produce high quality code with a
regression test suite and concise supporting documentation)
 Traditional teams may want detailed requirements and
design specifications, not realizing that the tests produced
by the Agile team can be considered as executable
specifications for the prod code
 Traditional teams may struggle with any changes to the
interface. Agile teams are used to work in an evolutionary
manner where the requirements, design and implementation
change over time. Traditional teams strive to define the
requirements and design up front, baseline them and then
avoid or prevent change to them from that point onwards.
These different mindsets can cause anxiety within the
traditionalist team  Agile team may need to be a bit
stricter than they usually would be when it comes to
embracing change
o Planning Tools & Concepts
 JIT Planning
 Performed on an as-needed basis for small batch of work

50 | P a g e
  Planning meeting is held at start of the work (all in
attendance)
 PO presents the set of features they would like to see
completed in the next iteration
 The team determines the tasks needed to complete the
features
 Work estimates are reviewed

Gantt Charts
 Diagram that depicts the scheduled activities, the
dependencies between them and sometimes the people
assigned to the activities
 Good for high-risk endeavours with low rate of change
 Risk to do too much planning up front, making the team
commit too early and restricting their flexibility
o DA Development Milestones (Inception, Construction, Transition)

o Planning the Release

51 | P a g e
 Goal Diagram:

52 | P a g e
53 | P a g e
o Improved Planning:

 We choose Estimating Strategy and Choose Estimation Unit

 Estimation Strategy

54 | P a g e
  Educated Guess by experienced individual(s)
 Person(s) with knowledge of the work takes a Wild
Guess (WAG) or a Scientific Wild Guess (SWAG)
to estimate the amount of work needed for a
particular task
 Educated Guess by a team
 WAG or SWAG by the team
 Similar size items
 Estimate for an item is based in part on the estimate
for an item of similar size
 Relative mass (grid) valuation
 Estimate is plotted as a value on a grid

 Planning Poker
 Using the Fibonacci sequence, the members of the
group give the work a point value
 Function Point
 Estimate is based on a measure that expresses the
amount of business functionality
 Cost set by stakeholders
 The stakeholders set the estimation strategy
 Choose Estimation Unit

 Relative Points
 Estimation is based on points system which is based
on how the work to be estimated relates to what we
already know

55 | P a g e
  T-Shirt Sizes
 Small/Medium/Large
 Normalized Points
 Points system which is based on how the work is to
be related to normalized conditions
 Hours
 Plan Your Work

 The activities in bold provide more accurate planning for

the work
 Coordination meetings/Scrum meetings
 Help to get a view of the work at the start of the
project and plan the work better

 Iteration/Sprint planning
 Planning of the work over a chunk of time
 JIT planning
 Planning performed on as-needed basis for a small
batch of work
 Look ahead planning/Backlog refinement
 Focuses on future work, looking at the backlog of
work to categorize it appropriately
 Release planning/program increment (PI) planning
 Planning that focuses on the release or program
increment
 Visualize Plan
 Visual representation of the plan on a physical
medium such as cork board

56 | P a g e
Module 9 – Pragmatic Reporting & Metrics for Agile Teams
 Always look for ways team can improve  need to find ways to gauge how your
team us performing in areas that matter
 DA Guidance on Metrics
o Adopt measures to improve outcomes
o Metrics should be used by a team to provide insights into how they work
and provide visibility to senior leadership to govern the team effectively
 DA Metrics
o Basic Principle:
 There is no easy answer of what to measure
 Need metrics that are specific to your team and context
 Work through a measurement strategy to get it right
 Every metric has strengths and weaknesses
 Learn the positive and negative of every metric
 Find out when to apply it or not
 Collect several metrics to provide sufficiently robust
insights
 Start with outcomes and goals

57 | P a g e
  The metrics we gather should provide insight into whether
we are achieving the outcomes we desire
 You get what you measure
 The way a team is measured would change its behaviour
 Make sure you know what behaviour you want to promote
 Automate whatever possible
 Reduces the cost, increases accuracy, makes it easy to
collect data as you go, enables real time monitoring
 Prefer trends over scalars/numbers
 Scalars have little meaning on their own
 A trend will provide insights into whether something is
improving
 Prefer leading over trailing metrics
 Leading = enables us to make decisions that could affect
future outcomes and provides insight into what is
happening/likely to happen
 Trailing = Indicates what has happened
 Prefer pull over push
 Metrics should be available when people want them
 Dashboard = pull mechanism
 Status report = push mechanism
o Overall:
 Measure the value of your metrics programme
 Be prepared to educate people on what metrics mean
 The value of metrics diminishes over time
 Evolve your metrics strategy as your situation evolves
 If you collect no metrics at all you are flying blind
 If you collect too many metrics you are flying blinded
o How teams approach metrics
 As a tool to help them improve performance in areas relevant to
their work
 May use metrics as a means of governance or to measure
effectiveness of new strategies
 Measure Outcomes at a Team level
 What really matters is how the whole team performs
 Identify the outcomes or goals you want to achieve
 Collect metrics that provide insight into whether you are
achieving those outcomes
 Trust but Verify
 Ask questions that verify:
 Are we getting the quality we expect from
outcomes?
 Are we getting good value for our investment?

58 | P a g e
  Are we delivering in a timely manner?
 Are we producing real business value for our
stakeholders?
 Each team needs a unique set of metrics
 Context counts – every team is unique  collect more than
one metric to have full picture
 Use metrics to motivate
 Don’t compare (people might manipulate metrics to their
advantage)
 Encourage self-competition (using metrics to motivate to
be their bes)
 Teams use metrics to self-organize
 Metrics provide insight to indicate potential issues or
opportunities the team may want to address
 Measure to improve
 The most important point for metrics – measuring the pain
to see the gain – when experimenting with a new technique,
metrics can be used to see if it works
 Don’t manage to the metrics
 Metrics are merely indicators of what is actually going on
 They are an invitation for a conversation
 Talk to your team to understand what the metrics mean

o How teams use metrics

 Self-organization
 People who do the work plan and estimate the work the
teams are doing (part of lean governance)
 Making decisions where the work is
 Following the broader guidelines and policies of the
enterprise
 Being transparent and accountable
 Metrics help monitor and improve team performance and
establish future performance goals
 Universal Metrics
 Cycle time – the time from starting a task to when it’s
ready for delivery
 Employee focus factor – 1/number of endeavours
 Cost of interruptions – time cost for being interrupted
while working on a task
 Internal rate of return – expected profitability of a project
or investment

59 | P a g e
  Type of work being done – the class of the work or
service being performed
 Net Present Value (NPV) – the value in terms of today’s
money
 Net Promoter Score (NPS) – those who would
recommend and those who wouldn’t
 Payback period – length of time it takes to recoup on your
investment
o Effective Ways to Measure
 Measuring quality depends on what is being produced and what
customers value. Issues to consider regarding quality:
 Does the solution still meet the needs of the stakeholders?
 Does the solution conform to applicable regulations?
 Have you built the solution according to generally accepted
principles?
 How easy will the solution be to adapt to changing
stakeholders needs?
 Focus on producing value
 Work that doesn’t produce value is often in response to a
previous error so only give credit to work that produces
value
 Value is what the customer considers important / what the
business invests in / what is most useful to the customer
upon release

 Metrics must shift with our thinking

 The time it takes to realize value is far more important than
productivity (of little use if it does not lead to value)
 Time metrics (how quickly we realize value)
 Lead time – measures the time elapsed between order and
delivery
 Cycle time – starts when actual work begins on the unit
and ends when ready for delivery
 Process Cycle efficiency – calculated by dividing the
value-added time associated with a process by the total lead
time of the process
 Not everything should be measured
 Being guided by the wrong metrics or inaccurate metrics
causes problems so measure what matters
 Consider the time and effort involved gathering the metrics
 The problem with the status report:

60 | P a g e
  Tends to be a poor use of resources – highly skilled
professionals must invest time in creating a status report –
they can be a costly way of reporting data
 Challenges that can lead to inaccurate reporting on status
reports:
 Green shifting – gradual improvement of a reported
message as it proceeds up the organization. Changes and it
is less accurate at each level of reporting
 Watermelon status report – Work appears to be green,
but is red or in danger upon closer inspection
 Quantum shifting from green to red – status jumps from
green to red suddenly
 Automation saves time
 A better alternative for reporting status is a dashboard 
not intrusive to the team / difficult to fake results /
increases trust via transparency for all stakeholders / helps
the team focus on delivering their commitments
o How orgs approach metrics
 Use metrics at a higher level to:
 Monitor teams as part of governance
 Ensure that all parts of the business are working towards set
goals

o Rolling up metrics
 Process of aggregating data from multiple sources, in summary
form, to provide a broad view at high level
 Rolling up metrics levels
 Team – intent is to:
 Measure against team rules
 Use specific metrics for each team
 Ensure the metrics evolve regularly as the situation
evolves
 Use a unique dashboard for each team
 Program – intent is to:
 Measure against program goals
 Use category indicators for each sub team
 Ensure the program goals evolve quarterly (or
thereabouts)
 Portfolio – intent is to:

61 | P a g e
  Measure against organizational goals
 Use an overall indicator or category indicator
 Ensure organizational goals evolve slowly
(annually)
 Check screenshots (In Antonio Quero Pastor’s document)
o Use the DA toolkit to solve measurements & reporting problems
 Metric Strategies:
 Goal Question Metric (GQM)
 The team identifies goals/outcomes they want to
achieve, questions to determine if they are
achieving them, and metrics they can gather to
provide insights to the questions
 When to use:
 Enables teams to identify metrics that fit
their context
 Good for teams new to measurement
 Objectives & Key Results (OKR)
 Desired objectives outcomes drive the identification
of measurable key results
 When to use it:
 Enables teams to identify metrics that fit
their context
 Good for experienced teams
 Consistent Metrics
 Teams are asked to report on specific measures to
stakeholders
 All teams use the same metrics
 When to use:
 Enables leadership to measure teams
consistently
 May not be meaningful to some teams and
may miss important insights
 Popular Metrics
 Teams adopt metrics commonly applied elsewhere
 When to use:
 Quick way to get some measures in place
but not meaningful in every situation
 Will miss important insights
 No Metrics
 Self-explanatory
 When to use:
 May work in small orgs where leadership
can more easily monitor by other means

62 | P a g e
  Team is essentially flying blind
 Teams evolve their WoW by trying new strategies from the toolkit,
adopting those that work and sharing their results with other teams
o Measure your WoW
 The “Evolve your WoW” Process Goal Diagram includes a
decision point for “Identify Potential Improvements”. One strategy
to meet this goal is “Measure your WoW”

 Potential metrics to measure your existing WoW:

 Lead time
 Cycle time
 Throughput
 Work in Progress (WIP)
 Incidents
 Colleague engagements & NPS
 Another decision point is “Implement potential improvements”,
one of several options you can use alone or in combination to
determine whether a strategy is producing the outcomes you would
like

o DA & Continuous Improvement

 Agile teams strive to continuously improve their WoW
 This diagram of the Kaizen Loop which parallels the
PLAN/DO/STUDY/ACT technique includes steps similar to
Evolve your WoW decision points – Identify a potential
improvement and assess effectiveness:

63 | P a g e
o Choose metric strategies for Team Improvement & Governance
 The “Govern delivery team” process goal provides strategies for
measurement and reporting as they relate to governance

64 | P a g e
o How to choose and design the metrics you need
 There are a number of logical and fairly simple models you can
follow to make intelligent choices as to which metrics you want to
use for your team/program/org
 But always think about WHY you need and are collecting this data
and what you want to do with it  Use purposeful metrics
o GQM – Goal Question Metrics process:
 Start with your goals whatever the level – you know what you
want, your metrics will have purpose and can be used to make
decisions to bring you closer to your goal
 Think of some questions – That will help you define your goal
(elicit quantifiable answers)  Ask questions that you can answer
by measuring certain quantities or qualities
 Identify the measures to collect – to answer those questions, and
track progress and product conformance to goals
 Developed data collection mechanisms – what mechanisms can
be used? Is there a way to automate data collection?
 Collect, validate and analyze the data in real time – to provide
immediate feedback to projects for corrective actions
 Analyze the data to assess conformance to the goals and to
make recommendations for future improvements – we gain
insights for analyzing collective data because we choose metrics
that are aligned to the goals  now we can make informed choices
 Iterate
o 2 types of metrics:
 Qualitative – descriptive + conceptual
 Quantitative – can be counted, measured or expressed in numbers

65 | P a g e
 Exam Questions
1- Formal modelling sessions, led by a skilled facilitator- joint application design
(JAD) sessions
2- Technical dependency- AOs help POs to better understand the implications of
the technologies being used.
3- Options to manage and maintain functional dependencies in a project-
Physical dependency map- Simple electronic tool- Work item management tool
Requirement Management tools are the other way to maintain the dependency.
4- Value in DA: What the customers considers important, what the business invests
in, what it is more useful to the customer upon release
5- System wide metrics examples: Standard entry time for all employees, follow a
set pattern to induct a new employee
6- which metric is suitable to measure 'Time to Market- The Schedule variance is
good metric for Time to market. Cycle time may not be a great metric in package
installation.
7- The Portfolio Manager is one of the key persons to: Identifies, prioritises,
organises and governs initiatives for the organisation to maximise value
8- The DA principle 'Organizing around products/services' enables us to
identify and optimize- Value stream
9- 2 ways to optimize the flow: Coordinate work between teams and reduce
dependencies
10- ORGANISE PEOPLE AROUND WORKFLOW - we lower the number of
interactions and make coordination easier and limit work movement
11- In a team's 'Forming' stage, what is one of the first things the team should do
as part of establishing its initial Way ot Working (WoW)? Since the team is in
the forming stage, first you need to select the Lifecycle before you measure the
existing WoW or conduct a retrospective.
12- A new team has instituted test-driven development. One of the team
members is very eager to show the benefits of test-driven development. What
its the preferred way to capture these benefits? – Expected outcomes
13- The team lead has recently been assigned to a Disciplined Agile project. The
Line managers provided the Team Lead with Developers and Business
Subject Matter Experts. What should the Team Lead do in the first team
meeting? Ask team members to introduce themselves , providing info on hobbies
and personal achievements. This is the start to the project and the idea is to break
the ice. Start casually and find a common ground, and proceed to esablish some
ground rules.
14- What strategy can help the team move out of 'storming to the 'norming'
state? Internal and external working agreements- it will help to establish good
working conditions and take it to Norming stage.
15- What are results of fostering healthy conflict? Decreases the chances of people
holding back ideas or information

66 | P a g e
16- While every context is different, what type of planning is preferred to enable
business agility?-  Progressive Elaboration.
17- A Definition of Done (DoD) defines the minimum criteria that a work item
must meet before our stakeholders will accept it as completed- TRUE
18- Which 2 process goals will have User Experience (UX) as an option or
decision point- Align with Enterprise direction and Develop test strategy
19- Look back options : Status Reporting and Trailing Metrics - mostly used in
traditional types of organization
20- How can a team increase the diversity of opinions expressed by team
members?- By creating physiological safety in the team
21- What is the role of the leadership in team formation? To create an
environment that fosters joy, through a focus on content, process and feelings.
22- An organization is moving to goal question metric (GQM). What primary
benefit should they expect from this move?- Team specific metrics and insights
23- Which concern is resolved in the storming phase of team formation?
Establishment of rules
24- Technical stories: works well for point specific requirements
25- Value Stream helps: Minimise waste, Bring visibility to org goals, Produce
alignment of goals
26- Qualitative measure of the resistance faced by the work in a value stream.-
VSI (Value stream impedance)
27- A daily Scrum of Scrums (SoS) is a common approach to co-ordinate among
various product teams- TRUE
28- a facilitated meeting or multiday conference where participants focus on this
specific agenda- Open space- are participant driven, with the agenda being
created at the time by the people attending the event. Also known as open space
technology (OST) or unconference.
29- A team from the DA associates India location wants to use the expertise on
project management skill from the USA location team for a certain cadence
of 2 months. How best can this be achieved? - The USA team member stay in
the US and attends the coordination meetings of both team. This moves
dependencies from between teams to within a team. This lowers the number of
handoffs, handbacks and delays.
30- Agile modeling aims to- Capture the intent of design in a barely sufficient way
31- The project team is figuring out the requirements early in the project to help
come to a common understanding, as to the scope of what is to be
accomplished. What are they doing?- requirements envisioning (This is Session
Types for Agile Modelling)
32- check if the productivity is increasing for the team. Which metric they should
use to understand the same?- velocity: It will give a good picture of the trend
and hence, the productivity increase or decrease.
33- There are 2 ways of finding the defects in the code- Detection and prevention

67 | P a g e
34- The leadership team wants every team to identify the outcomes that fit their
context. The leadership team wants that the teams should identify the key
metrics so that they can drive performance.<br />Based on the govern
delivery team process goal, which type of measurement strategy will meet the
leadership teams needs?- The Objective Key results- OKR talks about desired
results that the team wants to achieve and as per their context.
35- Life cycle that focuses on continuous flow of development: Continuous delivery
Lean
36- Process blades are cohesive collections of process options that a team can choose and
apply in a context sensitive manner- True
37- Which phase ends with producing a MMR( minimum marketable Release)-
Construction
38- Continuous improvement establishes an ongoing effort of improving that could
include products or solutions, processes, services, or management.
39- How DA supports teams that choose their own WoW- DA supports choice, DA supports
multimer life cycles options, DA establishes a set of principles
40- Agile and lean teams are self governing- TRUE!!
41- Business agility: the ability of a business to rapidly adapt to market and environmental
changes in productive and cost effective ways
42- What does governance do for teams?- Provides ways to share information, mitigate
risks, sustain strategies and establishes objectives
43- Pragmatism- focuses on effectiveness rather than process
44- Which role describes the business case, problem, or scenario that requires a technical
or service solution?- Architect Owner
45- When choosing a WoW- Choice is Good refers to: 1) The freedom to experiment with
strategies before deciding 2) the best choice for a given team’s context
46- Life cycle for Project based work with Disciplined teams with quickly evolving
requirements. Lean
47- Evolving your WoW is when teams experiment with and review their processes to find
ways to improve- TRUE
48- Online chat, video conferencing, face to face and emails are options under which
decision point? Choose communication styles
49- 4 elements of awesome teams- Unity, relationships, cross functional, Emotional
Intelligence
50- Inception phase ends when- it has been determined that the project is worth pursuing
and what resources will be needed. In this phase we understand the project scope and
objectives and get enough info to confirm the project should proceed.

68 | P a g e