The document outlines the principles and practices of agile methodology as a modern alternative to traditional project management, emphasizing flexibility, customer collaboration, and rapid delivery of software. It contrasts agile with the waterfall model, highlighting agile's adaptability to changing requirements and focus on teamwork and communication. Additionally, it provides insights on scrum as a framework for implementing agile practices, detailing roles, meetings, and tools essential for successful agile project management.

1. Collaborate. Innovate. Transform.
Agile Methodology

2. 2
Traditional project management
Requirements
Design
Development
Testing
Implementation
Traditional 20th century approaches
 Suited for manufacturing and construction
 Requirements and technology were fairly predictable
Waterfall methodology
 Sequential development
 Each step encompasses the whole project scope
 Don't see tangible value until the very end

3. 3
Modern software development
Agile: An alternative framework
 Addresses increased uncertainty in the process
 Requirements are unpredictable and always changing
 More emphasis on adaptability and innovation
 Frequent feedback loops allow regular reviews of the process
 Speed to market: frequent delivery of products is also a competitive advantage
Human-centric
 People are not mere resources
 Capable, motivated team members take active involvement in the process
 Collaborate and cooperate with all stakeholders
 Open communication is imperative for accountability, transparency, and shared
responsibility

4. 4
Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
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.

5. 5
Agile Manifesto - Principles
1. Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
4. Business people and developers must work together
daily throughout the project.
5. Build projects around motivated individuals. Give them
the environment and support they need, and trust them
to get the job done.
6. The most efficient and effective method of conveying
information to and within a development team is face-to-
face conversation.
7. Working software is the primary measure of
progress.
8. Agile processes promote sustainable
development. The sponsors, developers, and users
should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and
good design enhances agility.
10. Simplicity--the art of maximizing the amount of
work not done--is essential.
11. The best architectures, requirements, and
designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.

6. 6
Agile vs. Waterfall
Waterfall
 “Phase gates"
 Must ask for approval to move to next phase at every step
 Can't change the scope once development starts
Agile
 Re-set scope and priority every 2-4 weeks
 Requirement changes are anticipated, accommodated, and even
embraced
 Your work is always aligned to the current highest value
business needs

7. 7
Time/Cost/Scope
Waterfall
 Fixes the scope
 Often bloated - only 20% of the features actually get used
 Any changes to time and cost are frowned upon
Agile
 Fixes the time and cost
 Scope is flexible
 Freedom to add/remove features to ensure that what's needed is actually delivered
 It’s important to start developing the highest priority features first

8. Stages

9. Objective
Define what you are building, who’s on your team, and your team’s
values and norms
Activities
 Create a project charter that outlines scope, objectives, and
defined stakeholders
 Define overall boundaries, product vision, and key benefits
Approach
 Keep the team small: 15 or fewer members, or split into subteams
 Teams work closely together, prioritizing face-to-face
communication
Envision
Envision
Speculate
Explore
Adapt
Close

10. Objective
Create and revise a feature-based delivery plan
Activities
 Estimate time and cost
 Assess risks
 Organize features into groups and prioritize them
Key Terms
 Feature: small piece of client-valued functionality or
outcome that satisfies a business need
 Sprint: iteration; one project cycle where the team
completes a small, logical chunk of work
Speculate
Envision
Speculate
Explore
Adapt
Close

11. Explore
Objective
Develop the product
Activities
 Frequent interaction between business and technical teams
 Meetings
 Peer reviews
 Frequent testing
 Testers must be flexible and use expertise to make judgment
calls
Approach
 Issue register
 Track issues and their resolution
 Compile a bank of lessons learned
 Feature board
 Visually track progress
Envision
Speculate
Explore
Adapt
Close

12. Adapt
Objective
Use feedback to move forward
Activities
 Review what has been delivered and compare to the plan
 If features weren’t completed, discuss why not and
adjust expectations for the future
 Review the product with the customer to check progress
and potentially alter the direction of the project
 Often the most valuable features aren't at all obvious
until the customer has had a chance to play with the
software
 Team members reflect on performance:
 Discuss what is and isn’t working
 Agree to changes for the next sprint
