www.uSell.com
Agile @ uSell
Akshay Singhal
May 2014
Structure
• Why
• What
• How
History geeks can read more about Winston Royce at http://en.wikipedia.org/wiki/Winston_Royce and the
original paper at http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
The “Traditional” Approach
• In 1970 Dr. Winston W. Royce published a paper titled “Managing
The Development of Large Software Systems”, which in later years
came to be known as the “Waterfall” paper
• He described a process for software development based on his
experience on Spacecraft Mission software projects, with suggested
additions for further improvements in the process.
• His goal was to create a process that leads to success on projects,
leading to systems reaching operational state within time and
within budget
• Over the years, using the innate human ability of selective learning,
people adopted the steps described in the paper as a recipe, without
understanding the context.
History geeks can read more about Winston Royce at http://en.wikipedia.org/wiki/Winston_Royce and the
original paper at http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
The Relay Race
• This approach resembles a Relay Race
• To win, each step should execute perfectly
and the handoff from one step to the other
should be done perfectly
• This approach has been used for years
now, with varying degrees of success
The New Approach
• In 1986 Hirotaka Takeuchi and Ikujiro Nonaka published a paper
titled “The New New Product Development Game”
• They studied companies in the US and Japan which rely on
developing new products for success and described a holistic or
“rugby” approach
“This new emphasis on speed and flexibility calls for a different
approach for managing new product development. The
traditional sequential or “relay race” approach to product
development……may conflict with the goals of maximum speed
and flexibility. Instead, a holistic or “rugby” approach—where a
team tries to go the distance as a unit, passing the ball back and
forth—may better serve today’s competitive requirements.”
Read more about the “New” approach here http://hbr.org/1986/01/the-new-new-product-developmentgame/ar/1
The Right Approach for Product Development
• The right approach depends on your
problem domain
• The Cynefin framework was originally
developed in 1999 by Dave Snowden.
The framework provides a typology
of contexts that guides what sort of
explanations or solutions might
apply.
• Using this framework, New Product
Development seems to be in the
Complex Domain
You guessed it, more reading here http://en.wikipedia.org/wiki/Cynefin
Manifesto for Agile Software Development
• In 2001, 17 representatives from Extreme Programming, SCRUM,
Adaptive Software Development, Crystal, Feature-Driven Development,
Pragmatic Programming etc. met to find common ground
“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.”
The whole manifesto and the back story is available at http://agilemanifesto.org/
Agile Principles
Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the
project.
Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
Agile Principles
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances
agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from selforganizing teams.
At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
SCRUM
• Jeff Sutherland created the first Scrum team in 1993, and presented
the a formalized version at OOPSLA’95 with Ken Shwaber
• Scrum is a simple, people-centric framework based on agile
principles and values.
• Scrum is not a standardized process where you methodologically
follow a series of sequential steps to success, it’s a framework
• Scrum is
• Lightweight
• Simple to understand
• Difficult to master
The official definitive description of Scrum is embodied in the Scrum Guide, managed by the creators of
Scrum https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf#zoom=100
SCRUM Framework
All images used in this presentation are available at http://www.innolution.com/ , from the visual pattern
language used in the book Essential Scrum
SCRUM Team
• The Scrum team consists of the Product Owner, Development Team and the
Scrum Master
• Scrum Teams are self-organizing and cross-functional. The team model in
Scrum is designed to optimize flexibility, creativity, and productivity
SCRUM Product Owner
• The Product Owner is the central point of product leadership. The single
authority responsible for deciding which features and functionality to build
and the order in which to build them
• The Product Owner maintains and communicates a clear vision of what the
team is trying to achieve, and is responsible for overall success of the
solution being developed
• The Product Owner is the sole person responsible for managing the Product
Backlog
• The Product Owner may represent the desires of a committee, but those
wanting to change a Product Backlog item’s priority must address the
Product Owner
• For the Product Owner to succeed, the entire organization must respect his
or her decisions. No one is allowed to tell the Development Team to work
from a different set of requirements, and the Development Team isn’t
allowed to act on what anyone else says.
SCRUM Development Team
• The Development Team consists of professionals who do the work of
delivering a potentially releasable Increment of “Done” product at the
end of each Sprint
• Development Teams are structured and empowered by the
organization to organize and manage their own work. The resulting
synergy optimizes the Development Team’s overall efficiency and
effectiveness
• Scrum recognizes no sub-teams in the Development Team, regardless
of particular domains that need to be addressed like testing or
business analysis; there are no exceptions to this rule
• Individual Development Team members may have specialized skills
and areas of focus, but accountability belongs to the Development
Team as a whole.
SCRUM Scrum Master
• The Scrum Master is responsible for ensuring Scrum is understood and
enacted in the organization
• The Scrum Master is a servant-leader for the Scrum Team. The Scrum
Master helps those outside the team understand which of their
interactions with the Scrum Team are helpful and which aren’t
• The Scrum Master assists the Product Owner find techniques for
effective Product Backlog management, helping the team understand
the need for clear and concise Backlog Items
• The Scrum Master coaches the development team in self organizing and
cross functionality and removes impediments to the Development
Team’s progress
• The Scrum Master practices agility and facilitates Scrum events as
requested or needed
SCRUM Activities and Artifacts
• Product Backlog
• Backlog Grooming
• Sprint Planning
• Sprint Backlog
• Sprint
• Daily Scrum
• Sprint Review
• Sprint Retrospective
SCRUM Product Backlog and Grooming
• Product Backlog is an ordered
list of items that represent
changes / additions that need to
be made to the product
• Highest value items are at the
top
• Large items are broken down
into smaller pieces
• Priorities are changed based on
feedback from each release,
changing markets etc.
• Rinse - repeat
SCRUM Product Backlog and Grooming
• Features in the backlog are described as user stories. A User Story has
the format
As a <type of user>, I want <some goal> so that <some reason>
• Stories in the backlog start as an Idea, or an Epic. At this stage the
feature is abstract, incomplete and / or not actionable.
• Through requirement gathering discussions and grooming, Epics are split
into smaller stories that satisfy the definition of “Ready”
• All “Ready” stories are then ordered to reflect the value of each story,
ensuring the highest value stories are developed first
Definition of “Ready”
• For a Story to be “Ready”, following criteria have to be met
• The story should reasonably show INVEST characteristics
I – Independent / Immediately actionable
N – Negotiable
V – Valuable to the customer, user or product
E – Estimable
S – Sized to fit
T – Testable
• The business implications of the story have been discussed, any impacts
to finance, customer care have been addressed
• The User Interaction Design is ready (At the very least wireframes
covering all interactions of the story should be available)
• Any design assets needed for the story have been prepared to a
reasonable degree (PSDs for some if not all pages in the Story should be
available)
Definition of “Ready”
• In case the story includes interactions with a third party API, technical
feasibility has been completed, and a testing strategy is in place
• Release dependencies have been resolved, to ensure the story is released to
production in a sequence that makes business sense
• Grooming is a collaborative process
SCRUM Sprints
• A Sprint is time-boxed iteration or cycle of up to 1 month
• The work completed in each sprint should create something of
tangible value to the customer or the user of the product
• Sprints have a fixed start and end date, and are usually of the same
duration
• No goal-altering changes in scope or personnel are allowed during a
sprint
• A sprint consists of following activities
• Sprint Planning
• Daily Scrum
• Sprint Review
SCRUM Sprint Planning
• Work to be done in the Sprint is planned at Sprint Planning
• The Scrum Team reviews the product backlog and determines the highest
priority items that the team can realistically accomplish in the upcoming
Sprint
• Work selected to be part of the Sprint is called Sprint Backlog. It contains
the stories and tasks needed to be accomplish those stories
• For a Story to be allowed to enter the Sprint Backlog, it needs to pass the
definition of “Ready”
SCRUM Sprint Execution
• After planning, the Development team gets down to the business of getting
stories in the sprint backlog “Done”. The scrum team agrees on a definition of
“Done”. A story is considered to be complete, only when it satisfies this
definition
• Each day of the Sprint, ideally at the same time, the Scrum Team hold a
timeboxed daily Scrum, where each development team member answers the
following questions:
• What did I accomplish since the last daily Scrum?
• What do I plan to work on by the next daily Scrum?
• What are the obstacles or impediments that are preventing me from
making progress?
• The daily scrum is an inspect-adapt tool for the team to self-organize, it is not
an update meeting for higher ups. Through his participation in the meeting,
the Product Owner gets visibility into the current state of the sprint
• The Development Team does most of the talking, the Product Owner answers
questions, and the Scrum Master facilitates
SCRUM Sprint Execution
• By the end of the Sprint, all items that are “Done” become part of the
shippable increment of the product
• Any not done items are carried over to the next sprint for further work
SCRUM Sprint Review and Retrospective
• At the end of the Sprint, in Sprint Review, the product increment is reviewed to
inspect and adapt the product. The Scrum Team presents the increment to
stakeholders, sponsors, customers etc. Their feedback is solicited and used to
update the product backlog
• After the Review, the Development team meets to conduct a Retrospective. This
is another inspect and adapt tool used by the Development Team and Scrum
Master to fine tune the development process.
Thank you