The document discusses adopting an agile approach to requirements in software development projects. It begins by defining key agile terms like agile, requirements, and scrum team roles. It then discusses the benefits of agile like more relevant software and higher customer satisfaction. However, it also notes risks to agile success like having the wrong ideas, context, level of understanding, people or perspective involved. It provides tips for addressing these risks, such as understanding the big picture, proactively listening to gather requirements, and using techniques like progressive elaboration.

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
EDUCATE YOUR STAKEHOLDERS

25. For discussion Purposes only Confidential
Page 25
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

26. For discussion Purposes only Confidential
Page 26
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

27. For discussion Purposes only Confidential
Page 27

28. For discussion Purposes only Confidential
Page 28
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

29. For discussion Purposes only Confidential
Page 29
PROACTIVELY LISTEN

30. For discussion Purposes only Confidential
Page 30
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

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

32. For discussion Purposes only Confidential
Page 32
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.

33. For discussion Purposes only Confidential
Page 33
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

34. For discussion Purposes only Confidential
Page 34
Progressive Elaboration

35. For discussion Purposes only Confidential
Page 35
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

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

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

38. For discussion Purposes only Confidential
Page 38
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

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

40. For discussion Purposes only Confidential
Page 40
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

41. For discussion Purposes only Confidential
Page 41
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

42. For discussion Purposes only Confidential
Page 42
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

43. For discussion Purposes only Confidential
Page 43

44. For discussion Purposes only Confidential
Page 44
Decomposing Epics

45. For discussion Purposes only Confidential
Page 45
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

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

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

48. For discussion Purposes only Confidential
Page 48
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.

49. For discussion Purposes only Confidential
Page 49
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

50. For discussion Purposes only Confidential
Page 50
Assessing Value

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

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

53. For discussion Purposes only Confidential
Page 53
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

54. For discussion Purposes only Confidential
Page 54
The Backlog

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

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

57. For discussion Purposes only Confidential
Page 57
Backlog Assessment

58. For discussion Purposes only Confidential
Page 58
Backlog Overview

59. For discussion Purposes only Confidential
Page 59
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

60. For discussion Purposes only Confidential
Page 60
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

61. For discussion Purposes only Confidential
Page 61
RECAP

62. For discussion Purposes only Confidential
Page 62
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)

63. For discussion Purposes only Confidential
Page 63
QUESTIONS

64. For discussion Purposes only Confidential
Page 64
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