Your SlideShare is downloading. ×
  • Like
Scrum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply
Published

Overview of why SCRUM can add value to the development process.

Overview of why SCRUM can add value to the development process.

Published in Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,254
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
429
Comments
0
Likes
18

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

Transcript

  • 1. SCRUM Jeremy Thomas Development Manager Consumer Media active.com
  • 2.
    • SCRUM is a collaborative approach to building software. Testers, engineers, product developers and even IT work together from start to finish.
  • 3.
    • SCRUM acknowledges that chaos is present in most system development projects. SCRUM maximizes the amount of chaos a project can embrace and still be successful through collaboration .
  • 4.
    • chaos = changing market demands, evolving requirements, miscommunication, misinterpretation.
  • 5.
    • waterfall and chaos don’t get along.
  • 6.
    • waterfall wants order, predictability, known outcomes, benchmarks. Waterfall wants to predict the future .
  • 7.
    • and because we’re so in touch with the future, we can anticipate how users will use the system six months from now.
  • 8.
    • so let’s put together a 300 page requirements document with all of the functionality we can think of.
  • 9.
    • then we’ll throw it at the code monkeys, I mean engineering team, and project managers to build our system for us.
  • 10.
    • the project managers, with their hierarchical command and control structure, will divide the work among disparate groups.
  • 11.
    • these groups will work independently , reporting status back to the command and control center once a week or so.
  • 12.
    • and three months later, when it comes time for the modules these groups built to talk to each other, they’ll find they speak different languages and can’t communicate .
  • 13.
    • so they’ll work 80 hour weeks for the next month to fix that little problem.
  • 14.
    • oh yeah, and they’ll have to push out the project deadline by two months to compensate.
  • 15.
    • the system will finally be integrated, speaking one universal language, and the engineers will have a celebratory beer .
  • 16.
    • but then on Monday, when the business takes its first peek at the new system, they’ll organize an emergency meeting with the team leads.
  • 17.
    • because the system won’t look like what they envisioned five months ago when they predicted the future.
  • 18.
    • and between now and then things have changed , the business’ customers have demanded new features.
  • 19.
    • at the meeting the project managers and engineers will defend their positions , citing section numbers in the 300 page requirements document and saying “scope creep” a lot.
  • 20.
    • concessions will be made, and the company will deliver a product that nobody wants to use.
  • 21.
    • and they’ll do this after being two months late and over budget .
  • 22.
    • or we could use SCRUM .
  • 23.
    • SCRUM divides projects into manageable sprints .
  • 24.
    • a sprint is a two to four week period where something of business value is delivered at the end.
  • 25.
    • the project team is involved from start to finish. Design, testing and coding can all happen on the same day .
  • 26.
    • testers, developers, marketers and product managers intermingle becoming one big happy family.
  • 27.
    • communication is constant.
  • 28.
    • each day a 15 to 30 minute SCRUM meeting is held. Managers can watch, but they cannot talk.
  • 29.
    • during the meeting, each team member answers three questions :
      • what did I do since the last SCRUM meeting?
      • what has impeded my work?
      • what will I do before the next SCRUM meeting?
  • 30.
    • inter-departmental collaboration
    • + frequent communication
    • = transparency .
  • 31.
    • transparency = reduced risk, better product.
  • 32.
    • requirements are delivered not in 300 page documents but as user stories .
  • 33.
    • user stories describe user experiences and have enough detail for SCRUM Masters to estimate effort ( size ).
  • 34.
    • A sample user story is “A consumer can upload and play videos on the website”
  • 35.
    • A sample user story is “A consumer can upload and play videos on the website”
  • 36.
    • The SCRUM team then adds detail to the user story during the course of the project and clarifies ambiguity .
  • 37.
    • User stories emphasize verbal communication .
  • 38.
    • “ Entrée comes with choice of soup or salad and bread”.
  • 39.
    • Does this mean:
    • Soup or (salad and bread)
    • (Soup or salad) and bread
    • http://www.mountaingoatsoftware.com/article_view/27-advantages-of-user-stories-for-requirements
  • 40.
    • The SCRUM Master has Authority over what details are permissible. His goal is to deliver at the end of the Sprint.
  • 41.
    • He has no friends . He makes the business prioritize. He makes the developers compromise.
  • 42.
    • At the end of the sprint the team shows off what they’ve done to the rest of the business.
  • 43.
    • The stakeholders already knew what they were getting and are happy .
  • 44.
    • The developers are happy too because they built something the business can use.
  • 45.
    • And everybody goes home to rest . Well at least until the next sprint begins...
  • 46.