Intro | What | Why | How

Introduction to Agile & Scrum

During the training

Mobile in Silent / Vibrator mode Attend calls outside the training room Punctual in coming back after breaks May not be able to answer all the questions because of the limited timing available. You can reach me at help@myscrumcoach.com Please mention [Agile Training Query] in Subject line Avoid checking mails during training

Schedule for Training

Introduction Software Development Predictive
Traditional approach problems in Traditional

Scrum
Sprint planning Daily Scrum Meeting Scrum Master Shippable Product
DONE

Adaptive
Agile
Scrum XP

Sprint Review Sprint Retrospective

Scrum
Product Owner Product Backlog Team Sprint

Release planning and estimation Scrum for multi location Scrum and Metrics Challenges Training notes

Software Development
Different ways of looking at software Dev.: Predictive Adaptive

Predictive
PMBOK PRINCE

Traditional approach
Defined, predictive process Sequence of distinct phases Plans everything up-front Most of the risk and difficult work is pushed toward end of the project

Problems with Traditional

Whole project planned up-front Doesnt handle change very well Requirements specifications are an abstraction and can be interpreted differently Insufficient testing during development QA is trailer-hitched, so quality isnt baked in and testing gets crunched at the end Progress measured by task % complete Often dont know until its too late

Adaptive

Agile Values & Principals

Agile Manifesto

Agile Principles -12 No's

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

Agile Principles -12 No's

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 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

Agile Principles -12 No's

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

Reasons to use Agile

Incremental approach breaks complex projects down into simpler mini-projects Accommodates change easily Improves ROI through frequent and regular delivery of value to the business Increased business involvement and satisfaction Increased visibility (progress, obstacles, risks, etc) Lower development risk, higher quality, less defects Shorter cycles produce working software and incremental product quickly Progress measured by running tested software Early and regular process improvement driven by frequent inspection

Origin of Scrum

Scrum Framework

What Is Scrum Being Used For?

Large-scale enterprise software projects Consumer software products Financial payment applications Large database applications Embedded systems CMMi Level 5 organizations Multi-location development Sustaining and Maintenance Projects Non-software projects

Product Owner
The Product Owner owns the vision of what should be produced to achieve business success Product Owner gets input from customers, endusers, team, managers, stakeholders, executives, industry experts, etc. The Product Owner turns this into a single list of what should be produced, prioritized based on business value and risk This list is called the Product Backlog

Product Backlog
The Product Backlog is the single master list of features, functionality, and other work required, prioritized based on business value and risk, in the judgment of the Product Owner Items at the top of the list will be completed by the team soonest The Product Backlog is constantly being revised (items added, removed, modified) by the Product Owner, to maximize the business success of the teams efforts

Scrum Team
The ideal team size in Scrum is 7 people +/- 2 The team is cross-functional. It has all the skills to produce finished product designers, coders, testers, etc. and everyone contributes based on competency, rather than just job title The team is self-organizing and self-managing. It is responsible for making a commitment and managing itself to hit the goal (or get as close as it can). Scrum provides tools to help team do this

Sprint
The Team works for a fixed period of time, called a Sprint Sprints are typically between 1- and 4-weeks in length. Some people recommend starting Scrum with 2-week Sprints Sprints occur one after another, without any down-time between them. Working at a sustainable pace is very important to avoid team burn-out Team and Product Owner decide the Sprint length in advance

Sprint Planning Meeting

Before each Sprint, the team selects what it will commit to deliver by the end of the Sprint, starting at the top of the Product Backlog The team creates a task-level plan for how they will deliver The team works together to create an initial assignment of tasks, and compares total estimated task hours with total estimated available hours, to make sure the commitment is reasonable Everyone on the team takes part, regardless of experience-level It is very important that the Product Owner not pressure the team into committing to more than they think is doable. If there is pressure, the team will over-commit and either not finish, or burn themselves out after a couple of Sprints Many managers are initially concerned that their team might undercommit. In reality, most teams have the opposite problem: it may take them several Sprints to learn to not over-commit

