Tayfun BilselFounder & CTO,  Rabbitsoft14 April 2011

Waterfall vs Agile approach, Scrum Framework and best practices in software development

www.rabbitsoft.com

www.clinked.net

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?

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

Empirical (based on observation)orDefined?

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

• 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

Why Scrum?

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

DARKDesire - 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 have2. 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

round4. 3 rounds can be done until estimators converge, if not then, either majority or average

points can be used as the final estimate

Online versionhttp://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 Timeo attend to a conferenceo 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. Stop3. Re-plan4. Wait for the iteration to end5. Start again

Tools

Pivotal TrackerVersionOneJira - Green HopperScrumWorks ProRallyHansoftTFS 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)