www.clinked.

net
www.rabbitsoft.com

Waterfall vs Agile approach,

Scrum Framework and best
practices in software development

Tayfun Bilsel
Founder & CTO, Rabbitsoft
14 April 2011

Agenda

Common Problems in Tradition Project Management

Waterfall vs Agile approach
Where does your project fit?
Agile Manifesto
Agilebut syndrome and common problems
Scrum Framework
Best practices?

Common Problems in Traditional

Project Management
Late Delivery
Over budget
Wrong thing is
delivered

Waterfall Approach
- Requirements are known
- Each stage signed off before the next one
commences
- Need extensive documentation as this is the
primary communication medium

Perfect approach if requirements are fully understood and not complex

Agile Approach

Waterfall vs Agile

Be Agile
Outline requirement rather than detailed
requirements/solution/plan
Baseline Plan (3-9 months) vs Commitment Plan

Where does your project fit?

Empirical
(based on observation)
or
Defined?

Source: http://www.noop.nl/2008/08/simple-vs-complicated-vs-complex-vs-chaotic.html

Agile Manifesto
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.
http://www.agilemanifesto.org/

Agilebut and Scrumbut syndrome

We use Agile but.....
- our roadmap is fixed and a year old
- we don't have release plan
- we create detailed plan or architecture
- we manage team tightly
- we don't prioritize features
- we know our requirements, no need to talk to customers
- we don't do planning meetings
but but but...

Common Problem1
No Product Owner or Multiple Product Owners
case1: There is no one in the organisation to prioritize features
or no prioritization methods
case2: The priority set of one Product Owner not match with
the priority set of another Product Owner, as they have different
understanding of what is important.

Common Problem2
Sales/Marketing or Management often make promises to
customers about features or make assumptions that features
will be delivered in a certain time
and this never happens!
and..... they start to blame the development!

Common Problem3
We can do agile without customer feedback!
You may end up building a perfect technical product, with no
value to the customer
Customer is the most valuable team member

Common Problem4
Stick with the plan and you will be successful!
- Iterative development is well planned but planned in a
different way to waterfall

Why Scrum?
Wrapper for existing engineering practices and does
not strictly define principles or how to guidelines
Scalable from single team to entire organisation
Scrum is the lightest of all Agile methods (AUP, Lean,
XP...) with 5 values (Commitment, Focus, Openness,
Respect, Courage), 3 roles
Role to detect and remove anything that gets in the
way of developing and delivering products

Multi-level Planning
Release Plan -> Typically every 3 to 6 months
Sprint Plan -> Typically every 2 to 4 weeks
Daily Plan -> Daily

Scrum Roles
Scrum Team (Size 7 +-2) How - Who - How long - Deliver

Self Organising, cross functional with no pre determined roles

Responsible for self-organising tasks and committing to work
(no one assigns stories or tasks to team members, team must self-organise)
Authority to whatever is needed to meet commitment

Product Owner What - When - Signoff - Vision

Defines the features, writes user stories

Responsible for development schedule and prioritizing Product Backlog
Accepts or rejects stories
DARK - Desire, Authority, Responsibility, Knowledge (Business and Technical)

ScrumMaster (Coach)

Coaches the development team and responsible for productivity

Facilitates Scrum ceremonies
Establishes and enforces Scrum rules and responsible for the success of the process
Shields the team from noise and removes obstacles
Enables close cooperation across all roles

Self Organising Team

Team must
take initiative
focus on solutions and co-operate
self directed, motivated, multi-skilled
DARK
Desire - Authority - Responsibility - Knowledge

Scrum Artefacts
Product Backlog

Continuously evolving queue of stories created by the Product Owner with input from
other stakeholders
Owned and prioritised by Product Owner

Sprint Backlog

The list of tasks required to get the agreed Stories done

ccepts or rejects stories

Burndown Chart

Shows estimated effort remaining

Actual vs ideal progress
Should be publicly visible

Pigs and Chickens

Team, Product Owner and ScrumMaster are knowns as pigs

because they are committed to Sprint
Other stakeholders are known as Chickens as they are not
committed to Sprint Goal