Envision
Speculate
Explore
Adapt
Close

13. Objective
All deliverables are completed. Reflect on and document
lessons learned.
Activities
 Administrative tasks: invoicing, regroup for next project
 Communicate overall project results
 Transition monitoring of business results to client
Close
Envision
Speculate
Explore
Adapt
Close

14. 14
Daily Meeting
Process
 Limited to 15 minutes (for larger teams, 30 minutes max)
 Whole team convenes, standing up
 Each person answers 3 questions:
 What did you do yesterday?
 What do you plan to do today?
 What obstacles are in your way?
 Identify issues to discuss later, report back the next day
What this meeting is not
 Extended discussions
 Status report – should be peer-to-peer, not subordinates
reporting to a supervisor
Other common pitfalls
 Team members never raising any issues
 People emphasizing effort spent instead of tasks completed

15. Scrum

16. 16
Scrum
What is Scrum?
 The Agile Manifesto lays out values but doesn’t
provide concrete steps for implementation
 Scrum provides a more explicit framework with strict
rules to follow
 Etymology: scrum is a rugby term for a tightly packed
group of team members who move down the field as
one
Sprints
 Short (as short as 1 week or as long as 12 weeks)
 Maintain a “potentially shippable product” at all
times
 Every sprint combines all aspects of work
 Break tasks down into 1-2 working day chunks, and
measure progress daily

17. 17
Scrum team
Product Owner:
 Single individual responsible for return on investment
 Communicates project vision to developers
 Prioritizes product backlog and makes final business decisions based on project vision
 Shouldn’t micromanage, but should be available to answer questions
ScrumMaster:
 Facilitator with no management authority
 Removes obstacles to completing goals
 Teaches the team about scrum
Team:
 Small, cross-functional group that collaborates and learns from each other
 Self-organizing - has autonomy and responsibility to meet goals
 Empowered to make decisions: ensures buy-in, commitment, and sense of ownership

18. 18
Scrum tools
Product backlog:
 Everything we might ever do
 Organized by priority
 Written in the form of user stories or use cases
 User stories: “As a [user role], I want to [goal], so I can [reason].”
 Provides the who, what, and why, but not the how
Sprint backlog:
 What we have committed to do during the current sprint
 Has an end date

19. 19
Scrum meetings
Sprint planning meeting:
 Take top items from product backlog and plan to do them in this sprint
Daily scrum:
 15-minute stand-up meeting where team members report to each other
Sprint review meeting:
 Demonstrates a potentially shippable product to stakeholders to get feedback
Sprint retrospective meeting:
 Inspect and adapt the process
 What went well? What could be improved?
 Focus on 1-2 improvements for the next sprint and make sure to follow up
Backlog refinement meeting:
 Look ahead into product backlog and edit

20. 20
Resources
Lynda courses:
 Agile Project Management: http://www.lynda.com/Business-Project-Management-
tutorials/Welcome/122428/147336-4.html
 Transitioning from Waterfall to Agile Project Management: http://www.lynda.com/Business-Skills-
tutorials/Agile-vs-waterfall/369191/438508-4.html
Agile:
 Agile Manifesto: http://www.agilemanifesto.org/
 Agile Methodology: http://agilemethodology.org/
 What is Agile? 10 Key Principles: http://www.allaboutagile.com/what-is-agile-10-key-principles/
 Agile Glossary: https://www.agilealliance.org/agile101/guide-to-agile/agile-glossary/
Scrum:
 Scrum Methodology: http://scrummethodology.com/
 Intro to Scrum: http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm

21. © 2016. Aciron Consulting, LLC. All rights reserved.
Notice: This document is proprietary and confidential.
This document is protected under the copyright laws of the United States and
other countries as an unpublished work. This document contains information that
is proprietary and confidential to Aciron or its alliance partners, which shall not be
disclosed outside or duplicated, used, or disclosed in whole or in part for any
purpose other than to evaluate Aciron. Any use or disclosure in whole or in part of
this information without the express written permission of Aciron is prohibited.
Aciron Consulting, LLC
678 Massachusetts Ave
Suite 1002
Cambridge, MA 02139
(617) 245- 0497
www.aciron.com