Don Wilson presents Agile Requirements Management at the PM Reston luncheon March 18, 2015

1. For discussion Purposes only Confidential
Page 1
Revolutionary
Performance Management

2. For discussion Purposes only Confidential
Page 2
About the speaker:
Don Wilson gained his Bachelors in Computer Science
from North Carolina A&T State University and jumped
immediately into solving business problems with
technology. He spent the first part of his career in with
Ernst & Young and Deloitte planning and implementing
multimillion dollar software packages for fortune 500
companies. He translated the strategic, process and
technical knowledge into a success as an architect and
then project manager for software development and
implementation projects. While making progress possible
with software is a passion for Don his spare time is spent
on the sidelines of his sons soccer games and the isle of
his daughters ballet and violin recitals or a blogging
event for his wife. If those aren't going on he's golfing
fishing or watching football(any kind).

3. For discussion Purposes only Confidential
Page 3
Definition: Agile
ag·ile [aj-uhl, -ahyl] Adjective
1. quick and well-coordinated in movement; lithe: an agile leap.
2. active; lively: an agile person.
3. marked by an ability to think quickly; mentally acute or aware: She's 95 and still very agile.
Origin:
1570–80; earlier agil < Latin agilis, equivalent to ag-
(base of agere to do) + -ilis -ile
Related forms
ag·ile·ly, adverb
ag·ile·ness, noun
un·ag·ile, adjective
un·ag·ile·ly, adverb
Synonyms
1. nimble, sprightly. 2. brisk, spry.
Antonyms
1. awkward. 2. sluggish, lethargic.
Dictionary.com Unabridged Based on the Random House Dictionary, © Random House, Inc. 2014.

4. For discussion Purposes only Confidential
Page 4
Definition: Requirements
re·quire·ment
riˈkwīrmənt/
Noun
Synonyms:
need, wish, demand, want, necessity, essential, prereq
uisite, stipulation
“good spelling is a requirement of the job"
noun
1.a thing that is needed or wanted.
"choose the type of window that suits your requirements best"
•a thing that is compulsory; a necessary condition.
"applicants must satisfy the normal entry requirements"

5. For discussion Purposes only Confidential
Page 5
Agility in life
Agile Animals
Agility in Sports
Agility In Traffic
Agility in Business

6. For discussion Purposes only Confidential
Page 6
BACKGROUND

7. For discussion Purposes only Confidential
Page 7
Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

8. For discussion Purposes only Confidential
Page 8
Agile Manifesto Principles
We follow these principles:
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout
the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation.

9. For discussion Purposes only Confidential
Page 9
Agile Manifesto Principles
We follow these principles:
7. Working software IS the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10.Simplicity--the art of maximizing the amount of work not done--is
essential.
11.The best architectures, requirements, and designs emerge from self-
organizing teams.
12.At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

10. For discussion Purposes only Confidential
Page 10
ADOPTION

11. For discussion Purposes only Confidential
Page 11
Adoption Rates

12. For discussion Purposes only Confidential
Page 12
Agile Success
According to the 2012 CHAOS report, Agile succeeds
three times more often than waterfall.

13. For discussion Purposes only Confidential
Page 13
Why Scrum
Source: 7th State of Agile Development Survey by VersionOne

14. For discussion Purposes only Confidential
Page 14
AGILE IN REQUIREMENTS

15. For discussion Purposes only Confidential
Page 15
What are the benefits of Agile
More software that is relevant
Higher Customer satisfaction
Higher Trust Level
Shorter Wait times
Shorter Development cycles )
More frequent delivery
More inspection opportunities
Ability to change direction

