Agile Project Management
Project Management Resources Site
Traditional Versus Agile
► Traditional PM Approach
► Concentrates on thorough, upfront planning of the entire project.
► Requires a high degree of predictability to be effective.
► Agile Project Management (Agile PM)
► Relies on incremental, iterative development cycles
to complete less-predictable projects.
► Is ideal for exploratory projects in which requirements need to be
discovered and new technology tested.
► Focuses on active collaboration between the project team and customer
representatives.
Traditional Versus Agile PM
Agile Project Management
► Agile PM
► Is related to the rolling wave planning and scheduling project methodology.
► Uses iterations (“time boxes”) to develop a workable product that
satisfies the customer and other key stakeholders.
► Stakeholders and customers review progress and re-evaluate priorities to
ensure alignment with customer needs and company goals.
► Adjustments are made and a different iterative cycle begins that
subsumes the work of the previous iterations and adds new capabilities to
the evolving product
Agile PM Characteristics
Focus on customer value
Iterative and incremental delivery
Experimentation and adaptation
Self-organization
Continuous improvement
Based on the Manifesto for Agile Software Development
► Individuals and interactions over processes and tools
► Working software over comprehensive documentation
► Customer collaboration over contract negotiation
► Responding to change over following a plan
Agile SW Development Principles
1. Customer satisfaction by rapid delivery of useful software
2. Welcome changing requirements, even late in development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Self-organizing teams
12. Regular adaptation to changing circumstances
Agile Projects Characteristics
► Lean methodology - Only as much process as necessary.
► 'Agile' is an umbrella term used for identifying various models used for agile development, such as
Scrum.
► Since agile development model is different from conventional models, agile project management is
a specialized area in project management.
Foundations of Scrum
► Transparency - all steps, inputs, and outputs of the development process are visible. An example of
transparency would be the burn down chart
► Inspection - provides an opportunity for feedback on the product. A great example of this is the
Sprint demo
► Adaptation - allows for making changes to the processes or procedures. The Sprint Retrospective is
a great example of this
Why go Agile?
► Accelerate time to market
► Manage changing requirements
► Better alignment to business
► Increase productivity
► Enhance software quality
► Ensure project visibility
► Reduce risk
► Simplify development process
► Reduce cost
► Improve team morale
► Enhance software maintainability
► Manage distributed teams
Agile Projects
► Agile project management is an iterative approach to planning and guiding a
project processes.
► An agile project is completed in small sections called iterations, or in scrum,
sprints.
► Each iteration is reviewed and critiqued by the project team, which may
include representatives of the client business as well as employees.
► Insights gained from the critique of an iteration are used to determine what
the next step should be in the project.
► Each project iteration is typically scheduled to be completed within two
weeks.
Scrum
► SCRUM is an agile, lightweight process for managing and controlling
software and product development in rapidly changing environments.
Properties:-
► Iterative, incremental process
► Team-based approach
► developing systems/ products with rapidly changing requirements
► Controls the chaos of conflicting interest and needs
► Improve communication and maximize cooperation
► Protecting the team form disruptions and impediments
► A way to maximize productivity
Scrum Roles
Product owner:
► Responsible for the business value of the project
► Decides what work to do and in what order, as documented in the product backlog.
► Ako of project sponsor
Scrum Master:
► Ensures that the team is productive,
► Facilitates the daily Scrum,
► Enables close cooperation across all roles and functions,
► Removes barriers that prevent the team from being effective.
► Has authority over the process but not the people on the team.
► Some experts suggest that traditional project managers do not make great Scrum- Masters.
Scrum team (development team):
► A cross-functional team of five to nine people who organize themselves and the work to
produce the desired results for each sprint.
► Large projects might require teams of teams.
Scrum Project Management Framework
Key Takeaway: There are iterations at multiple points in the framework.
Summary of Scrum Process
Scrum Activities
Process (Project Mngt.) Activities
Initiating Determine roles
Decide how many sprints will compose each release and the
scope of software to deliver
Planning Create product backlog
Create sprint backlog
Create release backlog
Plan work each day in the daily Scrum
Document stumbling blocks in a list
Execution Complete tasks each day during sprints
Produce a shippable product at the end of each sprint
Monitoring and Controlling Resolve issues and blockers
Create and update burn-down chart
Demonstrate the completed product during the sprint review
meeting
Closing Reflect on how to improve the product and process during the
sprint reflection meeting
Scrum Artefacts
► Product Backlog
► Requirements for a system, expressed as a prioritized list of Backlog Items
► Is managed and owned by a Product Owner, using a spreadsheet (typically)
► Usually is created during the Sprint Planning Meeting
► Can be changed and re-prioritized before each PM
► Sprint Backlog
► A subset of Product Backlog Items, which define the work for a Sprint
► Is created ONLY by Team members
► Each Item has it’s own status
► Should be updated every day
► No more then 300 tasks in the list
► If a task requires more than 16 hours, it should be broken down
► Team can add or subtract items from the list.
► Product Owner is not allowed to do it
► Burn down Charts
► Are used to represent “work done”.
► Are wonderful Information Radiators
► 3 Types:
► Sprint Burn down Chart (progress of the Sprint)
► Release Burn down Chart (progress of release)
► Product Burn down chart (progress of the Product)
Burn-down Charts
Sprint Burn-down
► Depicts the total Sprint Backlog hours remaining per day
► Shows the estimated amount of time to release
► Ideally should burn down to zero at the end of the Sprint
► Actually is not a straight line, can bump up
Burn Down Charts
Release Burn-down
► Will the release be done on right time?
► X-axis: sprints
► Y-axis: amount of hours remaining
► The estimated work remaining can also burn up
Product Burn-down chart
► Is a “big picture” view of project’s progress (all the releases)
Agile Project Events
1. Product Backlog: Stories which have not been completed and have value to
the customer. The backlog should be regularly prioritized, groomed and
include “acceptance criteria”. If a story is not properly groomed it should not
be pulled into sprint.
2. Release planning: Planning the next set of product features to release
3. Sprint: A short cycle of development, in which the team creates potentially
shippable product functionality.
4. Sprint planning: A meeting at the beginning of each sprint where the scrum
team commits to a sprint goal.
5. Daily scrum: A 15-minute meeting held each day in a sprint, where
development team members state what they completed the day before, what
they will complete on the current day, and whether they have any roadblocks.
Agile Project Events
6. Sprint review: A meeting at the end of each sprint, where
the development team demonstrates the working product
functionality it completed during the sprint.
7. Sprint retrospective: A meeting at the end of each sprint
where the scrum team discusses what went well, what could
change, and how to make any changes.
Get Quick Wins First
► Build High value first
Value
High Value (1) High Value (2)
Low Complexity (3) High Complexity (4)
Low Value Low Value
Low Complexity High Complexity
Start Complexity
Selection considerations: guiding questions
► Organizational characteristics
► What are the characteristics of the organizational culture?
► What are the management comfort levels with the various
methodologies?
► How open is management and the organization to change?
► Is the organization risk-tolerant or risk-averse?
► What is the organization’s tolerance for real risk vs. perceived risk?
► Project characteristics
► How large is the project?
► What is the project’s estimated duration?
► Are teams co-located or distributed?
► Is regulatory compliance a significant factor?
► How flexible are documentation requirements?
Selection considerations: guiding questions
► People and management characteristics
► What are the experience levels of team members?
► Are team members self-motivated or command-driven?
► What sort of management style is employed? Laissez-faire,
micromanagement, or somewhere in-between?
► What sort of social dynamics govern project efforts within the
organization? Cooperative and problem-solving, adversarial, or
blaming?
Reasons for Agile Project Failure
► Inexperience on agile development
► Misunderstanding of the broader organisational change
needed
► Organisational culture at logaheads with agile
development
► Unwillingness of team to learn
► Lack of Management support
► Lack of mutual trust between business and development
Pros and Cons of Agile Project Management
Pros Cons
• Quicker delivery of valuable functionality • Hard to predict cost
• Highly flexible • Time consuming
• Regular prioritization • Requires “culture change”
• Quicker feedback cycles and bug • Requires significant management support
identification
• Does not provide “instant gratification”
• Fewer defects in final product
• Requires reinforcement not to fall back to
• Effective where goals are Waterfall.
“ill defined” or evolving
• Documentation may be incomplete
• Highly interactive and collaborative