Demystifying Agile/Scrum

Agile:

Literal meaning of agile is moving quickly and lightly.

Agile approaches are typically used in software development to help businesses respond to unpredictability.

Scrum:

Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each.

Scrum uses fixed-length iterations, called Sprints, which are typically 1-2 weeks long (never more than 30 days). Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration.

Scrum is usually associated with object-oriented software development.

Waterfall model

Scrum Roles

Product Owner

·         Single person responsible for maximizing the return on investment (ROI) of the development effort

·         Responsible for product vision

·         Constantly re-prioritizes the Product Backlog, adjusting any longterm expectations such as release plans

·         Final arbiter of requirements questions

·         Accepts or rejects each product increment

·         Decides whether to ship

·         Decides whether to continue development

·         Considers stakeholder interests

·         May contribute as a team member

Scrum Development Team

·         Cross-functional (e.g., includes members with testing skills, and often others not traditionally called developers: business analysts, domain experts, etc.) Self-organizing / self-managing, without externally assigned roles

·         Negotiates commitments with the Product Owner, one Sprint at a time

·         Has autonomy regarding how to reach commitments

·         Intensely collaborative

·         Most successful when located in one team room, particularly for the first few Sprints

·         Most successful with long-term, full-time membership. Scrum moves work to a flexible learning team and avoids moving people or splitting them between teams.

·         3-9 members (originally 7 ± 2 members)

It implies teams have to work closely, everyone should be aware where the other person is – assist, grow & deliver.

Scrum Master

·         Facilitates the Scrum process

·         Helps resolve impediments

·         Creates an environment conducive to team self-organization

·         Captures empirical data to adjust forecasts

·         Shields the team from external interference and distractions to keep it in group flow

·         Enforces timeboxes

·         Keeps Scrum artifacts visible

·         Promotes improved engineering practices

·         Has no management authority over the team (anyone with authority over the team is by definition not its ScrumMaster)

Scrum Meetings

All Scrum Meetings are facilitated by the ScrumMaster, who has no decision-making authority at these meetings.

Sprint Planning Meeting

At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to negotiate which Product Backlog Items they will attempt to convert to working product during the Sprint. The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement without accruing technical debt. The team “pulls” work from the Product Backlog to the Sprint Backlog.

When teams are given complex work that has inherent uncertainty, they must work together to intuitively gauge their capacity to commit to items, while learning from previous Sprints. Planning their hourly capacity and comparing their estimates to actuals makes the team pretend to be precise and reduces ownership of their commitments.

Until a team has learned how to complete a potentially-shippable product increment each Sprint, it should reduce the amount of functionality it commits to. Failure to change old habits leads to technical debt and eventual design death. If the top of the Product Backlog has not been refined, a major portion of the planning meeting should be spent doing this.

Toward the end of the Sprint Planning Meeting, the team breaks the selected items into an initial list of Sprint Tasks, and makes a final commitment to do the work.

The maximum allotted time (a.k.a. timebox) for planning a 30-day Sprint is eight hours, reduced proportionally for a shorter Sprint.

Daily Scrum and Sprint Execution

Every day at the same time and place, the Scrum Development Team members spend a total of 15 minutes reporting to each other in a standup meeting. Each team member summarizes what he did the previous day, what he will do today, and what impediments he faces. Topics that require additional attention may be discussed by whomever is interested after every team member has reported.

The team may find it useful to maintain a current Sprint Task List, a Sprint Burndown Chart, and an Impediments List. During Sprint execution it is common to discover additional tasks necessary to achieve the Sprint goals. Impediments caused by issues beyond the team’s control are considered organizational impediments.

It is almost always useful for the Product Owner to attend the Daily Scrum. But when any attendee also happens to be the team’s boss, the invisible gun effect hampers self-organization and emergent leadership. People lacking real experience of team self-organization won’t see this problem, just as fish are unaware of water. Conversely, a team that needs additional expertise in product requirements will benefit from increased Product Owner involvement, including Daily Scrum attendance.

The Daily Scrum is intended to disrupt old habits of working separately. Members should remain vigilant for signs of the old approach. For example, looking only at the ScrumMaster when speaking is one symptom that the team hasn’t learned to operate as a self-organizing entity.