Ceremonies
Daily Scrum Meeting (Everyday @ 9:00) - 15min
Sprint Planning (Last day of Sprint in the afternoon) - 8hours max
(4+4)

Sprint Review (Last day of Sprint @10:00-11:00)

&
Sprint Retrospective (Look back) - 1hour max

Daily Scrums - Syncing pigs

1. What did you do yesterday?
2. What will you do today?
3. What is blocking your work?
Timeboxed to 15 minutes
Problems are solved outside the meeting
Not a reporting session!

Sprint Planning

Timeboxed to 4 hours + 4 hours

Priority items are explained by the product owner
Overall Sprint Goal is agreed
Team estimates and commits to what it can get "done"
The result is an agreed Sprint Backlog

The second part of the meeting, the team decomposes the

sprint backlog items into tasks
Tasks are estimated by the team. They need to be complete
enough for the team to make commitment

Sprint Goal
Collectively, the Scrum team and the product owner define a
sprint goal in the planning meeting
It is usually one sentence descriptive text
The success of the sprint will later be assessed during the
Sprint Review Meeting against the sprint goal.

Planning Poker
1. Product Owner reads the user story and answer any questions that the estimators have
2. All cards are simultaneously turned over and shown so that all participants can see each
estimate.
3. If estimates differ, the high and low estimators explain their estimates and do another
round
4. 3 rounds can be done until estimators converge, if not then, either majority or average
points can be used as the final estimate

Online version
http://www.planningpoker.com/

Sprint Review

Acknowledge achievements
Chickens are invited
Demo of everything that's been done in the Sprint
Product Owner signs off Sprint if tests are ok

Sprint Retrospective
Takes place at the end of the Sprint before the planning
meeting/poker
Short workshop session for team to review lessons learned
and discuss actions for the next Sprint
No chickens involved (except end of release retrospective)

Action Plan
At the end of
retrospective meeting

Information Radiator

Source: Henrik Kniberg: Scrum and XP from the trenches

Sprint finished early?

Put more stories in (if not risky)
or
Gold Time
o attend to a conference
o celebrate - go out
If this happens regularly - your estimates are wrong!

What's "Done" mean?

met Sprint Goal?
passed acceptance test?
met policies and procedures?
Then it is done!

What is Spike?
Spike is a learning activity
Spike something that you don't understand in advance - when
you don't know what exactly it is or how to implement
It is timeboxed - you need to limit how much time you are going
to spend researching

User Stories
Explains Who, What, Why (including functional, non-functional
and non-software features)
Sprint stories should be doable in 1-5 days. If it takes more
than 5 days (compound story), decompose it. For Complex
stories (if no way to split up) - spike it as not enough is known
Product Owner can decompose it with stakeholders
Back of the card- high level acceptance test posed in the form
of questions (not detailed tests) - testers should come up with
these

Cancelling Sprint
Actions required:
1. Retrospective meeting. What went wrong?
2. Stop
3. Re-plan
4. Wait for the iteration to end
5. Start again

Tools
Pivotal Tracker
VersionOne
Jira - Green Hopper
ScrumWorks Pro
Rally
Hansoft
TFS version 2010 (Team Foundation Server)

Best Practices?
Combining approaches:
Agile Management Practices with Scrum Framework +
merging with XP and Lean engineering practices
Scrum can customize up rather than customize down

What does it mean?

Scrum
+
XP

Coding Standards
Pair progamming where possible?
Test Driven Development
Continuous integration
Collective ownership

+
Lean

Eliminate waste (bureaucracy, unclear reqs., unnecessary code, delay, comms)

Amplify Learning (improve process through learning)
Empower the team (Allow team to make decisions)
Build integrity in (System should work the way what the customer expects it to)
Decide as late as possible (make decisions based on the facts not assumptions)
Deliver as fast as possible (Deliver early - Deliver Often)
See the whole - See the software as a whole not just parts->Think big, act small,
fail fast; learn rapidly

We all succeed or We all fail!

"Go the distance as a unit passing the ball back and forth"
(Takeuchi, Hirotaka, 1986)