1. Delivering value early
and often, giving
ourselves the best
opportunity to beat the
competition to market,
realize revenue and
discover insights that
we can use to help us
improve
The Business Proposition

2. Roadmap to “being” agile
• Delivery of commercial or operational value early and
often, giving ourselves the best opportunity to beat the Agile
competition to market, realize revenue and discover Coaching &
insights that we can use to help us improve Training
• Cross-functional, collaborative and adaptive teams
developing and delivering value-added product (system-
software) increments in a continuous flow from
requirements to deployment Agile Scrum
• Avoiding the high cost of discovering defects late in the Cultural Adoption Coaching &
Renewal Training
development cycle by discovering defects early in the
development cycle which is accomplished by
eliminating waste, increasing feedback loops and
developing code from the point of view of provability
and outside-in design
Organizational
• Emphasis is placed on the need for teams to nurture Change
Management
group cohesion, and paying attention to norms that
serve as a guide that strengthens positive practices
• Minimizing frustration levels and making the art and
science of system-software development enjoyable and Delivering value early and
not a burden or death march often, giving ourselves the
best opportunity to beat the
• The what, why, and how of agile/lean product (system-
competition to market,
software) development and delivery is not one persons realize revenue and
vision alone; to become reality it needs to be a "shared" discover insights that we
vision through negotiation and compromise between can use to help us improve
individuals, the team and the organization
2

3. Recent
Data Points
Russell Pannone (805) 910-6481 3

4. 4

5. 5

6. Gain
feedback Accept Lower
through change project risk
iterative without through
incremental slowing higher
value down visibility
delivery
Delivering
value early
and often,
giving
ourselves
the best
opportunity
to beat the
competition
to market,
realize
revenue
and
discover
insights
that we can
use to help
us improve
6

7. Four Spheres
of Influence
CMU/SEI-2002-TR-009, ESC-TR-2002-009, July 2002
1. Sphere 1 - Stakeholder Needs and Business Processes: This sphere denotes requirements (including
quality attributes such as performance, security and reliability), end-user business processes, business
drivers and operational environment.
2. Sphere 2 - Architecture and Design: This sphere denotes the essential elements of the system, the
relationships between them, and how they fit with the enterprise system. The elements include
structure, behavior, usage, functionality, performance, resilience, reuse, comprehensibility, economic
and technologic constraints and tradeoffs.
3. Sphere 3 - Marketplace: This sphere denotes available and emerging technology and products, non-
development items and relevant standards.
4. Sphere 4 - Program/Project Management: This sphere denotes the management aspects of the
project. These aspects consider the cost, schedule and risk of building, fielding and supporting the
solution. Key to these management aspects are the cost, schedule and risk of changing the necessary
business processes.
These four spheres are simultaneously defined and traded through the life of an agile and
lean project because a decision in one sphere will inform and likely constrain the decisions
that can be made in another sphere 7

8. 8

9. Copyright © 2005, Mountain Goat Software
1. Agile puts the Product Owner (aka “the business” or customer representative) in the
driver’s seat – In the majority of the waterfall style projects the customer is involved, but in a limited capacity. They get
to define a scope up-front, but then any changes they deem necessary are change ordered back to them. This practice
assumes that the customer knows exactly what they want up front and penalizes them for changing their minds later in the
development process.
2. Agile allows the business to quickly react to changing market conditions and needs – The only
thing constant in today’s economy is change. Businesses need to be able to make quick course corrections in order to
survive.
3. Agile provides visibility into the development process – For many customers software development is a
dark art. They don’t have the background in order to understand the technical details and in most cases the development
team prefers it this way. The customer is left feeling helpless and Agile engages them throughout the development
lifecycle, providing enhanced visibility.
4. Agile also puts the Development Team in the driver’s seat - While the Product Owner is responsible
for “what” is to be developed the Development Team is self-directing and self-organizing as to “how” to develop the system-
software product
Copyright © 2008 Russell Pannone. All rights reserved.
9

10. Tooling Project - Product Backlog
10

