Please enable JavaScript.
Coggle requires JavaScript to display documents.
AGILE, 20 YEARS of PM in 25 Minutes:, KANBAN, SCRUM, WATERFALL, PORTFOLIO …
AGILE
ESTIMATION
-
Time: given by the TEAM:
"Nothing is impossible for the man who does not have to do it himslelf." - A.H.Weiler
-
-
-
PLANNING POKER
Gather TEAM, distribute decks of cards
-
Team discusses the story, each picks a card for estimation
-
Numbers vary, TEAM discusses,
chooses cards again until convergence/agreement
THEME
FEATURE
EPIC
(Low-priority, large USER STORY)
-
-
PLANNING ONION 
-
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.
-
KANBAN
LIFECYCLE (7 CADENCES)
STRATEGY REVIEW (Quarterly)
Select the services to provide and the context in which those services are appropriate.
OPERATIONS REVIEW (Monthly)
Understand the balance between & across services, including deploying people &resources to maximize value delivery
-
SERVICE DELIVERY REVIEW (Bi-Weekly)
Examine & improve the effectiveness of a service. This is similar to a retrospective that is focused on improving the kanban system.
REPLENISHMENT MEETING (Weekly)
Identify items that the team will work on & determine which work items may be selected next. A planning meeting for a sprint/iteration.
THE KANBAN MEETING (Daily)
A team working on a service coordinates their activities for the day. A daily standup.
-
-
Whenever a column is empty, "pull" is done from a column to the left
LEAD TIME:
- time between accepting responsibility for the task and delivery
CUSTOMER LEAD TIME:
- time between customer "pushing" the task and delivery
-
ROLES
SERVICE REQUEST MANAGER
(Product Manager, Product Owner, Service Manager)
SERVICE DELIVERY MANAGER
(Flow Manager, Delivery Manager, Flow Master)
KANBAN VS SCRUM:
- Differences:
- NO 2-WEEKS SPRINTS:
- Continuous flow instead
- Similarities:
BACKLOG
DAILY STAND UP
DEMO
RETROSPECTIVE
VALUES
- Transparency
- Balance
- Cooperation
- Customer focus
- Flow (Work is a flow of creating value)
- Leadership
- Understanding
- Agreement
- RESPECT
CHANGE MANAGEMENT PRINCIPLES
- Start with what you do now
- Agree to pursue improvement through evolutionary change
- Encourage acts of leadership at every level
AGENDAS
- INSIDE: Sustainability (stable work pace, less stress & lower costs)
- OUTSIDE: Service-Orientation (focus on fulfilling customer needs, everything else - side-effects)
- FUTURE: Survivability (evolutionary approach to maintaining fitness & preparedness)
SERVICE DELIVERY PRINCIPLES
- Understand & focus on your customers’ needs & expectations
- Manage the work; let people self-organize around it
- Evolve policies to improve customer and business outcomes
PRACTICES:
- Visualise
- Limit work in progress
- better flow, shorter lead times, higher quality, more frequent deliveries
- Manage flow
- identifying & addressing bottlenecks & blockers
- Make policies explicit
- WiP Limits, capacity allocation, DoD
- Implement feedback loops
- System
- Thinking
- Approach
- To
- Introducing
- Kanban
SCRUM
ARTIFACTS
PRODUCT BACKLOG
- Dynamic ordered list of all what needs to be done on the product
- Single source of truth for the product
- Visible for everyone
- Anyone can add anything to a backlog
- Opportunities, not Commitments
- Also includes bugs, technical debt, important non-dev-related items (e.g. increase RAM, conduct training)
- Managed by PO (PRIORITIZING)
PRIORITIZING
-
VALUE-BASED
- High Risk
- High Value
- Low Risk
- Low Value
KANO MODEL
- Mandatory/Threshold - expected minimum
- Linear - raising satisfaction
- Exciters/Delighters - bonus
-
RICE
- Reach
X
- Impact
X
- Confidence
- Used for planning & tracking
- Dynamic
- Progressively refined (top to bottom)
- Vertical slice of functionality
CONTAINS ITEMS LIKE:
- STORIES
- BUGS
- CHORES
- EPICS
- PROTOTYPES
- FEATURES
- THEMES
- SPIKES
SPRINT
(PLAN > BUILD > TEST > IMPLEMENT/REVIEW)
- Length defined and cannot be changed
- Consistence cadence
- Scope is constant
- Quality goals do not decrease
- End goal - potentially shippable increment of functionality
SPRINT BACKLOG
(All what TEAM is doing right now, in the current SPRINT)
- Includes at least 1 high-priority improvement from the last RETROSPECTIVE
- Emerges during the SPRINT as the TEAM works through the plan & learns more about thins to be done
- Only DEV TEAM can make changes to it
-
STORY
- Small (1-2 days), specific unit of work to complete
- Specific acceptance criteria
TEAM OBJECTIVES
- TEAM goals for the SPRINT
- Both commited work and stretch goals
DEFINITION OF DONE
- TEAM defined list to complete before sth is "done"
- Generic enough for (nearly) all tasks:
-- Acceptance criteria attached
-- Coded
-- Peer review & Code review done
-- Unit tests created & passed
-- QA passed
-- PO has reviewed & accepted
- DOES NOT ALWAYS INCLUDE INSTALLATION
"GOOD ENOUGH"
- Perfect is too expensive
- Quick & simple designs
- Functional
- Can be extended
- Emergent architecture
- No "gold plating" (extra effort for little real value)
TASK BOARD
- Visual representation of work in progress
TODO | BUILD | TEST | DONE
OR
TODO | IN PROGRESS | DONE
METRICS
BURNDOWN CHART:
Story Points x Iterations/Days
for the TEAM, not the management
&
BURNUP CHART:
Same, but reversed, shows business value
- has TOTAL (BACKLOG) and COMPLETED
- SPRINTS
- RELEASE PERIOD
- PSI
- STORIES COMMITED
- STRETCH GOALS
- CAPACITY - how much room TEAM has
- VELOCITY - how much work can be done
-
-
FEATURE PROGRESS REPORT
- Dynamic
- Has PLAN and ACTUAL:
-- ACTUAL is green if within 15% of plan
-- ACTUAL is red, if more than 15% behind
PREDICTABILITY MEASURE
- TEAM consistently scoring within 80-100% objectives reached - GREAT!
- TEAM scoring beyond that range - LOSING CONTROL
CEREMONIES
SPRINT PLANNING:
- Start of every SPRINT
- Estimates based on TEAM's VELOCITY
- 90 to 120 min per week
- TWO parts: WHAT & HOW?
- Participants: Pigs (Chicken by invite)
- Good to have Pigs from other teams to discuss dependencies
WHAT?
- SM facilitates the meeting
- PO presents the next priorities from backlog
- TEAM presents technical items they wnat or need to do during the sprint
- TEAM discusses, asks PO questions
- TEAM breaks down stories as needed
- TEAM estimates each story (Poker time)
HOW?
- PO leaves the room
- SM facilitates the meeting
- TEAM calculates their sprint capacity
- TEAM discusses the stories in more detail
- TEAM adds stories to Team/Sprint Backlog
- Stop when capacity is filled
- TEAM confidence vote & commitment
- Stretch goals (next things to do)
CAPACITY ALLOCATION
Never 100%, stop 80-85%
- Refactoring - 10%
- Technical debt - 20%
- Architecture - 10%
- NEW STUFF - 60%
POST PLANNING
- SM presents the team commitments to PO
- PO can re-prioritize based on commitments
- if PO requires changes, TEAM repeats "HOW?"
- if no changes, TEAM commits to work, PO & Chickens commit to not require sprint scope change
DAILY SCRUM:
- Same time every day (start or end)
- 15 min, standing (@Taskboard)
- 3 Questions:
-- YESTERDAY
-- TODAY
-- IMPEDIMENTS
- SM takes note of questions & addresses afterwords
- Participants: PIGS!
SCRUM OF SCRUMS:
- 15 min, standing
- 1 Repr from each team (not always SM)
- Collabs & transparency across teams
- Programs w/ multiple independent teams
- At least 1/week, daily is great
- Same questions, less details
SPRINT REVIEW AKA DEMO:
- Informal meeting (NB!)
- 1 h/week of SPRINT
- Show TEAM's accomplishments from the sprint, e.g.:
-- Demo
-- Discuss research findings
-- Walk through new documentation
- Get PO's official approval
- Good to have Chickens present and asking questions (PO invites them)
- Gather performance metrics
- Collect feedback from attendees
- Review of what external factors might have changes and what is the MVThing to do next
- Review timeline, budget, capabilities and marketplace
- Celebrate success, have fun
BONUS - Program Review:
- same, but w/ all teams & on higher level of detail
STORY TIME / BACKLOG GROOMING (REFINEMENT)
- Whenever needed; just long enough
- Glimpse into the future
- Refined until deemed "Ready" to be selected for one of the future SPRINTS
- Participants: Pigs (Chicken by invite)
RELEASE PLANNING
- High-lvl estimated roadmap
- Release = period of time OR an actual installation
- Not a commitment
- Planning poker to assess feature's length
- Participants: Pigs & Chicken
SPRINT RETROSPECTIVE
- Kaizen (Continuous improvement)
- Participants: PIGS ONLY!
- 45 minutes/week of SPRINT
- 3 QUESTIONS:
-- What went well?
-- What went wrong?
-- What can we do to improve?
- Team building included:
-- Honest, transparent communications
-- Play games
-- Appreciate each others' efforts
-- TEAM outing
-
WHY IT WORKS?
- Customer's representative rules
- Quick reaction to the changing market and needs
- More visibility
- Ideal environment for development
- Self-managed teams
- Removes confusion and distraction
- No fortune tellers; Plan as you go
- Issues are less disruptive
- Continuous improvement
TRIPLE CONSTRAINTS:
- SCOPE (FLEXIBLE)
- TIME (FIXED)
- COST (FIXED)
VALUES
- commitment
- courage
- focus
- openness
- respect
PILARS
- transparency
- inspection
- adaptation
||
\/
trust
HOW IT WORKS?
- PRODUCT BACKLOG
\/
- SPRINT PLANNING
\/
- SPRINT BACKLOG
\/
- SPRINT (1-3 W) WITH DAILY SCRUMS
\/
- POTENTIALLY SHIPPABLE PRODUCT
\/
- SPRINT REVIEW (FOR PRODUCT OWNER)
\/
- RETROSPECTIVE (FOR TEAM)
ORIGIN:
Inspired by: Japan, 1986 inspired by Toyota "Lean Manufacturing" in mid-30s (Just In Time Inventory)
cross-functional team
Developed by Ken Schwaber and Jeff Sutherland
WATERFALL
ADVANTAGES:
- discipline through strict phase progression
- simple to implement
- easy to manage
- perfect for mass production and high lvl of certainty
DISADVANTAGES:
- linear, no going back
- each phase is owned by a separate team
- typically little collab btw teams/phases
- planning everything upfront
- strict requirements; hard to change scope
TRIPLE CONSTRAINTS:
- SCOPE (FIXED)
- TIME (FLEXIBLE)
- COST (FLEXIBLE)
PORTFOLIO
PROGRAM
PROJECT
LIFECYCLE (SEQUENCE)
(unique, custom)
-