Software development with scrum methodology bhawani nandan prasad

Bhawani Nandan Prasad - IT process expert
Agile Software Development
with Scrum Methodology
Bhawani Nandan Prasad
IT Process Leadership
B.E. Computer Science, EMBA Senior
Management, MBA marketing
PMI-ACP, Scrum Master
7/28/2014

Objective
To help you understand the principles of
Agile software development and help you
practice the Scrum methodology to
ultimately improve your software
development experience
7/28/2014

Ground rules
This is YOUR workshop
Your time, my watch
Active participation is encouraged
Bhawani Nandan Prasad - IT process expert7/28/2014

Session Plan
Day-1
 Getting Started
 Issues with Traditional
Methods
 Overview and history of
Agile
 Agile Principles
 Agile methodologies
 Scrum Methodology
 Scrum Overview
 Different roles in Scrum
 Implementing Scrum
Day-2
 Managing Scrum Projects
 Estimation
 Tracking
 Communication
 Best practices
 Engineering practices
 People practices
 Risks and challenges
 Myth v/s reality
 Putting into practice!
 Summary and Discussion
7/28/2014

Why bother about Agile?
Israel Gat: Cutter Consortium:
“Agile can do to software development what
internet did to computing”
“Agile is a train. Either you get on to it or you
will be under it”
PMI research: Use of Agile has tripled
from December 2008 to May 2011
Gartner: 80% of software development
projects would use Agile by end of 2012

Problems with Software Development
 Excessively long “time to market” for products
 Customer orientation is lacking
 Over-engineered products
 ~60% features on a product are NEVER used!
 Cost of delivering software is too high
 Poor productivity of teams
 Too much “wasted work” to fix defects and rework designs
 Software quality is poor
 Ability to responding to change is low
 Employee morale is low (and attrition rates are high!)
 Project failure rate is too high
 ~70% or more
 Delivered RoI falls short of expectations
7/28/2014

Traditional Software Development
Design
Coding
Testing
DeployAdvantage: Logically sound
Disadvantage: Assumes predictability!
Analysis
7/28/2014

Evolution of Agile
 Iterative development, done in small incremental
chunks, validating requirements at each step
 Agile development evolved in mid-90’s – the
word “Agile” was adopted in 2001
 Has significant parallels with “Lean movement”
in the manufacturing world
 Is also similar to “spiral models”, except spiral
iterations are longer and rely on “prototypes,
where Agile emphasizes “working software”
7/28/2014

Providing early value
Value Realized
Time
Incremental delivery
All-at-once
Delivery
7/28/2014

Agile Manifesto – Feb 2001
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
7/28/2014

12 Principles of Agile
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.
7/28/2014

12 Principles of Agile (continued)
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.
7/28/2014

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.
7/28/2014

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.
7/28/2014

Agile Methodologies: Crystal Clear
Developed by Alistair Cockburn
Used by small teams (2-8 people) and
based on the following 3 core principles
Frequent delivery: Complete features and
deliver for pilot
Reflective improvement: Think about what is
not working and fix it (process or code)
Osmotic communication: Entire team is co-
located, everybody has the option of
participating or ignoring
7/28/2014

Agile Methodologies: Feature Driven
Development
 Developed by Jeff DeLuca with contributions
from a number of others
 Short phases that are completed “per feature”
 8 principles of FDD
Domain Object modeling to understand the domain
Developing by feature
Class “ownership”
Feature teams
Inspection
Regular builds
Configuration management
Visibility of reports (tracking and reporting)
7/28/2014

Agile methodologies: Dynamic Systems
Development Method
Iterative and incremental methodology
Time and resources are fixed; features are
variable
Requirements categorized and prioritized
according to the MoSCoW criteria
M: Must have
S: Should have
C: Could have
W: Wont have this time
7/28/2014

Agile methodologies: Extreme
Programming (XP)
 Emphasizes engineering practices to frequently
deliver high quality products
 Four basic values:
Simplicity
Communication
Feedback
Courage
 Recognized by practices like …
Test-driven development
Pair programming
Continuous integration and re-factoring
Coding standards
7/28/2014