11. Characteristics of good stories
As a <who/user> I want <what/goal> so that <why/reason>
 A good story is negotiable, testable, estimatable, commercially or
operationally value-adding, cohesive and loosely-coupled
 It is not an explicit contract for features or functionality; rather stories
are short descriptions of functionality, the details of which are to be
refined in a conversation between the Product Owner (aka, the business or
customer) and the development team
 The challenge comes in learning to include just enough detail to be able to
prioritize and estimate the size of story and minimize ambiguity
Story1 Story4
As an eligible user, I want to pay the As an eligible user, I want to access my Story11
onetime registration fee of $10, so record and delete any or all of my As an eligible user, I want to view a list
that I can access my driver’s record in information to keep it current of assembled answers to questions
the future asked most frequently of the DMV
Story5
Story2 Story12
As an eligible user, I want to access my
As an eligible user, I want to create a As an eligible user, I want to be able
record and change any or all of my
unique user name and password so find an address for my local DMV
information to keep it current
that my access is limited to my record office and print the results
and to track activity and payment
Story6 Story13
Story3 As an eligible user, I want multiple As the application, I want to maintain
As an eligible user, I want to access my payment options to pay fees so that I an audit trail of changes for each
record, so that I can verify that it is am able to access the features of the eligible user record indicating all edits
correct DMV site that require payment
Copyright © 2008 Russell Pannone. All rights reserved. 11

12. Acceptance
Criteria
 Acceptance criteria, represents the details for a story and specifies the
desired behavior and functionality the system-software must implement
 Acceptance criteria answer the question, “How will I know when I’m done
with the story?”
 Acceptance criterion is high level tests to verify and validate the
completeness of a story or stories implemented during a Sprint/Iteration,
expressed in a business domain language
 These tests are created ideally through collaboration between business
customers, business analysts, testers and developers; however the Product
Owner (aka, the business or customer) is the primary owner of these
conditions-of-satisfaction
 Test cases and acceptance criteria are two different things
 Test cases answer the questions, “How do I test and what are the test
steps?”
Copyright © 2008 Russell Pannone. All rights reserved. 12

13.  Depiction of the user
interface or maybe even a
report layout, is just as
much a part of the details
behind a story as
acceptance criteria
 Wireframes and screen
mockups are often
attached to stories as a
basic visual guide used in
interface design by the
development team
 Low fidelity diagrams
depicting a candidate
solution may also be
attached to stories to
visually communicate its
design Copyright © 2008 Russell Pannone. All rights reserved. 13

14. Where do
Optional
Stories
come from
Optional
Optional
Bus
Strategy
Use Cases
Business
Model
System Requirements
Customer Functional
Business Partner
&
Non-Functional
Product Owner
Team Solution/IT-Services
Copyright © 2008 Russell Pannone. All rights reserved. 14

15. 5 levels of Agile Planning
What, Who, Why, When, Constraints,
Product Vision Assumptions
Releases – Date, Theme/Feature Set,
Product Roadmap Objective, Development Approach
Iteration, Team Capacity, Stories, Priority,
Release Planning Size, Estimates, Definition of Done
Stories – Tasks, Definition of Done
Iteration Planning Level-of Effort, Commitment
1. What did I do yesterday?
Daily Planning 2. What will I do today?
3. What is blocking me?
15

16. A Paradigm Shift
Fixed
Variable
Source: www.dsdm.org
How is Agile Planning Different from Traditional Approaches?
16

17. 1. Selecting Stories from the
Product Backlog based on
the team’s velocity
2. Identifying the tasks to
realize a selected Story
3. Estimating the level-of-
effort required to
complete the task
Copyright © 2008 Russell Pannone. All rights reserved. 17

18. 1. Performing tasks to
complete the story
2. Completing the story
based on story acceptance
criteria and team's
definition of done
3. Developing and delivering
commercial or operational
value incrementally
Copyright © 2008 Russell Pannone. All rights reserved. 18

19. 19

20. Reduce Waste Feedback Loops
• Remove what isn’t of • Sprint Review & Planning
value to the customer • Sprint Retrospective
• Quicker delivery of value • Daily Scrum
& ROI
20