Agile (Scrum)

33
Agile (SCRUM) Methodology Dominic Cushnan @domcushnan

Transcript of Agile (Scrum)

Agile(SCRUM)

Methodology

Dominic Cushnan@domcushnan

What is Agile Methodology?

➔ Agile methodology is an alternative to traditional project management, typically used in software development. It helps teams respond to unpredictability through incremental, iterative work cadences, known as sprints.

➔ Agile methodologies are an alternative to waterfall, or traditional sequential development.

➔ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

➔ Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

➔ Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

➔ Business people and developers must work together daily throughout the project.

➔ Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

➔ The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Principles behind the Agile Manifesto

Principles behind the Agile Manifesto➔ Working software is the primary measure of progress.

➔ Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

➔ Continuous attention to technical excellence and good design enhances agility.

➔ Simplicity--the art of maximizing the amount of work not done--is essential.

➔ The best architectures, requirements, and designs emerge from self-organizing teams.

➔ At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What is Scrum?➔ It is one of many iterative and incremental software development

agile process for managing product development.

➔ It is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

➔ It is based on multiple small teams working in an intensive and interdependent manner. The teams in the organization work together while constantly focusing on their common interests.

➔ Scrum has three roles: Product Owner, Scrum Master, and Team.

Scrum involves:

➔ Initial appointment of a project manager called the "scrum master."

➔ Definition and prioritization of tasks to be done.

➔ Planning sessions for each task.

➔ Daily meetings among teams.

➔ Identification and evaluation of potential project risks and process pitfalls.

➔ Execution of projects in brief, high-intensity, frequent work sessions.

➔ Reviews of progress and evaluations of completed projects.

➔ Openness to constructive criticism and ideas for improvement.

The Scrum Process

Scrum blends all development activities into each iteration, adapting to discovered realities at fixed intervals.

The Calendar Template

ScrumRolesScrum Roles

consists of a Product Owner, the Scrum Master, and the

Development Team.

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 long term 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 Roles - 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 (a.k.a. the zone)

➔ Enforces timeboxes

➔ Keeps Scrum artifacts visible

➔ Promotes improved engineering practices

Scrum Roles - 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)

ScrumArtifacts

These represent work or value to

provide transparency and opportunities for inspection and

adaptation.

Scrum Artifacts - Product Backlog

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the it, including its content, availability, and ordering.

It lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

Scrum Artifacts - Product Backlog

➔ Force-ranked list of desired functionality

➔ Visible to all stakeholders

➔ Any stakeholder (including the Team) can add items

➔ Constantly re-prioritized by the Product Owner

➔ Items at top are more granular than items at bottom

➔ Maintained during the Backlog Refinement Meeting

Scrum Artifacts - Product Backlog

Product Backlog Item (PBI)➔ Specifies the what more than the how of a customer-centric

feature

➔ Often written in User Story form

➔ Has a product-wide definition of done to prevent technical debt

➔ May have item-specific acceptance criteria

➔ Effort is estimated by the team, ideally in relative units (e.g., story points)

➔ Effort is roughly 2-3 people 2-3 days, or smaller for advanced teams

Scrum Artifacts - Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.

The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

Scrum Artifacts - Sprint Backlog

➔ Consists of committed PBIs negotiated between the team and the Product Owner during the Sprint Planning Meeting

➔ Scope commitment is fixed during Sprint Execution

➔ Initial tasks are identified by the team during Sprint Planning Meeting

➔ Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution

➔ Visible to the team

➔ Referenced during the Daily Scrum Meeting

Scrum Artifacts - Sprint Backlog

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”

Scrum Artifacts - Sprint Backlog

Sprint Backlog is often represented with an “information radiator” such as a physical task board (Scrum Board).

An example of a physical Scrum Board

ScrumEvents

Prescribed events are used in Scrum to

create regularity and to minimize the need for meetings

not defined in Scrum. All events are time-boxed

events, such that every event has a

maximum duration.

Scrum Events - Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Scrum Events - Sprint Planning

Sprint Planning answers the following:

➔ What can be delivered in the Increment resulting from the upcoming Sprint?

➔ How will the work needed to deliver the Increment be achieved?

Sprint Goal

The Sprint Goal is an objective set for the Sprint. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting.

Scrum Events - Sprint Planning

Scrum Events - Daily Scrum/Daily Stand-upThe Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.

This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity.

Scrum Events - Daily Scrum/Daily Stand-upDuring the meeting, the Development Team members explain:

➔ What did I do yesterday that helped the Development Team meet the Sprint Goal?

➔ What will I do today to help the Development Team meet the Sprint Goal?

➔ Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Scrum Events - Daily Scrum/Daily Stand-upThe Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Scrum Events - Sprint Review/DemoA Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

Scrum Events - Sprint Review/DemoThe Sprint Review includes the following elements:

➔ Attendees include the Scrum Team and key stakeholders invited by the Product Owner;

➔ The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

➔ The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;

➔ The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;

➔ The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed);

➔ The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;

➔ Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,

➔ Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated release of the product.

Scrum Events - Sprint RetrospectiveThe Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.

Scrum Events - Sprint RetrospectiveThe purpose of the Sprint Retrospective is to:

➔ Inspect how the last Sprint went with regards to people, relationships, process, and tools;

➔ Identify and order the major items that went well and potential improvements; and,

➔ Create a plan for implementing improvements to the way the Scrum Team does its work.

CREDITS

Presentation template by SlidesCarnivalPhotographs by Death to the Stock Photo (license)SOURCES

http://agilemethodology.org/http://scrummethodology.com/http://searchsoftwarequality.techtarget.com/definition/Scrumhttp://scrumreferencecard.com/scrum-reference-card/http://www.scrumguides.org/scrum-guide.htmlhttp://www.synagila.com/wp-content/uploads/2014/01/scrum-board.jpghttps://amareshv.files.wordpress.com/2011/03/fairydustboard_20110324.jpghttps://www.mountaingoatsoftware.com/agile/new-to-agile-or-scrum