Rational Unified Process
Based on the software product by Rational
Software – later acquired by IBM
6 Best practices
Develop iteratively, risk as the primary driver
Manage requirements
Employ components-based architecture
Model software visually
Continuously verify quality
Control changes

Rational Unified Process (continued)
 Four project lifecycle phases
 Inception
 Elaboration
 Construction
 Transition
 Six engineering disciplines
 Business modeling, Requirements, Analysis and Design,
Implementation, Test, Deployment
 Three supporting disciplines
 Environment, Configuration and Change management, Project
management

Rational Unified Process (Continued)

Scrum
Founded by Ken Schwaber, Mike Beedle,
Jeff Sutherland and others
Well known for simple, robust
management framework
Scrum is a rugby term where the team
huddles together before starting play
Very popular in the Agile community
7/28/2014

Scrum Cheat sheet
7/28/2014 Bhawani Nandan Prasad - IT process expert

Scrum Basics
Backlog
Item
Priority
Product
Owner
Inputs from Customers,
Team, Execs, Support,
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
Once agreed, Sprint end date &
deliverables do NOT change
7/28/2014

Product Owner
 Responsible for managing Project RoI and risk
 Responsible for consolidating all inputs into what
the team should produce and turn it into a
prioritized “backlog”
 Participate actively in the sprint planning and
sprint review meetings and is available to the
team throughout the sprint
 Determines release plan and communicates to
everybody
7/28/2014

Product Backlog
Backlog
Item
Priority
Product
Owner
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
7/28/2014

Product backlog
 List of everything that could ever be of value to
the business for the team to produce.
 Defined in terms of “epics” and “user stories”
 Ranked in order of priority
Priority is a function of business value and risk
 Product owner can make any changes they want
before start of a Sprint / Sprint Planning meeting
It can be addition of new items, changing or
removing or existing items or re-ordering them
 Ideally for 2 sprints items should be well defined
7/28/2014

Example of Product Backlog
Description Size
Utility to mark all positions to market
at end of trading day 20
Report on outstanding positions for
SEBI filing 10
On-the-fly introduction of securities
into intra-day trading 5
Upgrade server platform to JRE 1.6
5
Fix intermittent problem with index
window flickering (Defect
No.0002413)
10
Integrate Mark-to-market utility with
trading system (execute every hour) 20
 List of requirements in
descending order of
priority
 Can be …
Functional or non-
functional
Technical upgrades
Significant bug-fixes
7/28/2014

User Stories and Epics
 Epic: High-level theme that combines a set of
planned features or requirements Examples …
Scalability improvements to handle processing rate of
100 transactions per second
Usability improvements
 User Story: A short description of a planned
feature or requirement. Examples …
Modify server code to support multi-threading
Reduce the size of packets sent over
Reduce number of clicks to checkout to 5
Support Section 508 recommendations
7/28/2014

Epics and user stories
Can include any or all of the following
New features
Modification or Deletion of existing features
Bug-fixes to existing software
Internal clean-up tasks like code re-factoring,
support for new technologies, etc.
Should all result in “adding value” to the
customer!
7/28/2014

User Stories
Should be small
Typically no more than 40 man hours of effort
Should be deliverable as a unit (de-
coupled or loosely coupled)
Should be described in as much detail as
is necessary to “validate successful
completion”
May contain child stories or tasks
7/28/2014

Writing good user stories
 Example templates
 As a [role], I can [feature] so that [reason]
 E.g. As a account holder, I can check my balances online so that I can
maintain daily balance
 Use 3”X5” index cards (ensure that you don’t write too much)
 Make it testable by writing acceptance criteria
 Given [context] <and/or [some more context]> When [event] Then
[outcome] <and/or [another outcome]
 E.g. Given account balance is negative and no direct deposit is scheduled
on the day when the account holder tries to withdraw money then the bank
will deny the request and send the account holder an alert
 Connect the dots by thinking of all possible scenarios
 More references:
 http://www.agilemodeling.com/artifacts/userStory.htm