16. For discussion Purposes only Confidential
Page 16
What are the Risks to Success
1. Wrong Time or Place
1. Good ideas coming only after code
complete
2. Good feedback from management or
others not directly related to the project
2. Wrong Ideas
1. Not understanding what needs to be built
2. Assuming what needs to be built
3. Wrong Context
1. Not understanding the context of
requirements
2. Incomplete requirements (whole context not
known/understood by development team)
3. Shame Changes: shaming into scope
changes. is it really a viable piece of
software if it cant do this. This is useless unless
it can do XYZ
4. Wrong Level of understanding
1. Not OWNING the requirement.
Understanding how to validate the
requirement has been achieved. The team
should be able to to not only articulate what
the requirement is but also know when it has
been successfully delivered.
2. Unspoken requirements
5. Wrong People
1. Not getting requirements from the right
people (getting requirements from owners
vs users)
2. Roles in and outside of system not clearly
defined
6. Wrong Perspective
1. Epic Splitting (part of the problem being
solved but part not addressed now.
Integration of stories within an epic can
cause additional issues)
2. Legitimate Changes in requirements
7. Wrong Priorities
1. Conflicting Priorities among Business
communities. Conflicts between users an
management and between different
groups
2. Gold Plating/Requirement stuffing (What i
really meant was... or it wont really be
complete if it does not do X)
8. Wrong Techniques/Tools/Tactics
1. Poor design, architecture, technique or
coding practices leads to poor results
2. Code not getting adopted or poor reuse

17. For discussion Purposes only Confidential
Page 17
Keys to addressing Risks
1. Understand your
process and its
stakeholders
2. Educate
3. Proactively Listen
4. Understand the big
picture
5. Work Progressive
elaboration into your
process
6. Work on what matters
7. Inspect and Adapt

18. For discussion Purposes only Confidential
Page 18
KNOW YOUR PROCESS

19. For discussion Purposes only Confidential
Page 19
Know your process & role first
Explain your process to the customer
Help them understand the process their idea will go
through to help deliver value
Know how your audience changes throughout the
process

20. For discussion Purposes only Confidential
Page 20
Scrum Team Roles
Aspect Scrum Master Product Owner Team
Key Activities Educate
Facilitate Key Ceremonies
Remove Impediments
Protect Team
Helping the team b
Create backlog
Assign Value and Prioritize
Stories
Break Epics into stories
Clarify Requirement inquiries
Facilitate Adoption
Estimates
Prototypes
Spikes
Develops
Tests
Major
Contribution
Education &
Impediment Removal
Process improvements
Vision & Roadmap &
Secure funding/Adoption
Creating Working Code
Measured by Transparency, Efficiency and
Effectiveness of the scrum
process
Roadmap
Ability to represent
stakeholder intrests
Velocity
Value
Quality
Code
Core Skills • Excellent leadership and
facilitation skills
• Able to explain key agile
concepts to a variety of
audiences
• Excellent communication skills
• Expert in the process able to
communicate the value of the
process nuances and coach
participants in the proper way
to execute
• Focused on continuous
improvements for the team,
management and the product
owner and customers alike
• Forward thinking visionary
• Able to decompose
concepts into phases or
components
• Technical enough to
understand implications of
technology decisions
• Business savvy enough to
understand implications of
business matters.
• Able to translate business
issues into technical terms
and technical issues into
business terms.
• Able to define/refine an
architecture to address current
and future needs
• Able to identify and establish
key programing practices that
lead to code reuse, easy
integration, scalability and
maintainability
• Ability to increase the technical
acumen of the development
team.
• Ability to view and assess
potential enhancements with
accurate effort estimations
and potential impact analysis
on the current infrastructure.
• Ability to identify talented

21. For discussion Purposes only Confidential
Page 21
Initiate Core Scrum Concepts
Value
Team Size
Scrum Meeting Cadence
Self Organizing Team
Colocation
Sushi not Sashimi
Chickens & Pigs
Spikes
Prototypes
Burn down
Empirical
Information Radiator
Scrum Board
Backlog
Stories
Epics
Story Points
Conditions of Satisfaction
Done Done
Shippable unit

