From whence, Scrum? Pt 2

Post on July 6, 2012 by admin tagged: , , , ,

At the bare bones of developing software (we’ll focus on software, but feel free to replace that with “project” or “business” or “book”), you need to know what to create, some thinking about how you’re going to create it, people to create it, and a physical point in the space/time continuum to actually deliver it and call it done. On top of that, you’ll want some way of managing the use of resources, time, and money, and tracking.

So let’s break that down as simply as possible, between the old-school Waterfall process and the newer Scrum process.

Waterfall

Scrum

Project Need

Requirements

Documents: Business Requirements, Functional Requirements,
Technical Requirements. Be as thorough as possible
upfront.

User Stories added to a Product “Backlog”, which
then get pulled by priority ordered sets into the Release Backlog and
similarly into the Sprint Backlog. Start coarse, and get down to details when
it comes time to focus on that story.

Resources

Different departments for Business, Design, Project
Management, Development Engineering, Operations, Quality Assurance led by
different managers. Cater to Stakeholders. Favor hierarchical chain of
command.

Different roles in small team (9 members or less): Scrum
Master, Product Owner, Developer, Designer, QA.
Favor flat self-organizing team.

Deadline

Driven by business need, months or years away. Favors
planning and adding enough margin to complete large
chunk of work by deadline.

Driven by business need, timeboxed
“sprints” on a regular interval (weekly, bi-weekly, monthly).
Favors smaller chunks of work that can be completed and deployed shorter
intervals.

Status Meetings

Weekly, bi-weekly, monthly for 1-4 hours, sitting. Meant
for those lower on the hierarchy to report progress to those higher up.

Daily, for 15 minutes, standing, at the same time each day. Meant for the team to share status with each other. Done well, these “Daily Stand-ups” are an effective way to share status with no one’s time wasted. In reality, diligence is needed to keep people on track, which is why we invented the Scrumball. DONATE so we can get it made!

Assignments

Manager assigns tasks to staff

Scrum Master is a facilitator, not a boss. Team members
take tasks with guidance from more senior members, and commit to completing
that work within the sprint.

Work/Level of Effort Estimation

Tech managers with project managers determine in advance
how much effort in days/hours all aspects of the project will take. Heavily
favors past experience, static teams. Brittle against unknowns, emergencies,
reprioritizations, and scope creep.

Team members weigh in on estimation, starting with
abstract and relative “story points” early on, when little is known
about the problem/solution/environment. Estimation gets more granular (e.g.
down to hours) only at the beginning of a sprint, for the User Stories to be
worked that sprint. Scope creep is disallowed during a sprint, but with each
new sprint, the backlog of User Stories can be reprioritized, reduced, or
added-to. Favors past experience with the same team to know velocity, however
it only takes another 2-3 sprints to determine any new team or changed team’s
velocity.

Budget

Set in advance, finite.

Set in advance, finite. As work goes on, sprint planning
can be adjusted to handle budget changes over time.

Tracking Tools

Microsoft Project, Excel, Gantt Charts, Word, etc.

Excel, Rally Software, Pivotal Tracker, VersionOne, JIRA Greenhopper, Trello, post-it notes, index cards,

Here’s a visual of the Scrum process, from Wikipedia:

The Scrum Process

The Scrum Process

 

And here’s the video by Hamid Shojaee (Axosoft) that I like to use when evangelizing and on-boarding colleagues or staff with Scrum:

Scrum in Under 10 Minutes