How to split storiesRef: Bill Wake’s “20 Ways to Split Stories”: http://xp123.com/xplor/xp0512/index.shtml
The Big Picture
 • Research vs. Action
 If a story is too hard, one split is to spend some time researching solutions to it.
 • Spike vs. Implementation
 You can buy learning for the price of a spike (a focused, hands-on experiment on some
aspect of the system).
 A spike might last an hour, or a day, rarely longer.
 • Main Flow vs. Alternate Flows
 (Use case terminology.) The main flow - the basic happy path - is usually the one with the
most value.
 • Manual vs. Automated
 If there's a manual process in place, it's easier to just use that for a while before throwing it
away.
 • Buy vs. Build
 Sometimes, what you want already exists, and you can just buy it. For example, you might
find a custom widget that costs a few hundred dollars. It might cost you many times that to
develop yourself.
 Other times, the "off-the-shelf" solution is a poor match for your reality, and the time you
spent customizing it might have been better spent developing your own solution.
7/28/2014

How to split stories
User Experience
 Batch vs. Online
 A batch system doesn't have to interact directly with the user.
 Single User vs. Multi-User
 Keep concurrency, access control issues, etc. in abeyance for
some time.
 API-only vs. User Interface
 It's easier to not have a user interface at all. For example, if
you're testing your ability to connect to another system, the first
cut might settle for a unit test calling the connection objects.
 Generic UI vs. Customer UI
 At one level, you can use basic widgets before you get fancy
with their styles. To go even further, something like Naked
Objects infers a default user interface from a set of objects.
7/28/2014

20 ways to split stories
“Ilities”
 • Static vs. Dynamic
 It's easier to calculate something once than ensure it has the correct value every time its
antecedents change.
 • Ignore errors vs. handle errors
 While it's less work to ignore errors, that doesn't mean you should swallow exceptions.
Rather, the recovery code can be minimized.
 • Transient vs. Persistent
 Let's you get the objects right without the worries about changing the mapping of persisted
data.
 • Low fidelity vs. High fidelity
 You can break some features down by quality of result. E.g., a digital camera could start as a
1-pixel black-and-white camera, then improve along several axes: 9 pixels, 256 pixels,
10,000 pixels; 3-bit color, 12-bit color, 24-bit color; 75% color accuracy, 90% color accuracy,
95% color accuracy." (William Pietri)
 • Small scale vs. large scale
 "A system that works for a few people for moderate data sets is a given. After that, each step
is a new story. Don't forget the load tests!" (William Pietri)
 • Unreliable vs. Reliable
 "Perfect uptime is very expensive. Approach it incrementally, measuring as you go." (William
Pietri)
7/28/2014

Sprints
Backlog
Item
Priority
Product
Owner
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
7/28/2014

Sprints!
 Refers to an “iteration”
Typically 1-4 weeks long
 Produces an enhanced version of the software
All engineering activities (Code, Unit Test, System,
Regression test) must be completed within the Sprint
Should be “near releasable quality”
 A “release” or project contains multiple sprints
As many as is necessary to create substantial “value” to
the customer
7/28/2014

Sprint at a glance
7/28/2014

Sprint Planning Meeting
Backlog
Item
Priority
Product
Owner
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
7/28/2014

Sprint planning meeting
 Goal:
 For the team to make good commitment around what it will
deliver by the end of the Sprint
 What’s a Good Commitment?
 Clearly understood by all
 Shared among team
 Achievable without sacrificing quality
 Achievable without sacrificing “sustainable pace” (heijunka!)
 Attended by Team, Product owner, Scrum Master
 Usually take 1-2 Hrs for each week of Sprint duration
7/28/2014

Sprint Calendar - Example
Mon Tues Wed Thurs Fri
3 4 5 6 7
10
Sprint
Planning
11
First day of
Sprint
12 13 14
17 18 19 20
Last day of
Sprint
21
Review &
Retrospective
24 25 26 27 28
7/28/2014

How Sprint Planning should work
Clarifying questions about stories asked
Determine how many stories can “fit” into
a Sprint
Stories are broken down to tasks and
assigned to individuals
Estimates may be modified if necessary
Tip: Some pre-preparation (story-
grooming) helps make the meeting short
7/28/2014

