Agile Processes: Scrum

Sprint as a Segway to Agile…

• Scrum is a means of introducing agile methods into a
traditionally disciplined environment.
• Because of this, Scrum has gained widespread
popularity!
• Scrum can be used for one or more components of the
system and this allows management to assess Scrum
effectiveness without completely changing the way the
organization normally does business.
• Scrum is NOT Extreme Programming
 Scrum and Scalability

• Scrum: one of the few agile methods used to scale

up for larger projects.
• How done?
– Accomplished the same way as organizations
handle integrated product teams.
– Individual Scrum team coaches - part of a higher
echelon team of coaches spanning several
products.
– This provides for communications to avoid
conflicting development issues
 The Purpose of Software
Development is…
To provide a suitable solution for
users…
That consists of quality code…
And doesn’t cost too much
Where Use Cases Live

Suitable = Useful +
Usable
 What is a Use Case?
• From an Analytic Perspective, a use case is
way to discuss with users how the system will
enable a user to get something done
• However, from a Development Perspective, a
use case is a collection of scenarios that have
to be coded up
– Success scenarios
– Alternative scenarios
– Failure scenarios (graceful degradation)
– Bugs (new failure scenarios)
• We Use Scenarios as the Basis for our Work
 The Purpose of Use Case Analysis
• To develop scenarios that drive development
– We want a system that works…
– Whose scenarios “get the job done”
– Usable would be nice…
• Agile Development
– Scenarios are developed as they are produced and
prioritized
– Developed scenarios are validated as they are
produced
– Scenarios are developed as soon as possible, so
that we can have something to show our
customers and users
 Validate a Scenario Four Ways before
Actual “code it up”
• Is it useful?
– Did it satisfy its post-conditions?
• Is it usable?
– May require storyboards and wireframes to validate
• Is it buildable?
– Must verify with developers that fits within architectural
scheme, etc
• Is it testable?
– Can we envision the test scenarios we need to test it?
 “good” Team Philosophies,
leading to Agility
• One Bite at a Time: reminds us to do things a little at a time, with
planning, validation, and management of the pieces.
• Validation Centricity: reminds us that the activities of validation,
verification and test are “more important” than those of analysis,
design, and construction; and that we must actively look for things
that cause us to change.
• Don’t Do What you Don’t Need: work on those things with the
most value; avoid analysis paralysis, and keep moving
• Quality Can’t be the Variable: When balancing the three main
variables (scope, time, quality), quality can’t be the one that slips
• Let the Product Lead: decisions must be based on the product, not
documented plans, analysis, requirements, or designs.
 Managing the Building of Product
• Work Backlog: an evolving, prioritized queue of
business and technical functionality that needs to be
developed into a system (Source: Scrum)
• Story: Describes some item of value to a user or
product owner (Source: XP, Cohn)
• Task: Well-defined unit of work in the process that
provides management with visible checkpoints into
the status of the project. Tasks have readiness
criteria and completion criteria. [Jones - IBM]
(Source: SEI:SE-CMM)
 Example Stories
• Description: Shop for Round Trip Flights
– Size: Big
– Validation: Functional test each Scenario
• Description: Round Trip, single passenger, no luggage, no seat
selection, one leg
– Size: Large
– Validation: Functional Testing
• Description: Add the Cello
– Size: Small
– Validation: Functional Testing
• Description: Help Marketing Prepare materials for the trade
show
– Size: Large
– Validation: Inspection by Marketing
 Example Tasks
• Description: New build script
– Estimate: 6 hr
– Owner: Sue
– Exit Criteria/Verification: Build succeeds, Joe will inspect results
• Description: Add the “multi-passenger” check-box to the
EntryScreen
– Estimate: 4 hr
– Owner: Joe
– Exit Criteria/Verification: Unit tests written and passed
• Description: SQL Training
– Estimate: 2 days
– Owner: Sue/Joe
– Exit Criteria/Verification: training completed
 The Basic Development Loop
