The document discusses agile principles and practices for software development and solution delivery. It outlines how scrum can be applied to both areas, including establishing story-level and unit tests, iterative development through sprints, and acceptance of features by business stakeholders. For solution delivery using packaged software, additional challenges are test automation and defining the product manager role given pre-existing packages.

1. 1
Outline
„ Level Set on What Is Agile
„ Level Set on Life Cycles
„ Start with the Ideal: Software Development
„ Bring It Up a Level: Solution Delivery
„ Talk About the Challenges of Enterprise Agile
„ Talk About the Agile Goodness to Harvest, Now

2. 2
What Is Agile
The Myth The Reality
It’s Faster It’s Faster to First Benefit, Not
Faster to All Benefits
Requirements? Design?
Documentation? Planning? Nah.
Yes, Some Up Front and then
Refine Continually.
Needs Heroes Needs Discipline
No Project Manager Project Manager with an Emphasis
on Leadership
No Risk Management Retrospectives and Frequent
Interaction with the Business
No Budget Initial Budget is Refined based on
Actual Experience.

3. 3
What Is Scrum
From: http://msdn.microsoft.com/en-us/library/dd997796(v=VS.100).aspx

4. A Collection of Life Cycles
„ Solution Acquisition Life Cycle
„ Solution Delivery Life Cycle
„ Software Development Life Cycle
4
Do Scrum and Agile Apply to All Life Cycles?

5. 5
Scrum for Software Development
„ The Up Front Stuff
„ Product Backlog/Impact Map/Story Map
„ Release Plan
„ High Level Design
„ Team Organization
„ Expect Adjustments
„ Development System Setup and Testing
„ Test By Building A Real Feature
„ The Rest of the Sprints
„ Plan the Sprint (select from story map)
„ Build and Test (with the business)
„ Test Everything from Previous Sprints (with the business)
} Iteration Zero

6. 6
Scrum for Software Development (cont.)
„ Iterative
„ Evolving the Deliverables Created to Date
„ Evolving the Documents/Features Already Delivered and
Accepted
„ Iterating means re-testing and therefore demands automation
„ Incremental
„ Delivering Features and/or Benefits One at a Time
„ Accepting Features and/or Benefits One at a Time

7. 7
Agile Testing – Story Level Tests
„ Use Examples to Describe a Feature
„ Implement Examples in a Test Automation Tool
„ Demand a Testable Architecture
„ Array of Choices:
„ Inside/Outside the GUI
„ Table/Scenario/Keyword Driven (i.e., Fitnesse/Cucumber/
RobotFramework)
„ User acceptance testing (UAT) is part of every sprint,
not a critical path phase after delivery

8. 8
Agile Testing – Unit Level Tests
„ Prescribe the design element in the form of
automated tests
„ Finish implementing the design element when all the
tests pass
„ Maintain these tests just like they are production
code

9. 9
Agile Testing – All Tests
„ These must be automated since they can be run
hundreds or even thousands of times
„ Simple experiment was to create a logging version of
a popular test automation framework and have
developers use that, then analyze the generated log
files.
„ Even a simple CRUD feature involved running some tests over
one hundred times.

10. 10
Agile Testing – The Difference
„ Initially it’s not about ‘testing’ but rather using testing
skills for different purposes:
„ To better understand requirements (story level tests) using
examples. As many examples as we can imagine for any given
requirement.
„ To better explain a design (unit level tests). These are also
examples, specifically examples of how components should interact
with one another or how a specific programming unit should behave.
„ THEN the usage of those tests changes
„ For refactoring – improving the design without changing the
behaviour
„ For regression testing – enabling changing or adding features without
stress by re-running the tests quickly
„ It’s valuing mean time to repair (MTTR) over mean time
between failures (MTBF)
„ It means establishing a cadence

11. 11
Agile Testing – More Differences
„ The Product Manager Chooses the Features/Benefit
to Deliver in a Sprint
„ A Feature/Benefit Doesn’t Exist Unless Tests For that
Feature/Benefit Exist (story level and unit level)
„ A Developer Automates Tests First as a Means of
„ Better Understanding the Requirements (Story Level Tests)
„ Determining and Communicating the Design (Unit Level Tests)
Everyone on the Team is a Developer
That’s Right, No Business Analysts or Testers

12. 12
Scrum for Software Development (cont.)
„ Solution: Pairing
„ BA-oriented developer “pairs” with a coding-oriented developer and
this is considered GOOD
„ Test-oriented developer “pairs” with a coding-oriented developer
and this is also considered GOOD
„ BA-oriented developer “pairs” with a test-oriented developer and
this too is considered GOOD
„ Solution: Feature Advocacy
„ Team plans the sprint together, reviews each feature/benefit that
has been designated for the sprint
„ All skills contributing together up-front, everyone understands the
tasks that contribute to the sprint
„ Individual strengths and preferences are expressed in what tasks one
chooses to complete for the sprint and in “coaching” others