Sprint backlog (planning template)
Story Task Owner Estimate
Utility to mark all positions to
market at end of trading day
Generate and test query to get
open positions
Sanjay 2
Determine formula for M2M
based on regulations
Shreya 4
Call web service to custodial
services for margin calls
Kapil 8
Email notifications to account
owners about margin position
Manish 2
Write and execute unit tests Sanjay 8
Test story end-to-end Murali 16
Upgrade server to JRE 1.6 Changes to the build system
and installer
Larry 8
Try out latest patch of JRE 1.6
to make sure it works
Gaurav 16
Limited regression testing Alex 24
7/28/2014

No changes during a sprint!
 Once team has committed, no changes can be
made to the Sprint deliverables
Details will emerge during Sprint, but no new work
or substantially changed work
 No Changes to Sprint Duration either
Sprint ends on planned date whether has
completed its commitment or not
 The Product Owner can …
Change the Product backlog before the next Sprint
Terminate a Sprint (used very rarely)
7/28/2014

The team
Backlog
Item
Priority
Product
Owner
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
7/28/2014

The team!
 Usually 7 + or – 2
 As low as 3 or as high as 15
 Resources can be shared (but ideally should not be)
 Can change between Sprints (but ideally shouldn’t)
 Can be distributed (but better when co-located)
 Is “cross-functional”
 Has all the skills necessary to produce another increment of
“potentially shippable” product
 Is “self-managing”
 Is empowered enough to do whatever it takes to produce the
potentially shippable product, within organizational constraints

Self-Managed Teams Game!

The “Scrum Master” role
Backlog
Item
Priority
Product
Owner
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
7/28/2014

Scrum Master
 What he SHOULD do
Serve the team
 Facilitate the team’s interactions
 Help remove the “blocks” surfaced by the team
Protect the team
 From outside interference or disturbance
 Resolve conflicts internally and externally
Support the team’s use of Scrum
 Organize and facilitate the Scrum rituals
 Audit the compliance with Scrum practices

Scrum Master
 What he SHOULD NOT do
MANAGE the team
DIRECT the team members
Assign tasks
“Drive the team”
Make decisions for the team
Over-rule team members
Direct product strategy or roadmap
Rule on technical issues

Daily Standup Meeting
Backlog
Item
Priority
Product
Owner
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
7/28/2014

Daily standup meetings
 Ground-rules
Every weekday
Whole team attends
Everyone stands
15 minutes or less
 Everyone reports three things
What was able to accomplish since last meeting
What will try to accomplish since by next meeting
What is blocking me
 No discussion, conversation until end of meeting
7/28/2014

Role of testing/QA in Scrum
No separate QA team
Quality is everyone’s responsibility
One team that is responsible for the
product delivery
No more adversarial relationship between Dev
and QA
QA is lot tougher with Agile
Near releasable quality each Sprint is a huge
challenge

Testing best practices
Continuous testing and regression
Automate as much testing as possible
Testers to participate in story elaboration
and estimation
Test early and test often
Close coordination between Developer and
Tester needed
Move towards “test driven development”

Test-Driven Development
Never write a single line of code until there
is a failed automated test
How to do it?
Design: Figure out what you want to do
Test: Write a test to express the design (it
should FAIL)
Implement: Write the code
Test again: Now the test should pass