• For Each Iteration you:
– Plan Simplified Scrum
• What’s the next stuff to do? (an agile process)
– Analysis Work
– Design Work
– Implement some
functionality
– Write Functional Tests
– Run Functional Tests
• The team decides how much it
can do
– Perform – You do it
– Evaluate – You evaluate both
the Product and the Process
• Repeat…
• You manage this iteration with
Work
the Work Backlog Backlog:
 Needs, Use Cases, Stories, Tasks –Creates
Work We Need to Manage
• Here’s what I recommend for the major steps
in moving from a User’s need to a collection
of Developer Tasks

Business Level Need

Detail a Use Case
Use Case
Ever-Unfolding Story
Scenario/
Product Level User
User
User
Story
Story
Story
Story
Iteration Planning Game

Task
Task Task
Task
Development Level Task
Task Task
Task
Task
Task Task
Task
 Use Cases aren’t the “only” thing going on…
ATM Project

Product Team Business

Management Sales Spt

Function Structure
Team Marketing
Training Support
Login Conversions Dev/SCM/Test User
Environments Training
Withdraw
Rewrites Dev
Cash User Docs
Process
Deposit
Refactorings App Business
Check
Framework Framework
Transfer
Funds … Tools
Adapt
Processes
Refresh Cash
Maintenance
Drawer
The Use Cases Docs …
… Populate the
…
“Function” Leg
Generating Scenarios for the
System
What Is The
System For?
Vision

Usability Concerns
What Should The
Use Case List
System Do?

What Should This

Pre/Post-Conditions
Use Case Do?
UI Design,
Development,
How Do We Make Basic Scenario Refactoring
It Do That?

What Could Go
Alt Scenario
Wrong?
What Pieces Do Design and
We Need? Development
What Else Might It
Ext Scenario
Do?

What Could Be
Parallel Scenarios
Different?
 Assumptions About Usability
• That it can be done incrementally
• That minimal up-front analysis needs to be done
– This doesn’t mean “none”, though, IMHO
• That interfaces can be refactored together as we go
• That “middle tier” can be separated from UI layer in
order to separate logic from interface in such a way
that logic persists even if UI changes
 The importance of up front
studies and scoping
• Do just enough to feel comfortable, then dig
in. Refine as you go, knowing that you
probably didn’t get it right, but hoping that
you got close enough…
 Analysis paralysis – how much is
enough
• Analysis paralysis is a boogie man that
programmers constantly raise because they
don’t feel the project is started until you begin
coding.
• Analysis Paralysis is a trap for everyone. You
defeat by constant validation and moving
forward once you have “enough”. Not what
you think is enough, but what the team thinks
is enough.
 User interface integrity &
consistency
• These are critical factors that affect usability –
they depend on adequate scoping,
development of a conceptual model (the
model offered to the user to help them form
their mental model), a UI that covers most of
the scope, and a Style Guide.
• It would be nice, but it is more important that
the system accomplishes its mission, making is
usable is different than making it “nice” to use
 Conceptual model development
• Few good UIs can depend on metaphors –
what you really need is a good understanding
of the major objects and processes that the
user interacts with and what they mean to the
user.
• And this can be done best by exploring the
objects as they come up in analysis and
development throughout the agile process;
doing it up front leads to hasty (and probably
incorrect) conclusions.
 Style Guide development
• There are several levels of Style Guide
required: corporate branding, product family,
and product specific.
• No doubt. The questions are “how soon do
you need it?” and “When does it get
developed?”
 Detail design of user interface
• The more of this that can be done before
coding gets started, the better.
• Do it one scenario at a time, and refactor
them together. UI designers can’t help looking
forward to future scenarios in order to lay out
their real estate on the screen, but they must
realize that they are probably going to have to
change things once those scenarios actually
come up for development.
 Usability testing during agile
increments
• Depends on the iteration. Release iterations
require extensive usability testing, just as they
require extensive QA. Development iterations
only require demos and testing to make sure
that risks are being properly mitigated.