Your SlideShare is downloading. ×
0
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Waterfall vs agile approach  scrum framework and best practices in software development
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Waterfall vs agile approach scrum framework and best practices in software development

24,303

Published on

Waterfall vs agile approach scrum framework and best practices in software development

Waterfall vs agile approach scrum framework and best practices in software development

Published in: Technology, Business
4 Comments
5 Likes
Statistics
Notes
  • Can anyone tell me how you fit Agile into a commercial contract where specific requirements are required by a specific date for a specific cost? These are technically complex deliverables not simple web page or database products but involve custom hardware and software with specific performance requirements. Because legally binding commitments have been made you cannot just ignore requirements and say so sorry. You have to schedule milestones for reporting and progress payments, and probably do not have tight customer involvement (especially day to day or week to week -- they are geographically separated from us, most likely in another country) once the requirements have been detailed up front.

    From a project management perspective I have a very hard time seeing how Agile would work for me. It seems that it is too idealistic in a technical development environment with commercial, fixed-price contracts.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Excellent overview! Thank you!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • very good
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Excellent overview. Nice work.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
24,303
On Slideshare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
608
Comments
4
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • In February 2001, 17 software developers met to discuss lightweight development methods. They published the  Manifesto for Agile Software Development  to define the approach now known as agile software development. Some of the manifesto's authors formed the Agile Alliance
  • In large organisations Product Owner may report to Product Manager
  • Transcript

    • 1. Tayfun Bilsel Founder & CTO,  Rabbitsoft 14 April 2011 Waterfall vs Agile approach, Scrum Framework and best practices in software development www.rabbitsoft.com www.clinked.net
    • 2. 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?
    • 3. Common Problems in Traditional Project Management
        • Late Delivery
        • Over budget
        • Wrong thing is delivered
    • 4. 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
    • 5. Agile Approach
    • 6. Waterfall vs Agile
    • 7. Be Agile
      • Outline requirement rather than detailed requirements/solution/plan
      • Baseline Plan (3-9 months) vs Commitment Plan
    • 8. Where does your project fit? Source:  http://www.noop.nl/2008/08/simple-vs-complicated-vs-complex-vs-chaotic.html Empirical (based on observation) or Defined?
    • 9. 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/
    • 10. 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...
    • 11. 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.
    • 12. 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!
    • 13. 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
    • 14. Common Problem4
      • Stick with the plan and you will be successful!
      • - Iterative development is well planned but planned in a different way to waterfall
    • 15. 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
    • 16. Multi-level Planning
      • Release Plan -> Typically every 3 to 6 months
      • Sprint Plan -> Typically every 2 to 4 weeks
      • Daily Plan -> Daily
    • 17. 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 
    • 18. Self Organising Team
      • Team must
        • take initiative
        • focus on solutions and co-operate
        • self directed, motivated, multi-skilled
      • DARK
      • Desire - Authority - Responsibility - Knowledge
    • 19. 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
    • 20. 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
    • 21. 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
    • 22. 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!
    • 23. 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
    • 24. 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.
    • 25. Planning Poker
        • Product Owner reads the user story and answer any questions that the estimators have
        • All cards are simultaneously turned over and shown so that all participants can see each estimate.
        • If estimates differ, the high and low estimators explain their estimates and do another round
        • 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/
    • 26. 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
    • 27. 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)
    • 28. Action Plan
      • At the end of retrospective meeting
    • 29. Information Radiator Source: Henrik Kniberg: Scrum and XP from the trenches
    • 30. Sprint finished early?
        • Put more stories in  (if not risky)
      • or
        • Gold Time
          • attend to a conference
          • celebrate - go out
      • If this happens regularly - your estimates are wrong!
    • 31. What's "Done" mean?
      • met Sprint Goal?
      • passed acceptance test?
      • met policies and procedures?
      • Then it is done!
    • 32. 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
    • 33. 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
    • 34. Cancelling Sprint
      • Actions required:
        • Retrospective meeting. What went wrong?
        • Stop
        • Re-plan
        • Wait for the iteration to end
        • Start again
    • 35. Tools
      • Pivotal Tracker
      • VersionOne
      • Jira - Green Hopper
      • ScrumWorks Pro
      • Rally
      • Hansoft
      • TFS version 2010 (Team Foundation Server)
    • 36. 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
    • 37. 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”
    • 38.
      • We all succeed or We all fail!
      • "Go the distance as a unit passing the ball back and forth" (Takeuchi, Hirotaka, 1986)

    ×