22. For discussion Purposes only Confidential
Page 22
Establish the elements
Artifacts
Working Code
Prototypes
Backlog
Retrospective Notes
Scrum Board (or app)
Burn down Charts
(sprint, Epic, Product)
Roadmap
Release Schedule
Budgets and Forecasts
Portfolio and Project
status reports
Meetings
Requirements Review
sessions
Road Mapping sessions
Bi-weekly
Client Prioritization
sessions (weekly)
Estimation
Grooming
Sprint Planning
Daily Standup
Sprint Demo
Sprint Retrospective

23. For discussion Purposes only Confidential
Page 23

24. For discussion Purposes only Confidential
Page 24
Life of a requirement
Ideas
Elaborate
QuantifyDeliver
Inspect &
Adapt

25. For discussion Purposes only Confidential
Page 25
Planning at Multiple Levels
Source: Agile Estimating and Planning

26. For discussion Purposes only Confidential
Page 26
EDUCATE YOUR STAKEHOLDERS

27. For discussion Purposes only Confidential
Page 27
Communicate Profusely
Management
Trust comes with results (doing
what you said you'd do when
you said you'd do it)
Over communicate
Steering committees/PMO
Governance
Financial reporting
Status Reporting
Budgeting
Arcuate Estimations critical
Use backlog grooming and SP
estimating in projecting future
budget requirements
Calculate EVM if necessary
Everyone else
Educate, Explain value, laud
victories, readily admit mistakes
and plans to address them
Time dependent interactions
with cadence where possible

28. For discussion Purposes only Confidential
Page 28
Agile Customer Alignment
Educate
Understand what’s valuable to the
customer.
Create an environment for success
Educate them on the process, what’s
different, what to expect and what’s
needed from them
What's different,
Time Boxed Delivery
More Frequent releases, Less
documentation
More responsiveness
and involvement from them (decisions in 5
minutes)
Keep them informed with a consistent
stream of information,
Each timebox has a frequency
(cadence/rhythm)
Help them to understand the cadence
Frequent inspection
Communicate
help them to know you truly intend to
represent their priorities as an advocate
Planning
Long term planning
Mid Term planning
Short term planning
Delivery
Frequent inspection
Adapting to the gaps
Scope is still important
Changes are encouraged if they improve
value but the triangle still needs to be
maintained
Changes still have an impact:
financial impact
Other users
Working with multiple clients & balancing
priorities
Transparency,
Fairness,
Consistency

29. For discussion Purposes only Confidential
Page 29

30. For discussion Purposes only Confidential
Page 30
Addressing the Risks
Risk
1. Wrong Time or Place
1. Good ideas coming only after
code complete
2. Good feedback from
management or others not
directly related to the project
Fix
Communicate early
and often about the
opportunities to provide
input.
Communicate to:
Team
Customers
Stakeholders/managem
ent
Others

31. For discussion Purposes only Confidential
Page 31
PROACTIVELY LISTEN

32. For discussion Purposes only Confidential
Page 32
Understanding has No Shortcuts
• Requirements are about
communicating what is
desired even if its not
explicit.
• The life of a requirement
needs to be understood
from thought to adoption
including its appearance in
many forms to many parties.
• Traceability should extend
beyond deployment to
understand the usage rates
patterns and errors. Its also
good to know who asked
for it and their history

33. For discussion Purposes only Confidential
Page 33
How do we Understand

34. For discussion Purposes only Confidential
Page 34
Proactive Listening
Hearing out the
requirements in the
right context with the
right people involved
is the first step in
refining requirements
for success
Subjects, Verbs, Objects
Confirm Understanding
Avoid Extremes
Writing everything
Not writing anything
The point is
understanding not just
understanding for
temporary recall but
understanding so that
you can represent the
matter to someone else.

35. For discussion Purposes only Confidential
Page 35
Progressive Elaboration
Understanding Takes time.
Agile is more interested in
communication over
documentation.
Elaboration Occurs in
Stages
Understand Macro Requirement
Understand Context
Outline Solution & Get feedback
Provide more detailed solution &
Get feedback
Provide mockup & Get feedback
Prototype and get feedback
Develop and get feedback
Deploy and get feedback

36. For discussion Purposes only Confidential
Page 36
Progressive Elaboration

37. For discussion Purposes only Confidential
Page 37
Addressing the Risks
Risk
2. Wrong Ideas
1. Not understanding
what needs to be built
2. Assuming what needs
to be built
Fix
Understanding the big
picture
Proactive Listening
Progressive elaboration

38. For discussion Purposes only Confidential
Page 38
UNDERSTAND THE BIG PICTURE

39. For discussion Purposes only Confidential
Page 39
Roadmap
Volunteer Portal RoadmapDec Jan Feb Mar April May Jun July Aug Sept Oct Nov Dec
R6
11/10
R7
12/15
R8
2/2
R10
6/21
R12
12/06
RX
Dev
UAT/BF
UI
R
Requirements
User Interface Design
Development
User Acceptance Testing and Bug Fixes
Production Release
Sprint 20 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11 Sprint 12 Sprint 1
Supervisor flow
Group 2 Epic 1
Group 3 Epic 2
Volunteer flow
Group 2 Epic 2
Group 2 Epic 3
Add Host
Edit Host: Marketing Contact
Edit Host: Contact Selection
Report Updates
Course Loading Tool Edit Host Capabilities
Modify Email Address
Submitter Flow
Edit Course
Reports Utilities and Transition
Host Flow
Receipt Management
ERP/Legacy Integration
Exports and Messaging
Volunteer Flow
Staff Flow
Locator Updates
R11
9/20
R9
4/18
R8.1
4/3
Group 1 Epic 1
UAT – DSP Host
Group 3 Epic 1
G1 – Epic 2
Mutually Beneficial Epic 1
Approver Flow
R11
UAT
Group 3 Epic 4
R12
UAT
R10
UAT

40. For discussion Purposes only Confidential
Page 40
Story Board: Big Picture

41. For discussion Purposes only Confidential
Page 41
Addressing the Risks
Risk
3. Wrong Context
1. Not understanding the
context of requirements
2. Incomplete requirements
(whole context not
known/understood by
development team)
3. Shame Changes:
shaming into scope
changes. is it really a
viable piece of software
if it cant do this. This is
useless unless it can do
XYZ
Fix
Progressive elaboration
Process Context
System Context
Mockups
Prototypes
Conditions of
Satisfaction

42. For discussion Purposes only Confidential
Page 42
Story Board: Process Context

43. For discussion Purposes only Confidential
Page 43
Addressing the Risks
Risk
4. Wrong Level of
understanding
1. Not OWNING the
requirement. Understanding
how to validate the
requirement has been
achieved. The team should
be able to to not only
articulate what the
requirement is but also
know when it has been
successfully delivered.
2. Unspoken requirements
(Context: technical &
business )
Fix
Proactive listening
Understanding Why
Progressive elaboration
Process Context
System Context
Mockups
Prototypes
Conditions of
Satisfaction

44. For discussion Purposes only Confidential
Page 44
Edit Mileage
Reimbursement Entry
Description: This page provides allows a volunteer or designated proxy to Add or Edit
a single Mileage reimbursement expense entry
# Action Logic Data
1 Date Slection NO limitation on dates to
be selected (NEED
CONFIRMATION
Required
2 Select Expense activity List Populated from table Required
3 Enter Explaination Required
LIMIT 255
Characters
4 Enter Miles Required
(3 digits after
decimal point)
5 Update Saves and returns to the
expense details screeen
6 Cancel Returns to the expense
details screen
7
8
9
Accessing User Access Conditions Display logic
Volunteers Visible Access only to personal list
Staff/Proxy entry Visible Access to all volunteers via
lookup
Approvers Not visible
Finance Liason Not visible
# Action/
Triggers
To Subject Message Body
Exceed
Character
limit for
Explainatio
n
Add
Success
Successfully Added a mileage
Expense
Add Error Error in adding milage expense
# Business Rule
Mileage rate per program needs to be defined and configured in the admin tool (or
at least in a configuration file)
Requirement from TA to allow a lower mileage entry rate per submission (Not per
entry) (ADD TO SCOPE ISSUES) (Not an issue for States –DSP will confirm)
Need Expense Activity Lists from DSP/States and Expense Types
Are there any limitations on Miles or expenses per day or per type per day
Add Delete buton
Story Board Page Example

45. For discussion Purposes only Confidential
Page 45
Conditions of Satisfaction
The system is
considered
complete if it meets
these conditions.
Conditions can be
Functional Conditions
Technical Conditions
Pre-Conditions
The COS serve as a
baseline for both
feature validation
and traceability

46. For discussion Purposes only Confidential
Page 46
Addressing the Risks
Risk
5. Wrong People
1. Not getting requirements
from the right people
(getting requirements
from owners vs users)
(Understand Who uses
the system)
2. Roles in and outside of
system not clearly
defined
Fix
Educating the users
Proactive listening
Progressive elaboration
Process Context
System Context
Mockups
Prototypes
Conditions of
Satisfaction

47. For discussion Purposes only Confidential
Page 47

48. For discussion Purposes only Confidential
Page 48
Decomposing Epics

49. For discussion Purposes only Confidential
Page 49
Addressing the Risks
Risk
6. Wrong Perspective
1. Epic Splitting (part of the
problem being solved
but part not addressed
now. Integration of
stories within an epic can
cause additional issues)
(Planning for integration
with Epic Breakdown)
2. Legitimate Changes in
requirements (scope
swap)
Fix
Epic Breakdown
Scope Swapping
Backlog Overview
Backlog Assessments
Conditions of
Satisfaction

50. For discussion Purposes only Confidential
Page 50
THINK LEAN ELIMINATE WASTE

51. For discussion Purposes only Confidential
Page 51
Think Value
Source: Jim Johnson. The Standish Group International Inc. 2002.

52. For discussion Purposes only Confidential
Page 52
Seven Wastes
Toyota Production System [1]
Inventory
Overproduction
Extra Processing
Transportation
Waiting
Motion
Defects
Software Development [2]
Partially Done Work
Extra Features
Relearning
Handoffs
Delays
Task Switching
Defects
1. Shingo, Shigeo. A Study of the Toyota Production System. Productivity Press, 1981.
2. Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Addison-Wesley, 2006.

53. For discussion Purposes only Confidential
Page 53
Assessing Value
Understand why its being requested, who benefits from
the request and how. Also identify the ideal scenario.
Set a formula Weighting what’s important to your
organization
Auto calculate base on entries in each area
Be consistent in ratings (keep them relative)
Examlpes:
Attract Customer or enhances customer experience
Legal
Corporate Dashboard/Score card Goal Impact
Impacts Business Continuity
Time Savings
Increase Capacity
Impact Community
Impact Multiple Groups
Cost Savings
Increase Revenue

54. For discussion Purposes only Confidential
Page 54
Assessing Value

55. For discussion Purposes only Confidential
Page 55
Right Sizing Stories
Relative size
Relative complexity
Independence
Factor assumptions & Constraints
Challenges to be faced
Unknowns
Assumed Effort

56. For discussion Purposes only Confidential
Page 56
Story Point Estimating

57. For discussion Purposes only Confidential
Page 57
Addressing the Risks
Risk
7. Wrong Priorities
1. Conflicting Priorities
among Business
communities. Conflicts
between users an
management and
between different groups
2. Gold Plating/Requirement
stuffing (What i really
meant was... or it wont
really be complete if it
does not do X)
(Prioritization & Value
assessment)
Fix
Value Evaluation
Story Point Estimation
Educating the users
Proactive Prioritization
Roadmap

58. For discussion Purposes only Confidential
Page 58
The Backlog

59. For discussion Purposes only Confidential
Page 59
Traceability
Coverage
Requesting party, Adoption and Usage
Relationship to others
Parent items
Children

60. For discussion Purposes only Confidential
Page 60
Value Evaluation
Scope swaps
Remaining work
Delivered items

61. For discussion Purposes only Confidential
Page 61
Backlog Assessment

62. For discussion Purposes only Confidential
Page 62
Backlog Overview

63. For discussion Purposes only Confidential
Page 63
Inspect and Adapt Opportunities
Customer opportunities for inspection & adjustment
Requirements: Idea Discussed and
translated to story
Grooming/Planning: Effort Estimation & Value
assignment & Priority Assignment
Design
Client Prioritization sessions (weekly)
Road Mapping sessions Bi-weekly
Sprint Review Demonstration
UAT
Production
Team Opportunities for inspection & adjustment
Grooming
Sprint Planning
Daily Standup
Sprint Review
Retrospective
Management Opportunities for inspection &
adjustment
Project Initiation
Project Estimating
Project Budget authorization
Status reports (Sprint specific, Project Specific)
(indicate overall progress in terms of scope,
resources and time)
Steering committee/PMO Meetings (Sprint specific,
Project Specific)
Lessons Learned
Others:
Grooming
Invited to planning
Scrum of Scrum Sessions

64. For discussion Purposes only Confidential
Page 64
Addressing the Risks
Risk
8. Wrong
Techniques/Tools/Tactics
1. Poor design, architecture,
technique or coding
practices leads to poor
results
2. Code not getting
adopted or poor reuse
(Inspect & Adapt)
Fix
Backlog Assessment
Proactive Prioritization
Roadmap
Inspect and Adapt
Team
Tactics
Technologies
Process

65. For discussion Purposes only Confidential
Page 65
RECAP

66. For discussion Purposes only Confidential
Page 66
Performance Measures
Project Success
Budget
Scope
Time
Client Satisfaction
Development Team Success
Vision
Deliverables
Scope delivered
Speed of Delivery
Quality of Delivery
Residual Value of delivery
Reuse
Planned and unplanned value
Reduced maintenance
Teamwork:
Listening
Trust
Innovation
Agile Team Success
High Value Delivery
Reduced Code Waste
High Visibility
Development
Implementation
Self Managed Teams
Accountable
Transparent
Innovative

67. For discussion Purposes only Confidential
Page 67
What are the Solutions
1. Wrong Time or Place (Process)
1. Good ideas coming only after code
complete
2. Good feedback from management or
others not directly related to the project
2. Wrong Ideas
1. Not understanding what needs to be built
(Big picture)
2. Assuming what needs to be built (Confirm
with Pro Elab)
3. Wrong Context
1. Not understanding the context of
requirements
2. Incomplete requirements (whole context not
known/understood by development team)
3. Shame Changes: shaming into scope
changes. is it really a viable piece of
software if it cant do this. This is useless unless
it can do XYZ (COS & Mockups)
4. Wrong Level of understanding
1. Not OWNING the requirement.
Understanding how to validate the
requirement has been achieved. The team
should be able to to not only articulate what
the requirement is but also know when it has
been successfully delivered. (COS)
2. Unspoken requirements (Context: technical
& business )
5. Wrong People
1. Not getting requirements from the right
people (getting requirements from owners
vs users) (Understand Who uses the system)
2. Roles in and outside of system not clearly
defined
6. Wrong Perspective
1. Epic Splitting (part of the problem being
solved but part not addressed now.
Integration of stories within an epic can
cause additional issues) (Planning for
integration with Epic Breakdown)
2. Legitimate Changes in requirements
(scope swap)
7. Wrong Priorities
1. Conflicting Priorities among Business
communities. Conflicts between users an
management and between different
groups
2. Gold Plating/Requirement stuffing (What i
really meant was... or it wont really be
complete if it does not do X) (Prioritization
& Value assessment)
8. Wrong Techniques/Tools/Tactics
1. Poor design, architecture, technique or
coding practices leads to poor results
2. Code not getting adopted or poor reuse
(Inspect & Adapt)

68. For discussion Purposes only Confidential
Page 68
QUESTIONS

69. For discussion Purposes only Confidential
Page 69
Strategic IT services
Does your organization have a clear vision for its use of Information technology? Is your
organization using the right technologies to enable your business to execute its vision?
Does your organization have the right team to execute its vision? Is your organization
using the right tactics to execute the vision?
Target: Vision Direction Progress
• Business/Technology Portfolio Assessments
• Business Data Profiling Mapping
• Product road mapping,
• Support process definition
• Product Business Analytics
• Change Management
Tools: Defining the right Technology Stack
• Technology Assessment
• Technology Roadmap
• Technology Selection
Tactics: Optimizing Execution
• Process Improvement
• Process Assessment,
• Process Definition
• Process Metric Definition,
• Process Analytics
• Project Execution
• PMO Assessment,
• Agile Adoption Planning
• Agile coaching and training (Scrum, LEAN),
• Project Management Team augmentation
• Project Tools Implementation,
• Project Execution Analytics
Team: Talent Acquisition and Development
• Evaluation/Assessment
• Strategic Staff Augmentation
• Coaching
• Training
• Leadership development
• Succession planning
Contact us
Revolutionary Performance Management Inc.
www.thinkrpm.com
202-360-4932

70. For discussion Purposes only Confidential
Page 70
STUFF I NEED TO ORGANIZE

71. For discussion Purposes only Confidential
Page 71
Agile Team Roles
Role: User Experience Designer (UX)
Key Activities:
Defining the User experience across interfaces including browsers and devices
Defining the prototypes
Core Skill sets: Key skill sets and strengths required
Able to define/refine the UX elements of the architecture to address current
and future needs
Able to identify and establish key UX practices that lead to code reuse, easy
integration, scalability and maintainability
Ability to hear the unspoken requirements by understanding what people are
experiencing and have become accustomed to using or want to use
Transforming requirements into powerful positive experiences for the customers
by adjusting to the requirements and feedback.
Keeping ahead of the curve on technical trends that make user experiences
better including upgrades in current technologies and transitions to new ones.
Standard project role comparison: Designer UX and Architect
Key differences:
Most UI designers are only focused on style sheets, java script or frameworks. By
empowering the UX designer to define the architecture and overall
experience the UX is able to build an experience from the prototype through
deployment that makes cross platform integration and platform upgrade not
only possible but expected improvements.

72. For discussion Purposes only Confidential
Page 72
What are we selling
Unified Project leadership core teams.
Units that supply value throughout the development cycle in key
areas:
Product Ownership
Technical Expertise
Talent Development
Consistent Structured requirements and testing process
Consistent UI development approach (optional)
Instant functional teams
Consistency in planning
Known commodities in process expectations and roles
Known delivery styles
Consistency in execution
Cohesive units easily digest intended scope, and quickly move to execution
Continuity in team dynamics
Largest variable in software is team turnover. With a consistent approach to onboarding development team members and a focused approach
towards indoctrinating with process and tool usage the focus shifts to allowing developers to do what they are being paid to do.
Maximize development resource time
Reduce onboarding time
Increase developer productivity with structured talent development
Just add developers and testers

73. For discussion Purposes only Confidential
Page 73
Agile Team Roles
Role: Product owner
Key Activities:
Set product vision and direction
Manage customer expectations
Manage the project and associated artifacts
Core Skill sets: Key skill sets and strengths required
Forward thinking visionary
Able to decompose concepts into phases or components
Technical enough to understand implications of technology decisions
Business savvy enough to understand implications of business matters.
Able to translate business issues into technical terms and technical issues into
business terms.
Standard project role comparison: Project Manager
Key differences:
Product owner is more closely tied to the overall business benefit of the project
and its impact over the life span of a product. The PO is keenly interested in
the timely delivery of scope as much or more than most stake holders. They
also have a vested interest in assembling the best team to consistently deliver
efficient value for their product through a series of projects.

74. For discussion Purposes only Confidential
Page 74
Agile Team Roles
Role: Scrum Master
Key Activities:
Manage the project execution process
Educate the key stakeholders, executives and team members
Remove project/process and task impediments
Facilitate scrum process and key activities
Core Skill sets: Key skill sets and strengths required
Excellent leadership and facilitation skills
Able to explain key agile concepts to a variety of audiences
Excellent communication skills
Expert in the process able to communicate the value of the process nuances
and coach participants in the proper way to execute
Focused on continuous improvements for the team, management and the
product owner and customers alike
Standard project role comparison: Project Manager
Key differences:
The project manager is tasked with planning and navigating issues, risks and
facilitating the monitoring controlling and execution of a project in its entirety.
While these are scrum master duties the typical pm is also focused on scope
management and resources. The product owner is tasked with managing the
definition of scope while the scrum master monitors changes.

75. For discussion Purposes only Confidential
Page 75
Agile Team Roles
Role: Technical Lead/Architect
Key Activities:
Set Technical Direction
Guide Development resources
Provide tactical and strategic
Core Skill sets: Key skill sets and strengths required
Able to define/refine an architecture to address current and future needs
Able to identify and establish key programing practices that lead to code
reuse, easy integration, scalability and maintainability
Ability to increase the technical acumen of the development team.
Ability to view and assess potential enhancements with accurate effort
estimations and potential impact analysis on the current infrastructure.
Ability to identify talented development team members
Standard project role comparison: Senior Developer or Architect
Key differences:
A technical team lead is given the luxury of focusing on a specific product
and architecture while most senior developers are forced to switch context
throughout the day. Their focus enables a greater trade off in both better
architecture and better practices resulting in higher code quality, efficiency
and accuracy of projections and lower total cost of ownership for the code.

76. For discussion Purposes only Confidential
Page 76
Agile Team Roles
Role: System Analyst
Key Activities:
Defining success criteria and conditions of satisfaction
Identifying and removing barriers for adoption including Training business users
Facilitating transition to maintenance
Core Skill sets: Key skill sets and strengths required
Highly technical and able to identify and communicate barriers for adoption
by business users including personal, technical, process specific issues
Deeply analytical and able to determine trends in usage or lack of usage.
Able to identify trends in data and application improvement requests as
potential enhancements.
Able to establish execute and validate test scenarios/conditions of satisfaction
Great at identifying and eliminating non-technical barriers in adoption
Standard project role comparison: Business Analyst
Key differences:
A business analyst typically is focused only on the definition of requirements
and the validation of the delivery of requirements. The system analyst is both
technical and process but more focused on what the application does and
does not currently do. They look for reasons people wouldn’t use the
application in order to eliminate potential barriers for adoption especially
those that don’t require development.

77. For discussion Purposes only Confidential
Page 77
Performance Measures
Project Success
Budget
Scope
Time
Client Satisfaction
Development Team Success
Vision
Deliverables
Scope delivered
Speed of Delivery
Quality of Delivery
Residual Value of delivery
Reuse
Planned and unplanned value
Reduced maintenance
Teamwork:
Listening
Trust
Innovation
Agile Team Success
High Value Delivery
Reduced Code Waste
High Visibility
Development
Implementation
Self Managed Teams
Accountable
Transparent
Innovative