13. 13
Scrum for Software Development (cont.)
„ The Product Manager Accepts and Demonstrates the
Features/Benefits Delivered in a Sprint
„ This is HARD. It is not easy accepting a feature/benefit when the
entire solution is not yet complete.
„ This is REALLY HARD. It is not easy accepting a feature/benefit
on behalf of others that are not in the room.
„ A Retrospective (a form of testing) Gives the Team a
Chance to Improve for the Next Sprint

14. 14
Example: The Enterprise App Store
What Would It Take to Build from Scratch?

15. 15
Example: The Enterprise App Store (cont.)
Story Template Story Test Template
As a <blank>
I want to <blank>
so that <blank>
Given <blank>
when <blank>
then <blank>

16. 16
Example: The Enterprise App Store (cont.)
Story Story Test
„ As the store manager
I want to review submitted
apps
so that I can approve or
reject as per policy
„ Given an app and a
registered dev,
when they submit it for
review
then it appears on the to-
be-approved app listing
„ Given an app on the to-be-
approved app listing
when the store manager
approves it
then it should appear in the
new app listing

17. 17
Scrum for Solution Delivery
„ Commercial Off-the-Shelf (COTS) implementations
„ Delivery combines installation, configuration,
customization, and perhaps integration of the
package

18. 18
Sidebar: What Happens During UAT When a
Problem/Issue is Discovered?
„ Whole Team Approach; Problem is immediately ‘triaged’ by
business and technical people together. Best team/member
to resolve picks up the problem.
„ Could be problem/issue with training materials
„ Could be the business process that is wrong
„ Could be the software and it truly is a ‘defect’
„ Backlog; Problem is grouped with other problems and work
is prioritized; team can’t work on them all but works on as
many as they can.
„ Acceptance; Business users/customer accepts the
resolutions to the feature within the phase. Project
continues.

19. 19
Sidebar: What Happens During UAT When a
Problem/Issue is Discovered? (cont.)
„ Duration; a typical UAT phase for an enterprise project is 2-4
weeks. A typical Scrum sprint is 2-4 weeks.
„ Now replace the term ‘problem/issue’ in this conversation
with ‘need/gap’.
„ Now string 10 of these ‘UAT’ phases together with planning/
adapting workshops in between to steer the project.
„ What do you get?
„ Yup. You get an agile project.

20. 20
Scrum for Solution Delivery
„ The Up Front Stuff
„ Product Backlog/Road Map/Story Map
„ Release Plan
„ High Level Design
„ Team Organization
„ Expect Adjustments
„ Development System Setup and Testing
„ Test By Building A Real Feature
„ The Rest of the Sprints
„ Plan the Sprint (select from story map)
„ Build and Test (with the business)
„ Test Everything from Previous Sprints (with the business)
Challenges …

21. 21
Scrum for Solution Delivery (cont.)
„ Iterative
„ Evolving the Deliverables Created to Date
„ Evolving the Documents/Features Already Delivered and
Accepted
„ Iterating means re-testing and therefore demands test
automation and in a package development environment, does
not always exist
„ Incremental
„ Delivering Features and/or Benefits One at a Time
„ Accepting Features and/or Benefits One at a Time

22. 22
Scrum for Solution Delivery (cont.)
„ The Product Manager Chooses the Features/Benefit
to Deliver in a Sprint
„ A Feature/Benefit Doesn’t Exist Unless Tests For that
Feature/Benefit Exist (story level and unit level)
„ A Developer Automates Tests First as a Means of
„ Better Understanding the Requirements (Story Level Tests)
„ Determining and Communicating the Design (Unit Level Tests)

23. 23
Scrum for Solution Delivery (cont.)
„ The Product Manager Accepts and Demonstrates the
Features/Benefits Delivered in a Sprint
„ This is HARD. It is not easy accepting a feature/benefit when the
entire solution is not yet complete.
„ This is REALLY HARD. It is not easy accepting a feature/benefit
on behalf of others that are not in the room.
„ A Retrospective (a form of testing) Gives the Team a
Chance to Improve for the Next Sprint

24. 24
Example: The Enterprise App Store
„ What Would It Take to Buy a Package and Implement
the Enterprise App Store based on that Package?
„ Do We Create the Story Map?
„ Use Product Backlog/Impact Maps/Story Maps to
describe what’s needed?
„ Release Planning?
„ Sprint Planning?
Yes

25. 25
Example: The Enterprise App Store (cont.)
„ Story Level Tests?
„ Unit Level Tests?
Harder

26. 26
Summary
As an agile team member,
I want to have testing skills
So that I can express requirements using examples
Given an agile project
when the team releases a new feature
then tests describing that feature are also released
For package implementations, there are challenges
that would be a competitive advantage if they were
worked out:
„ test automation
„ the product manager role

27. 27
Summary (cont.)
„ Testing skills are more useful than ever in describing
requirements
„ To see the difference, if any, convert a set of requirements you
are familiar with to the given-when-then style
„ All of a sudden, by understanding the requirements better, you
have built the test plan for that requirement … and in the right
context you have already built the regression suite for that
requirement
„ Testing skills are more useful than ever in delivering
quality code
„ Quality as measured by testability and maintainability at a
minimum

28. 28
Questions
„ adam.geras@solvera.ca
„ @testfirst