Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Agile - Scrum

No description
by

Arnold Schoenfeld

on 15 January 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile - Scrum

Agile - What it is / What it's not

Scrum What is agile Software development methods based on iterative and incremental development where requirements and solutions evolve through collaboration between self-organized, cross –functional teams.

It's the ability to inspect and adapt, reflect and refine, and efficiently and effectively manage the changes that inevitably occur.

Genesis

Software Developers belief that a history of over budget projects was caused by volatile requirements and ambitions to create sweeping, improperly targeted product designs before any real code was written.

The technological evolution of communications and how individuals interact with one another.

The speed at which software development has increased, bringing systems closer to the business Manifesto Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more. Empirical It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.
—B. A. Ogunnaike and W. H. Ray, Transparency 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.

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.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. A chance to question the need for the document and producing anything that doesn't make sense, isn't valuable, or insn't useful - regardless of previous practice. Planning that does not preclude building your product. It is lightweight, efficient, and iterative. An open door for scope screep Flexible and transparent means of allowing stakeholders to request changes taking deliberate tradeoffs into consideration A 'rigid best practice' solution A set of guiding principles with a number of options: Scrum, XP, Kanban, Crystal Roles Rather Principles Product Owner Scrummaster
The scrum master helps the product group learn and apply scrum to achieve business value. The scrum master does whatever is in their power to help the team be successful

Process Champion: Ensures the scrum process is followed as closely and efficiently as possible. Runs most scrum-related meetings.

Block Remover: Works to remove any impediment may have in the way of completing their work

Buffer: Shields the team from unnecessary interactions that may be unhealthy for the team.

Facilitator

Radiates information

Enables cooperation Builds the product that the customer will use. The team is cross functionality and includes all the expertise necessary to deliver the potentially shippable product each sprint. It is self organizing, with a high degree of autonomy and accountability.

Cross functional: Aware of each others strengths and work together to support one another the meet the sprint goal

Agreeable and accountability: Sprints are planned as a group so that each team member may provide input- the result being estimations to which the team is held accountable

self Organizing: No tasks are assigned to anyone developer.

100% dedicated: Completely focused on one project

Comprised of 7/+- 2 people Product Owner Scrummaster Team Responsible for maximizing return on investment

Subject Matter Expert: Understands the domain well enough to envision a product.

Business Advocate: Understands the needs of the organization paying for the software’s construction

Customer Advocate: Understands the needs of the client buying the product ,selecting a set of features available to the customer

Communicator: Capable of communicating vision and intent effectively.

Decision Maker: Given a variety of conflicting goals and options, be the final decision maker for hard product decisions. Team An excuse to stop producting product documentation An opportunity to eliminate planning Agile is Not Process Product Vision Statement
Created by the Product Owner. An effective product vision guides the Scrum team and aligns stakeholders and customers.
Who is the target customer?
Which customer needs will the product address?
Which product attributes are critical to satisfy the needs selected?
How does the product compare against existing products?
What is the target timeframe and budget to develop and launch the product? Product Backlog Vision Statement Sprint Planning Sprint Review Daily Scrum Sprint Retrospective 24 hours The Backlog is the product roadmap existing throughout the life of the product

Contains all potential product "items" (new functionality, performance improvements, research, etc)
Evolving
Prioritization
Estimated
Used for release planning

Items do not have to be in the form of user stories, it could be use cases or any other requirement approach desired Sprint Planning Part 1:
What does the Product Owner want and why does he need it? Sprint Planning Part 2:
How to implement what the team decides to take on? The Product Owner discusses the sprint objectives and the next highest items that he would like to see implemented during the upcoming sprint.
What and Why
Last minute clarifications

The product owner may devise a 'Sprint Goal' which is a summary of the objectives
Provides the team with some scope flexibility, since even though not all items may be accomplished within the sprint, they should be able to produce tangible results towards that Sprint Goal Sprint Planning 1 Team forecasts the amount of items they can complete in the sprint starting at the top of the backlog and working down the list.
Determines all tasks and the hours to complete each task
Matches hours to complete tasks against available hours

Team estimates how much it will take rather than having it assigned to them, making it more reliable since it’s based on their own analysis and planning

The product owner has no control over how much the team determines it can take on

The team has the right to lobby for items they believe should be moved up the priority list (eg. Dependencies, the patients open) Sprint Planning 2 Every 2 - 4 Weeks The daily scrum is not a status meeting to report to a manager; it is a time for the self-organizing team to share with each other what is going on and to help them coordinate with one another

15 Minutes or Less

Each Individual answers 3 questions:
What have I worked on since the last meeting?
What will I working on until the next meeting?
What obstacles are in the way

There is little or no in depth conversation at the meeting. Any details should be discussed after the meeting or at another time.

Reporting of sprint progress is maintained via the task board and the sprint burn down chart Daily Scrum Product Inspection and Adaptation: Learn what is going on and evolve based on feedback

Conversation between the team, the product owner, and the stakeholders
Team: Discuss what is going on with the product and the team.
Product Ownder: Discuss the market.

The review includes using the actual live software that the team has built.

Should not take more than hour – 1 hour Sprint Review Team Inspection and Adaptation: Discuss how the team is working together and how it can be improved Sprint Retrospective Model of process control exercises frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs. What’s working?
What’s not working?
Agree to changes
Should always include positives and strength’s and not just negative feedback
Full transcript