Test frameworks/tools for TDD
 Xunit
 Junit (http://junit.org)
 cppunit (http://cppunit.sourceforge.net)
 Ruby
 PHPunit
 Jsunit
 TAP (Test Anything Protocol)
 http://testanything.org
 Other test libraries
 e.g. http://opensourcetesting.org
 Use code coverage tools (e.g. Clover, Emma, Cobertura)

Orderly closure of Sprints
Backlog
Item
Priority
Product
Owner
etc.
Team
Sprint Backlog
Sprint Planning
Meeting
Sprint
1-4
weeks
Finished
Deliverables
Sprint
Review
Sprint
Retrospective
Scrum Master
Daily
Standup
7/28/2014

Sprint review
Purpose of Sprint Review
Demo (not just slides) what the team has built
Generate feedback which Product Owner can
incorporate in the product backlog
Decide about “release” of the builds to the
stakeholders (alpha, beta, etc.)
Attended by Product Owner, Managers,
Scrum Master and Team
Usually lasts 2 Hrs
7/28/2014

Sprint “done” criteria
 Software with all features work as defined by the
user story
 All QA testing for completed features is done
with no pending defects
Regression tests pass
 All documentation is completed
 Planned stories demonstrated to the Product
Owner, Customer and other stakeholders

What happens if Done criteria are not
met?
Incomplete stories move to the backlog
and prioritized again before the next Sprint
Retrospective to determine why the plan
commitment was not met
Under no circumstances can you “extend”
a Sprint!

Sprint retrospective
 What it is?
1-2 Hr meeting followed by each Sprint Review/Demo
Attended by Product Owner, Scrum Master, Team
What’s working and what could work better
 Why does Retrospective matter
Accelerate visibility
Accelerate actions to improve
It’s a key mechanism of continuous improvements
(Inspect & Adopt)
7/28/2014

How to make retrospectives effective
Have fun (e.g. bring in food, recognize star
performers from the previous sprint)
One person facilitates (Scrum Master)
Do not stifle opinion – collect all inputs
Arrive at few (2-3) things to change
Follow up!
Assign specific actions
Token penalty if improvements are repeated!
7/28/2014

Engineering best-practices
Continuous integration: “Automated”
nightly builds
Mandatory code reviews (integrated with
code check-ins) and unit tests
Automated testing:
Sanity tests, executed daily
Regression tests, executed per iteration
Test-driven development
7/28/2014

Typical life-cycle in a Scrum World
Repeated as long as it
takes to create a
releasable product
High-level Roadmap
For a Release
7/28/2014

Wrapping up the release!
 Once the work required for the release is done
Final readiness checks for a “release”
 Can be preceded by one or more “hardening”
sprints
No new features added during hardening
Focus on fixing bugs, packaging, regression testing,
performance testing, etc.
Hardening sprints can be split across the release (need
not all be at the end)
Resist temptation to bank on hardening sprints to do
required bug fixes – it quickly turns into waterfall in
disguise
7/28/2014

Release “done” criteria
 Customer acceptance received
 Beta feedback incorporated
 Release documentation (e.g. Release Notes, Read me
First, etc.) is completed
 Non-functional requirements (e.g. Performance,
Usability, etc.) are tested and validated
 Regulatory and compliance requirements are met (e.g.
Section 508, ECCN, License agreements, etc.)
 All planned integrations with other products are tested
and working

Release Planning
 Aims at coming up with a “long-term roadmap”
 What should happen during a release planning?
 Prepare of a release roadmap with “epics” defined at high level
 Estimate of what and how much can be accomplished in a
release
 Identify and tie up dependencies on external factors or events
 Prepare a high-level project plan with milestones
 Mode of release planning
 Usually face-to-face, lasting up to a week
 The entire team need not attend– key representatives should
 Product Owner and optionally other stakeholders can attend
 Advance preparation (understanding epics, priorities,
dependencies, etc.) help this go faster
7/28/2014

Release planning exercise

Managing Scrum Projects
Estimation
Tracking
Challenges
7/28/2014

Estimation
Types of estimation
Top-down
Ask the expert!
Analogous
Parametric
Bottom-up (Detailed)
Estimation is not necessarily more difficult
in Scrum, it is just that Scrum exposes bad
estimates quicker!
7/28/2014

Principles in estimating
Team (people who are actually working on
the stories) has the final word
Team can ask clarifying questions
Achieving precision in estimation is not so
important
Being “predictable” is!
7/28/2014

Ideal days
Number of days a story should take in
“ideal” circumstances
This allows for expected distractions (e.g.
normal worker only puts in 5 hours of
actual work in an 8 hour day)
Conversion of ideal days to actual days
depends upon …
Whether the resource is novice or experienced
How much distraction should be accounted for
7/28/2014

Story points
Story points
An analogous estimation technique
Establish a benchmark story that can be
considered as 1 story point
Estimate other stories “relative to” the
benchmark
Story points assigned are usually in modified
Fibonacci series: 1, 2, 3, 5, 8, 13, 20
Correlation of story points to man hours is
based on past experience
7/28/2014

Estimation game – Planning poker!
See www.planningpoker.com for details
and online version of the game
7/28/2014

Tracking Agile Projects
 Team should ideally manage progress – should
NOT be micro-managed
 Tracking mechanisms
Daily stand-up meetings
Scrum-of-Scrums
Burn-down chart (automated or manual)
Progress chart
7/28/2014

Burn-down chart
7/28/2014

Burn-down basics
Tracks number of hours (or days) worth of
work remaining in the Sprint
Should be a downward sloping curve,
hitting zero before the last day of a Sprint
Requires data to be updated daily (could
be done during or after Daily Stand-up
meetings)
7/28/2014

Progress chart
7/28/2014

Progress Chart
Set of post-it notes (one per story) that
move from Planned to In progress to
Completed
Posted on a board at a place where it is
visible to the entire team
Clearly define criteria for “Done” or
“Completed”
Primitive, but highly effective!
7/28/2014

Agile Metrics
 Velocity: Functionality delivered per iteration (story
points or number of stories or another measure)
 Defects per iteration (Absolute number or weighted
average)
 Other measures
 Standards violation per sprint
 Level of automation (% of automatable tests)
 Number of tests developed per story
 Stories planned/Stories delivered
 Scrum Maturity Model
 Use metrics to target the behavior you want to
encourage/eliminate!
7/28/2014

Stakeholders
 Anybody who “can impact” or “can be impacted
by” the project (for good or bad)
 Common stakeholders
 Managers (various levels!)
 Scrum Master
 Team
 Product Owner
 Customer and/or sponsor
 End user
 Subject Matter Experts
 Other political/vested interests
 Chicken or pig?
7/28/2014

Communication guidelines
Type of Stakeholder Opportunities to engage
Who only want to ensure smooth
progress (e.g. Managers)
Involve in demos
Give access to dashboards and
metrics
Who are “result-oriented” (e.g.
customer, end-user)
Involve in demos, early
acceptance testing
Customize visibility
Give decision authority!
Who are direct contributors (e.g.
Team)
Involve throughout the project
(transparency and Trust)
Who are observers (e.g. SME’s) Involve in demos
Ask for opinions, participation7/28/2014

Common (scrum-specific) risks
 Integration challenges on complex inter-
dependent projects
Daily/Periodic integrations
Call out dependencies early and plan
 Tendency to delay bug-fixes in a rush to
complete features
Use periodic “hardening” iterations
Define and follow “done” criteria for iterations
 Blocking issues derailing Sprints
Proactive tracking of blocking issues
Scrum Master to get Management attention
7/28/2014

Common (scrum-specific) risks
 Team follows Scrum principles, but Product Owner, Management,
Customer don’t!
 Educate everybody about Scrum (basic principles)
 Find a way to meet everybody’s needs
 Activities requiring lot of R&D/Design would never be done in one
Sprint
 Find a way to break into modular tasks/stories
 Make use of “Spike” stories
 Previously deployed software breaks and customer
escalations block new work
 Reserve time for “Support” activities
 Make a “Sustaining Engineering” team

Let us put it into practice!
Agile Simulation!
7/28/2014

Tools used in Agile project management
 In principle, Agile likes simple, easy-to-use tools. Agile
projects can very well be managed using post-its,
spreadsheets, etc.
 Some of the other tools in vogue are …
 Rally (http://www.rallydev.com/)
 Mingle (http://studios.thoughtworks.com/mingle-agile-project-
management)
 Scrum Desk (http://www.scrumdesk.com)
 VersionOne (http://www.versionone.com/)
 Freeware tools
 X-planner (http://xplanner.org/index.html) (open-source)
 Sprintr (http://www.sprintr.com)
7/28/2014

“Managing” Agile projects
 What do Managers do on Scrum projects?
 A project manager or coordinator operating in a “matrix” environment
can be trained to morph into a Scrum Master
 Line managers (who have reporting authority) should …
 Provide “Functional” and/or “Technical” expertise – help the team solve
problems
 Help the team understand the larger context of the project
 “Protect” the team during prioritization battles
 Foster the right “culture” in the team – team metrics over individual
 Represent the team at external forums
 Be risk managers for the projects
 Administer rewards and recognition!
 Focus on “What” to do (portfolio decisions) rather than “How”
 Additional reading: http://www.infoq.com/articles/scrum-
management-deemer
7/28/2014

Applying Agile on Maintenance and
Enhancement projects
 Ask yourself these questions:
 Can you define a clear, prioritized backlog?
 Can you estimate your “defect fixes” with reasonable accuracy?
 If the answers to both is YES, then you can apply Agile
techniques
 Provide a larger buffer for uncertainties
 References:
 http://www.linkedin.com/answers/product-management/product-
design/product-design/PRM_PDS_PDG/166734-863751
 http://agileworld.blogspot.com/2007/04/applying-agilescrum-
practices-in.html

Agile in RFP responses
 Advantages you can highlight to your customer:
Customers get early visibility (potentially an alpha
drop every few weeks!)
Customers get nearly infinite capacity to change
requirements (in between Sprints)
 But you must forewarn them that:
You expect much more involvement from the
“business” (directly or through Product Owner)
They cannot expect instant gratification on change
requests
The team must be allowed to “self-manage”

Agile in Fixed Price projects
 In the event of a change in scope, you could
either –
Add Sprints to your release/project (additional cost)
Trade one feature for another (re-prioritize) at no cost
to the customer
 In a nutshell, Change Management process
would work the same way as before
But you would get much more flexibility to absorb
change

Agile in Distributed Teams
Same “best practices” that work on all
distributed teams
Cultural exchange/sensitivity
Team pages with pictures
Invest in collaboration tools (Webex,
Livemeetings, Skype, Video conferences, etc.)
Schedule Scrum rituals to suit everybody’s
timings – if necessary, share the pain!

Parallels of Agile with Lean
5 Principles of Lean
Specify the value
Identify the value stream (what creates value)
Create Flow
Manage using “pull” based systems (Kanban)
Strive to achieve perfection

Basic tenets of Lean
 Reduce waste/re-work, by …
Avoiding production of items not needed
Keeping minimum inventory
Preventing unnecessary processing
Preventing unnecessary movement of people
Preventing unnecessary transport of goods
Reducing waiting time
Not producing anything that does not meet a customer
need

Kanban v/s Agile
 Kanban is actually a system for process control
Invented by Taichi Ohno at Toyota (>50 years ago)
 Principles of Kanban:
It is a “pull based system”
There is only a small “buffer” in front of each
processing step
The system is continuously improved by “Kaizen”
 Some teams use a Kanban system on
software projects to maintain a constant flow of
items through the software life-cycle

Kanban v/s Agile
Kanban emphasizes “flow” rather than
iterations
Work done immediately reduces “induced
waste”
Focus on time and reducing delays
Time from getting information till we need it
(e.g. requirements)
Time from making an error to fix it
Time from needing information and getting it

Cycle time
Request
0.5
Approve
0.1
Requirements
60
Signoff
1
Analyze
40
Design
40
Review
2
Code
80
Test
40
Deploy
3
80 8080 80
40
80
808080
20% rework65% rework
Actual time spent = 0.5+0.1+60+1+40+40+2+(0.2*(40+2))+80+40+0.65*(80+40)+3 = 353
Elapsed time = 353+80+80+80+80+80+2*40+80+2*80+80 = 1173
Process cycle efficiency = 353/1173 = 30%
7/28/2014

Kanban Board
Approved Under
review
Ready
For
Dev
Analysis
Ready
For
Design
Design
Ready
For
Code
Coding
Ready
For
Test
Test Ready
For
Deploy
Deploy
7/28/2014

Agile certifications: Certified Scrum
Master
 Scrum Alliance (www.scrumalliance.org): Offers Certified
Scrum Master and Certified Scrum Product Owner
 Requirements
 Attend a Scrum training given by a “Certified Scrum Trainer”
 Costs between $500-$1000
 Scrum Trainer submits application
 Pass an online evaluation
 Renew it every 2 years
 For more details see:
http://www.scrumalliance.org/pages/faq_training_and_ce
rtification

Agile certifications: Professional
Scrum Master
Launched by Ken Schwaber
www.scrum.org
Professional Scrum Master (2 levels)
Also Professional Scrum Product Owner (2
levels) and Professional Scrum Developer
Open to all (pass assessments at 85%
passing mark)
Scrum.org also offers trainings
$100 for Level-1 and $500 for Level-2

Agile certifications: PMI – Agile
Certified Professional
 Offered by Project Management Institute (www.pmi.org)
 Costs $435 (members) and $495 (non-members)
 Membership $129
 Requirements
 1 year of General Project Management experience and 8 months
of Agile Project management experience
 21 hours training required
 Assessment (100 multiple choice questions)

Important links
Scrum Alliance
www.scrumalliance.org
Ken Schwaber’s site on Scrum
www.scrum.org
Agile references
www.agilealliance.org
www.agilebok.org
http://agile.vc.pmi.org/Public/Home.aspx
7/28/2014

To sum it up!
Advantages of Agile
 Helps to reduce “waste”
by always focusing on
highest priority items
 Enforces disciplined
change management,
while greatly enhancing
ability to absorb changes
 Enhances “visibility” into
the development process
and improves productivity
Disadvantages of Agile
 Some teams and some
people will not like it
 Partial or haphazard
implementation of Agile
will makes things worse
than before!
 It will not resolve your
engineering problems –
but it will make it visible
sooner!

Risk Management in Agile
Risk: An “uncertain” event that may impact
an expected outcome for good or bad
Agile has in-built risk management
mechanism because it will make things
visible sooner!
Facets of risk events
Probability
Impact
Response
7/28/2014

Transforming to Agile
 Must
 If Waterfall is working for you, do not use Scrum – Ken
Schwaber!
 Understand what you want to get out of Agile and measure what
you are getting
 Get customer and senior management buy-in
 Good to do
 Education for key roles: Scrum masters, Product Owners and
also for General Managers
 Get a coach/mentor, join communities
 Some people/teams will never be comfortable – do not force
them!

Sample risk register
7/28/2014

Managing large/integrated teams
Multiple teams working on the same
product or application
Split in a way that each is at least
somewhat de-coupled from each other
Each team should be cross-functional
Manage dependencies and integrations
carefully
Scrum of Scrums
Product coordination teams

Scrum-of-scrums
Useful in situations where multiple scrum
teams are working for a single or
integrated set of projects
Representative from each Scrum attends
SoS focuses on the “inter-dependencies”
SoS need not be daily
Frequency depends on the nature of the
dependencies
7/28/2014

Product coordination team
Identify few (2 or 3) people whose job is to
coordinate across teams
Opportunities to coordinate
High priority epics or stories that require
multiple teams to work on
Technical dependencies
Ensuring consistency and uniformity of design
Coordination may be a full-time or part-time role

Which methodology is best?
 RUP is a pretty good framework for enterprise, large
scale projects with a high level of complexity and inter-
dependencies
 if you can afford to buy their tools 
 FDD is good if you are big on OO methodology
 Crystal Clear is good if you have co-location
 XP is good if your challenge is engineering practices
 Scrum is good for a robust management framework –
and is by far the most popular!
 There isn’t a right or wrong methodology – use one that
works for you!

Thank You
bhawani_nandan@yahoo.com
Certified scrum Master
Product Owner
7/28/2014

Software development with scrum methodology bhawani nandan prasad

More Related Content

What's hot (20)

Viewers also liked (9)

Similar to Software development with scrum methodology bhawani nandan prasad (20)

More from Bhawani N Prasad (20)

Recently uploaded (20)

Software development with scrum methodology bhawani nandan prasad