SCRUM

Jeremy Thomas

Development Manager

Consumer Media

active.com

SCRUM is a collaborative approach to building software. Testers, engineers, product developers

and even IT work together from start to finish.

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.

chaos = changing market demands, evolving requirements, miscommunication, misinterpretation.

waterfall and chaos don’t get along.

waterfall wants order, predictability, known outcomes, benchmarks. Waterfall wants to

predict the future.

and because we’re so in touch with the future,

we can anticipate how users will use the system six months from now.

so let’s put together a 300 page requirements

document with all of the functionality we can think of.

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

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

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

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.

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

oh yeah, and they’ll have to push out the

project deadline by two months to compensate.

the system will finally be integrated, speaking one universal language, and the engineers will

have a celebratory beer.

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.

because the system won’t look like what they

envisioned five months ago when they predicted the future.

and between now and then things have

changed, the business’ customers have demanded new features.

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.

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

and they’ll do this after being two months late

and over budget.

or we could use SCRUM.

SCRUM divides projects into manageable

sprints.

a sprint is a two to four week period where

something of business value is delivered at the end.

the project team is involved from start to finish. Design, testing and coding can all happen on the

same day.

testers, developers, marketers and product

managers intermingle becoming one big happy family.

communication is constant.

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

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?

inter-departmental collaboration

+ frequent communication

= transparency.

transparency = reduced risk, better product.

requirements are delivered not in 300 page

documents but as user stories.

user stories describe user experiences and have enough detail for SCRUM Masters to estimate

effort (size).

A sample user story is “A consumer can

upload and play videos on the website”

A sample user story is “A consumer can

upload and play videos on the website”

The SCRUM team then adds detail to the user story during the course of the project and

clarifies ambiguity.

User stories emphasize verbal communication.

“Entrée comes with choice of soup or salad and

bread”.

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

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

He has no friends. He makes the business prioritize. He makes the developers compromise.

At the end of the sprint the team shows off what they’ve done to the rest of the business.

The stakeholders already knew what they were

getting and are happy.

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

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