Where and Why Agile Project Management Works

Plan, make decisions, and demonstrate your learning so you can succeed.

Move quickly from decision-making to action and innovation. Companies using Agile Project Management principles to run projects allows organizations with an Agile mindset to respond quickly and effectively to the complexity and uncertainty that characterize today’s business needs.

Illustration of Agile Project Management
What is Agile Project Management?

Broadly defined, Agile Project Management is an iterative process that focuses on customer value first, team interaction over tasks, and adapting to current business reality rather than following a prescriptive plan. Agile Project Management is based on the same organizational practices and key principles found in the Agile Manifesto.

The diagram below displays the differences between agile and waterfall development processes. By delivering working, tested, deployable software on an incremental basis, agile development delivers increased value, visibility, and adaptability much earlier in the life cycle, significantly reducing project risk.

value-prop

Agile Project Management is how you deliver high value and technical quality within your time and budget constraints. However, the principles go beyond software development. It’s a mindset for people who need a management approach that builds consensus quickly in a fast-paced environment.

Risk Mitigation
Time to Market
Budget Risk
Cancellation Cost
Scope Creep
Requirements Error
Technology Risk
Testing Risk

What the Analysts Say
1. Reduced time-to-market
2. Increased quality
3. Reduced waste
4. Better predictability
5. Better morale
Agile projects are 37% faster to market than industry average.

The Agile Paradigm Shift

agile1

 

What Agile is NOT
A specific methodology
– It’s an umbrella term for a set of approaches which share common values
“Glorified hacking”
– Rather, a synergistic set of highly disciplined practices
Working without planning
– Adaptive planning instead of following a plan
Suitable for all types of projects
– Unavailability of customers and pre-defined requirements may sway projects to other approaches
A silver bullet
– The project could still fail… but it will fail faster

Agile Manifesto for 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
“While there is value in the items on the right,
we value the items on the left more”

12 Principles behind Agile Manifesto

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.

agile2

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.

Bottom Line Agile
Focus on customer value
Deliver early and often
Working software is the primary measure of progress
Inspect and adapt
Collaborative culture

The Scrum Framework

agile3

Scrum Project Lifecycle

agile4

agile5

 

Scrum is Light-Weight
• No mention of issues or risk management, quality assurance, configuration management, story boards, etc.
• Anything additional that you do needs to support the Agile manifesto.
• Any additions are inspected and adapted by the team as part of the sprint retrospective.

Scrum Framework

Roles
Agile Manager
Product Owner
ScrumMaster
Team

Practices
Release planning
Sprint planning
Daily stand-up
Sprint showcase
Sprint retrospective

Metrics
Sprint burndown chart
Release burnup chart

Agile Manager
• Coach, inspire, and lead teams more than they measure and manage them.
• Focus on the organizational environment’s ability to deliver value

“If you fail to honor your people, they will fail to honor you;
It is said of a good leader that When the work is done, the aim fulfilled, the people will say ‘We did it ourselves.’ ”

The Scrum Team = 7  (+/- 2 people)
• Scrum Master
• Product Owner
• Team

SCRUM MASTER
• Removes impediments
• Enforces values and practices
• Protects the team
• Develops team members skills
• Facilitates ceremonies
• Escalates issues on behalf of the team

PRODUCT OWNER
• Develops and communicates the vision
• Represents (or is) the customer
• One voice, even if not one person
• Develops the product roadmap and release plan
• Accepts or rejects work results
• Addresses team’s questions
• Grooms the backlog and sets priorities

The Team
Primary responsibilities
• Breaks down user stories into tasks
• Estimate tasks during Sprint planning
• Works on design/code/test/integration for each task
• Supports other team members
• Continues to work through tasks until no tasks remain in Sprint backlog
• Participates in sprint demos and retrospectives
Skillsets required
• Technical expertise
• Cross functional – analysis /design /development / testing
• Collaborative team player – voluntarily offers assistance as needed
• Good communicator – knows to ask for help so the team stays on track

Product Roadmap

agile6

Release Schedule
Release Schedule looks easy – but the confidence to commit requires the rigor of Release Planning

agile7

Sprint Planning
0) Estimate team capacity
1) Discuss highest priority story from the product backlog
2) Size the user story
3) Break story into tasks
4) Task owner estimates task in hours
5) Repeat 1-5 until capacity is reached

Plan to the Team’s Capacity
1. Collect available hours before the sprint planning session
2. Build in a buffer
3. Stop when the team reaches capacity
 Prevent over-commitment
 Ensure a sustainable pace
 Ensure that the team has enough work
 Level-load the work

Deduct Time from Capacity for the Following Scrum Practices
Release Planning Session
– ~4 hours
– at least once per release
Sprint Planning
– ~2 hours for each 2-week sprint
Daily Scrum
– 15 minutes per day
Sprint Showcase
– 1.5 hours per sprint
Retrospective
– 30 minutes per sprint

Commit to the Work
“On a scale of 1 to 5, how confident are you that we can complete the user stories in the sprint plan by the end of the sprint?”

