What is Agile? Agile is not a project management methodology.

It is a philosophy and set of guiding principles for developing high quality software faster that better meets the needs of the business users. Agile Development is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include Scrum, Extreme Programming (XP), Crystal, RUP, EVO, Lean Development, and MSF for Agile. While each of the agile methods is unique in its specific approach, they all share a common vision and core values from the Agile Manifesto.

The Agile 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 .

Principles behind the Agile Manifesto:

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

Why do Agile/Scrum? Faster delivery of incremental value Higher quality code Daily involvement of the Business ensures that: Requirements are clearly defined Project progress is effectively communicated Software delivered meets up to the minute requirements

No surprises Teamwork and creativity It make common sense

What is Scrum? Scrum is an Agile methodology Scrum is made up of a series of iterations called sprints Each sprint is generally 30 days A project can be made up of one to several sprints Each sprint delivers an increment of usable software Typical individual team is 7 2 people The end date of a sprint never changes, instead, features are left out Each sprint uses an overlapping development process A sprint has a daily scrum meetings for the development team A sprint has daily business meetings The power of scrum is in the team, not the process

Scrum Framework: Roles: Business owner Product Owner Scrum Master. Team

Logistics: Sprint Planning Sprint Execution. Sprint Review.

Artifacts : Product Backlog Sprint Backlog Burndown Charts.

Roles in Scrum: Business Representatives Single representative from each impact business unit Authorized to make decisions for their business unit Responsible for communicating project status back to the business

Product Owner (similar to current Business Analyst or RM roles) Define the features of the product Decide on release date and content Prioritize features according to market value Adjust features and priority every iteration, as needed

Scrum Master (similar to current Project Manager and development lead roles) Represents management to the project Responsible for enacting Scrum values and practices Removes impediments Ensure that the team is fully functional and productive Shields the team from external interferences

Team Typically 5-9 people Cross-functional: Programmers, testers, user experience designers, etc. Members should be full-time. May be exceptions (e.g., database administrator) Teams are self-organizing Membership should change only between sprints

Sprint Logistics: Sprint Planning Business reps, Product owner, ScrumMaster and team meet to agree on which features from the product backlog will be included in the sprint

Sprint Execution Daily Scrum Meetings 15-20 minutes only Each team member is asked just three questions: What did you do yesterday? What will you do today? Are there any impediments in your way?

Daily Business Meeting Review and refine requirements as needed Discuss and resolve any issues that have come up Demo any new software functionality

Sprint Review

Development Guidelines: Follow an overlapping phase approach High level requirements for each user story and a logical approach are determined first Detailed requirements are created as you develop (just in time requirements) UI work is done first, then slice through a logical backend processes to get QA engaged as early as possible Adhere to upfront design reviews and backend peer code reviews Document code religiously

Sprint Artifacts: Product Backlog The product backlog is a high-level document for the entire project. It contains broad descriptions of all required features defined as user stories. It is the what" that will be built. It is open and editable by anyone. It contains rough estimates, usually in days. This estimate helps the Product Owner to gauge the timeline and, to a limited extent, priority.

Sprint Backlog The sprint backlog is a list of user stories selected to be delivered in a specific sprint. It is the how" that will be built. Each user story is broken down into development tasks. These tasks are broken down into pieces that will require less than two days (or sixteen developer-hours) of work.

Burn down Chart The burn down chart is a publicly displayed chart showing the number of tasks remaining for the current sprint or the number of items on the sprint backlog.

User Stories: A user story is a software system requirement formulated as one or two sentences in the everyday language of the user User stories are written by the business or Product Owners User stories are prioritized by the business to indicate which are most important for the system and will be broken down in tasks and estimated by the developers A user story must include acceptance/test criteria User story format: As a (role) I want (something) so that (benefit).

Examples: As a Student I want to purchase a parking pass so that I can drive to school As a book shopper, I can read reviews of a selected book to help me decide whether to buy it. As the system, I would like to add a record to the audit log if an page fault occurs

User stories are a simple thing. "Simple" is not always the same as "easy."

Sprint Backlog:

Sprint Backlog

User Story 1

Development Tasks Requirements Acceptance Criteria

User Story 1

Development Tasks Requirements Acceptance Criteria

When to use Agile/Scrum:

Co-location is highly preferred, especially for those new to Agile. Experienced, self directed team members Self motivated Possess good interpersonal skills Experienced enough at development to take little direction and deliver, make good decisions, and to recognize when clarification is necessary.

The business stakeholders trust the team to make decisions and deliver Global teams when supported by on-shore and off-shore counterparts to facilitate hand-off and updates. No dependencies on other projects using differing methodologies.

When to not use Agile/Scrum:

The project team cannot adapt to changes in working durations, overlaps & shifts Application users are NOT always accessible Team lacks breadth, depth, or both Specific instructions required Success is ensured by the team, not the process

Documentation in Agile/Scrum: Documentation is necessary The idea that documentation will be maintained over time is a fantasy Code is the ultimate documentation Documentation should be just barely good enough Documentation is done later in process Documentation must have a business value and that value must be greater than the cost of creating and maintaining it The teams primary goal is to develop software, its secondary goal is to enable the next effort. Comprehensive documentation does not ensure project success, in fact, it increases the chance of failure Recognize the use and reliance on living documentation Minimal: Vision Scope, System support document, Product backlog, Sprint backlog, Burndown charts, model/process flow diagram