Slideshare.net (beta)

 
Post: 
Myspace Hi5 Friendster Xanga LiveJournal Facebook Blogger Tagged Typepad Freewebs BlackPlanet gigya icons

All comments

Add a comment on Slide 1

If you have a SlideShare account, login to comment; else you can comment as a guest


Showing 1-50 of 5 (more)

Scrum

From jgrahamthomas, 2 months ago

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

619 views  |  0 comments  |  5 favorites  |  28 downloads  |  9 embeds (Stats)
 

Groups/Events

Not added to any group/event

 
 

Privacy InfoNew!

This slideshow is Public

 
Embed in your blog
Embed (wordpress.com)

Slideshow Statistics
Total Views: 619
on Slideshare: 488
from embeds: 131* * Views from embeds since 21 Aug, 07

Slideshow transcript

Slide 1: SCRUM Jeremy Thomas Development Manager Consumer Media active.com

Slide 2: SCRUM is a collaborative approach to building software. Testers, engineers, product developers and even IT work together from start to finish.

Slide 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.

Slide 4: chaos = changing market demands, evolving requirements, miscommunication, misinterpretation.

Slide 5: waterfall and chaos don’t get along.

Slide 6: waterfall wants order, predictability, known outcomes, benchmarks. Waterfall wants to predict the future.

Slide 7: and because we’re so in touch with the future, we can anticipate how users will use the system six months from now.

Slide 8: so let’s put together a 300 page requirements document with all of the functionality we can think of.

Slide 9: then we’ll throw it at the code monkeys, I mean engineering team, and project managers to build our system for us.

Slide 10: the project managers, with their hierarchical command and control structure, will divide the work among disparate groups.

Slide 11: these groups will work independently, reporting status back to the command and control center once a week or so.

Slide 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.

Slide 13: so they’ll work 80 hour weeks for the next month to fix that little problem.

Slide 14: oh yeah, and they’ll have to push out the project deadline by two months to compensate.

Slide 15: the system will finally be integrated, speaking one universal language, and the engineers will have a celebratory beer.

Slide 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.

Slide 17: because the system won’t look like what they envisioned five months ago when they predicted the future.

Slide 18: and between now and then things have changed, the business’ customers have demanded new features.

Slide 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.

Slide 20: concessions will be made, and the company will deliver a product that nobody wants to use.

Slide 21: and they’ll do this after being two months late and over budget.

Slide 22: or we could use SCRUM.

Slide 23: SCRUM divides projects into manageable sprints.

Slide 24: a sprint is a two to four week period where something of business value is delivered at the end.

Slide 25: the project team is involved from start to finish. Design, testing and coding can all happen on the same day.

Slide 26: testers, developers, marketers and product managers intermingle becoming one big happy family.

Slide 27: communication is constant.

Slide 28: each day a 15 to 30 minute SCRUM meeting is held. Managers can watch, but they cannot talk.

Slide 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?

Slide 30: inter-departmental collaboration + frequent communication = transparency.

Slide 31: transparency = reduced risk, better product.

Slide 32: requirements are delivered not in 300 page documents but as user stories.

Slide 33: user stories describe user experiences and have enough detail for SCRUM Masters to estimate effort size). (

Slide 34: A sample user story is “A consumer can upload and play videos on the website”

Slide 35: A sample user story is “A consumer can upload and play videos on the website”

Slide 36: The SCRUM team then adds detail to the user story during the course of the project and clarifies ambiguity.

Slide 37: User stories emphasize verbal communication.

Slide 38: “Entrée comes with choice of soup or salad and bread”.

Slide 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

Slide 40: The SCRUM Master has Authority over what details are permissible. His goal is to deliver at the end of the Sprint.

Slide 41: He has no friends . He makes the business prioritize. He makes the developers compromise.

Slide 42: At the end of the sprint the teamshows off what they’ve done to the rest of the business.

Slide 43: The stakeholders already knew what they were getting and are happy.

Slide 44: The developers are happy too because they built something the business can use.

Slide 45: And everybody goes home to rest. Well at least until the next sprint begins...