No Changes
During the Sprint, what the team committed to deliver does not change, and the end-date of the Sprint does not change This enables team to make and keep commitments, it gives the team focus and stability during the Sprint, and it trains Product Owner to clearly think through what is on the Product Backlog If something major comes up, Product Owner can direct the team to terminate the Sprint prematurely, and start a new one In return for not making changes during the Sprint, Product Owner can make any changes they want to the Product Backlog before the start of the next Sprint Product Owner can add, remove, reorder, or change items. They can also ask the team to re-implement work thats already been completed

Daily Standup Meeting

Each day, the team has a short meeting to update each other on progress and surface blocks. They stand up, to keep it fast To keep the meeting to <15 minutes, everyone reports just 3 things: done since yesterday, done by tomorrow, and blocks Scrum Master notes blocks, and afterwards helps resolve them. Others can attend the meeting if the team invites them, but they do not speak. This meeting is not for monitoring team Each day, the team updates simple charts that make visible how they are progressing towards their goal for the Sprint The Sprint Backlog lists all the tasks, and the hours remaining for each. The Burn down Chart graphs the total hours left for all tasks. The Task Board shows where tasks are in progress These charts enable the team to successfully self-manage and deliver what they committed to by the end of the Sprint

Scrum Master
The Scrum Master is a new role. It can be played by an existing person (such as a former Project Manager or team-member) The Scrum Master serves the team (helping them remove any and all impediments that surface), protects the team (from any outside disruption or interference), and teaches and guides the teams use of Scrum Without a Scrum Master, the team has a high risk of failure

Shippable Product
The aim for the team is to complete 100% of what they committed to, ideally an increment of Potentially Shippable Product at the end of each Sprint For software, this means functionality that has been designed, fully implemented, and fully tested, with no major defects Few teams can do product Potentially Shippable Product from Sprint 1, but each Sprint they work to get closer to this goal

Definition of Done
We have to define what Done means
This represents the goal were trying to achieve at the end of each Sprint

So what does Done mean?

Coded? Tested? Potentially Shippable?

Sprint Review
At the end of the Sprint, the Product Owner, Team, Scrum Master, and Stakeholders come together and see a demo of what the team has produced The Product Owner gathers feedback from everyone on ways to improve whats been built This feedback is incorporated into the Product Backlog

Sprint Retro
The Team, Product Owner, and Scrum Master meet at the end of each Sprint to review their way of working, and look for ways to improve their effectiveness This is the mechanism for continuous improvement, and also where critical problems are identified and addressed, or surfaced to management for assistance

Sprint Retrospective
Create 4 large lists (whiteboard or flipchart)
Whats working Whats could work better Things to try in the next Sprint Issues to escalate to management

Go around the room, and give each person an opportunity to add items to the 4 lists
If people agree with something already on the lists, put a tick mark next to them Select a subset of the Things to try... list to try in the next Sprint (Scrum Master responsible for tracking this)

Release Planning and Estimation in Scrum

Using Scrum for MultiLocation Development

Scrum and Metrics

ScrumBut

Scrum Challenges

Youre Not Done Yet

It doesnt matter how agile you have become or how well you do Scrum Being Agile is not the goal, delivering great product is Your primary goal is to develop amazing products, quickly and cheaply, that thrill your customers and users To do that, though, I believe you will need to be agile And to be Agile, you must continuously improve And to continuously improve, always you need to inspect and adapt (Scrum)
Taken from Succeeding with Agile Mike Cohn

Web Resources
To Name a few good ones www.google.com www.Scrum.org www.scrumalliance.org www.mountaingoatsoftware.com/scrum www.scrumprimer.com scrumdevelopment@yahoogroups.com

A Scrum reading list

Agile and Iterative Development: A Managers Guide by Craig Larman Agile Estimating and Planning by Mike Cohn Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Software Development Ecosystems by Jim Highsmith Agile Software Development with Scrum by Ken Schwaber and Mike Beedle Scrum and The Enterprise by Ken Schwaber User Stories Applied for Agile Software Development by Mike Cohn Lots of weekly articles at www.scrumalliance.org