Daily Scrum or Standup
• Brief (10-15 min) daily meeting
• Assures continual team communication
• Drives accountability (peer-pressure, transparency)
• Demonstrates day-to-day progress to all team members and stakeholders

Everyone answers 3 questions
1. What did you do yesterday?
2. What will you do today?
3. Is anything in your way?
These are not status for the Scrum Master, they are commitments in front of peers.

Sprint Showcase
Two Parts
• Review of sprint metrics
• Live demonstration by the people who did the work
Informal
• 2-hour prep time rule
• No slides
Invite all interested parties
Open forum – collect feedback

The Definition of Done
Each delivery team needs to define their definition of when a user story is considered to be “DONE.”
For example:
 Has the code been promoted to QA/TEST environment?
 Has the code passed functional testing?
 Has documentation been updated?
 Has the code undergone peer code review?
Only when a user story meets all the criteria of done, (i.e., DONE/DONE) can the team claim credit for completing the story/functionality.
Note: Incomplete work cannot be demonstrated!!

Commit-Accept (Say-Do) Ratio
This diagnostic metric reflects team progress by completion of its work commitment.
Total story points accepted by the Product Owner Total story points committed for completion by the team
The higher the Say-Do Ratio, the better. For instance, if a team commits to finishing 40 story points in a sprint, and the PO only accepts 36 story points, the Say-Do Ratio equation is:
(36/40)*100 = 90%
Benefits:
A team can identify/inspect delivery problems then take corrective action(s) as required.
By meeting its work commitments, a team build trust with the PO/client supported.

Sprint Retrospective

agile8

• Team reviews sprint successes and short falls
• What could be done different in subsequent sprint?
• Build in continuous improvement to agile process
• Vital to success of agile development

Net Promoter Score How do customers feel about our product?

agile9

Promoters (score 9-10) Loyal enthusiasts who will keep buying and refer others, fueling growth.
Passives (score 7-8) Satisfied but unenthusiastic customers who are vulnerable to competitive offerings.
Detractors (score 0-6) Unhappy customers who can damage your brand through negative word-of-mouth.

Sprint Burndown Chart

agile10

 

Scrum Team Velocity
Velocity is the average number of user story points a delivery team completes during a sprint. It’s used to gage of how much work a team is capable of delivering. Benefits:
• Team velocity enables the Product Owner to forecast how much work a team can be expected to complete – based on the team’s own estimate of effort.
• With an established team velocity, the Product Owner can plan future releases with improved predictably.
The team’s goal is to gain and sustain a consistent velocity across releases.

User Stories
Purpose of User Story
A user story is an agreement to have a conversation

Product Backlog – “The Work”
• Owned and maintained by the Product Owner – stack ranked by business value offered – most important at top
• Master list of desired product functionality expressed as user stories
• One Product Backlog per delivery team
• Initiates the development process
• High priority items are used to create the Sprint Backlog
• Each user story provides value
• Grows & changes as more information is acquired

Sample Backlog Grooming Checklist
 Prioritize stories
 Clarify stories (e.g., title, description, notes, etc.)
 Assign initial point estimates (i.e., 1, 2, 3, 5, 8, 13, 20, 40, 100)
 Break down “epics” into smaller stories
 Identify any risks and dependencies
 Tag stories (e.g., administrative, technical spike, CRM, etc.)
 Add acceptance criteria
 Add any known tasks
 Change status in Rally from “B” (backlog) to “D” (defined)

Breaking Down User Stories
Right-Sizing Stories

agile11

Splitting User Stories
Remember: Don’t split or detail Product Backlog Items until they are declared sufficiently valuable for the product

Estimating User Stories
Estimating Effort
We’re not very good at estimating…
Relative Sizing
Begin by estimating the effort for what the team agrees is a medium story
Estimating Effort
Story 1/2/3 – Complexity, Effort, Doubt

Planning Poker
1. Read the user story, discuss briefly to ensure clarity
2. Each team member selects an estimate card Fibonacci sequence (1, 2, 3, 5, 8, 13) — any higher (20, 40, 100) means story needs more clarification
3. Cards are all turned over at once
4. Discuss the high and low cards
5. Re-estimate once more
6. SM makes the final call

Planning Poker acts to:
• Identify consensus quickly
• Democratize the discussion, so we hear from all voices!
• Uncover assumptions
• Team learns to collaborate on decisions

Summary:
Agile Manifesto for 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
“While there is value in the items on the right, we value the items on the left more”
http://agilemanifesto.org/

The Scrum “Fractal”

agile12

"605" srcset="http://avanteideas.com/blog/wp-content/uploads/2013/12/agile12.jpg 946w, http://avanteideas.com/blog/wp-content/uploads/2013/12/agile12-300x191.jpg 300w, http://avanteideas.com/blog/wp-content/uploads/2013/12/agile12-234x150.jpg 234w, http://avanteideas.com/blog/wp-content/uploads/2013/12/agile12-150x95.jpg 150w" sizes="(max-width: 946px) 100vw, 946px" />