Studied by 0 people
Looks like no one added any tags here yet for you.
Scrum
most common method of agile
Agile
umbrella term used to refer different types of iterative development
Iterative vs Incremental : Goal
iterative: correctness of solution
incremental: speed
Agile Benefits
customer involved throughout life cycle
greater customer interaction with all stakeholders
constant feedback is required to stay current and successful
Greater Value up front
Change is welcomed by all stakeholders
Agile Mindset
welcome change
work in small value increment
use build and feedback loop
learn through discovery
value-driven development
failing fast with learning
continuous delivery
continuous improvement
Inverting Triangle
Traditional: Time and Cost change, scope stay
Agile: Scope change, time and cost stay
The Agile Manifesto Values
individual & interaction over Processes & tools
Working software over Comprehensive doc
Customer collaboration over Contract negotiation
Responding to change over Following a plan
individual & interaction
project undertaken by people, not tools
problem solve by people, not process
Working software
done in time
done just because
deliver software does what it should come first, before create doc
Customer collaboration
manage change, don’t suppress change
Responding to change
spend effort and energy respond to change
Agile Guiding Principle 1
satisfy customer through early and continuous delivery
Agile Guiding Principle 2
welcome change, even late in development
Agile Guiding Principle 3
deliver working software frequently
Agile Guiding Principle 4
people and developer must work together daily
Agile Guiding Principle 5
motivated individual, give support, trust them
Agile Guiding Principle 6
face-to-face conversation, most efficient and effective
Agile Guiding Principle 7
working software is primary measure of progress
Agile Guiding Principle 8
sustainable development, maintain constant pace indefinitely
Agile Guiding Principle 9
continuous attention to technical excellence and good design enhance agility
Agile Guiding Principle 10
Simplicity, maximum amount of work not done is essential
Agile Guiding Principle 11
self-organizing team, create best architecture, requirement, and design
Agile Guiding Principle 12
regular intervals, team reflect on how to be more effective, then tunes and just its behavior accordingly
Product Backlog
an agile framework for managing projects, particularly in software development. It’s a prioritized list of everything that might be needed in the product
Agile Scrum Process
CUstomer/Product Owner → Product Backlog → Sprint Planning Meeting → Sprint Backlog → Sprint/Iteration (include Daily Standup Meeting → Sprint Review Meeting → Sprint REtrospective → Potentially Shippable Product Increment
Sprint
a short iteration where project teams work to complete the work in sprint backlog(1-4 weeks typical)
Sprint Backlog
work team selects to get done in the next sprint
Sprint Planning Meeting
meeting done by agile team to determine what features will be done in the next sprint
Daily Stand Up Meeting
a quick meeting each day to discuss project statuses, led by Scrum Master (usually 15 mins)
Sprint Review
an inspection done at the end of sprint by customers
Retrospective
meeting done to determine what went wrong during sprint and what went right
Partial Completed Product
customers Demo the product provides feedback, feedback adjust next Sprint priorities
Release
several sprints wort of work directed to operations for possible rollout and testing
Product Owner
deigned person rep customer
owns product vision
define feature, decide release date, content
responsible for market success
prioritize feature according to market value
can change feature and priorities every Sprint
3 Pillars of Scrum
Transparency
Inspection
timely check
look for problematic deviation
Adaptation
adjust process to minimize further issue
ScrumMaster
responsible for facilitating process
focus team and protect them from external interruption
look for way to enhance productivity
assist product owner in leveraging scrum
Development Team
small team
focus on steady delivery
generate option for delivery
manage own work
Scrum Activities
sprint planning meeting
sprints
daily stand-up meeting
sprint review meeting
sprint retrospective
Sprint Planning Meeting
determine what work will be done
predict what can be delivered on estimate, projected capacity, past performance
determine how this functionality will be built, how team will organize to deliver sprint goal
output: sprint backlog
Sprints
timeboxed (time-limited), 1-4 weeks
each sprint include sprint planning meeting, daily Scrum, actual work, sprint review meeting, sprint retrospective
During sprint, no changes are made that would affect sprint
team members are kept same throughout sprint
Daily Scrum (or Standup)
15 min time-boxed activity for Development Team synchronize activities and create plan for next 24 hours
should be held at same time and place each day
each team member should answer 3 questions
what did you do yesterday
what will you do today
are there any impediments in your way
Sprint Review
at the end of Sprint
gather feedback
demo work completed
create conversation b/t Team and stakeholder about how make product better
Sprint Retrospective
inspect and create plan for improvement to be done during next Sprint
what went well
what went wrong
what to do more
what to do less
Scrum Artifacts
Product increment
Product Backlog
Sprint Backlog
Product Backlog
prioritized list of all works
dynamic list, evolves as more work i added and prioritized
items prioritized by product owner and sort by value
most valuable items listed first
constantly being refined as more work is added to it
team and product owner will “groom backlog”
Product Increment
part of product that is done after each sprint
done to get feedback after each sprint
product owner and team needs to agree upon “definition of done” before team starts working on product
Sprint Backlog
product backlog selected for a specific sprint
plan to how to achieve sprint goal, forecast for functionality that will be part of sprint
visible view of work being undertaken and may only be updated by development team
Definition of Done (DoD)
shared understanding of what it means when work is considered done, defined at beginning of project, applies globally to project
crucial element of a successful scrum software development
might include thing
DoD for Unit & functional tests
Dod Documentation
Dod for a Writing code
XP Practices - Planning Activities
Release Planning
push of new functionality all the way to production user
customers outline functionality required
Developers estimate difficult build
XP Practices - Planning Activities
Iteration Planning
short development cycles within a release (Scrum calls “sprint”)
conduct at start of every iteration, or every 2 weeks
customer explain functionality they would like in iteration
developer break functionality into task and estimate work
based on estimate and amount accomplished in the previous work
XP Practices
Small Release
frequent, small release to test environment
demo progress and increase visibility for customer
quality maintained: rigorous testing or continuous integration
XP Practices
Customer Tests
customer describes one or more tests to show software is working
team builds automated tests to prove software is working
XP Practices
Collective Code Ownership
any pair of developer can improve any code
multiple ppl work on all code, which results in increased visibility and knowledge of code base
lead to higher level of quality, more ppl look at it, greater chance defect will be discovered
less risk if programmer leave, since knowledge is shared
XP Practices
Code Standards
follow consistent coding standard
code looks as if it has been written by a single, knowledgeable programmer
XP Practices
Sustainable Pace
repeated overtime is unsustainable
XP Practices
Metaphor
XP use metaphor and similes to explain designs and create a shard technical vision
description establish comparison that all stakeholders can understand help explain how system should work
I.e. “the invoicing module is like an accounts receivable personnel who makes sure money collected from our customers
XP Practices
Continuous Integration
integration involves bringing code together and make sure it all compiles and works together
critical, because it brings problems to surface before more code is built on top of faulty or incompatible designs
XP Practices
Test-Driven Development (TDD)
write test then code
if test work, initial code entered will fail test
code will pass test once it is written correctly
XP Practices
Pair Programming
code written by 2 developers
provide real-time feedback
XP Practices
Simple Design
code is testable, browsable, understandable, explainable
self-organizing teams
XP Practices
Refactoring
remove redundancy, eliminate unused functionality, rejuvenate obsolete designs
saves time and increases quality
Code is kept clean, so easy to understand and modify, extend
Lean Software Development Principles
using visual management tool
identify customer-defined value
build a learning and continuous improvement
Lean Software Development
Eliminate Waste
include partially done work delays, handoffs, unnecessary feature
Empower team
Deliver fast
Optimize whole
Build quality in
Defer decision
balance early planning with making decision and committing to things as late as possible
Amplify learning
facilitate communication early and often
7 Wastes of Lean
Partially done work
extra processes
extra features
task switching
waiting
motion
defect
Kanban Development
derived from lean production system
Kanban is Japanese meaning “signboard”
Items
In Progress
Testing
Done
Kanban 5 Principles
Visualize workflow
Limit WIP (work in progress)
reduce issues
Manage Flow
Make process policies explicit
improve collaboration
Feature-Driven Development
first develop overall model, then build list, plan work
Crysal
customized methodologies coded by color names
small team work on non-critical project
Crystal magenta used for larger team work on more critical work
Scalable Agile Framework (SAFe)
implements Scrum at enterprise level
approach consume whole enterprise, not just a team
deal with big global teams
all aspect of organizations are managed
3 important parts
Lean Production Development
Agile Software Development
System Thinking
Servant Leadership to Lead Effectively
shield team from interruptions
remove impediment to progress
recommunicate project vision
carry food and water
give them resource they need to succeed
12 Principles for Leading Agile Projects
learn team member needs
learn project requirements
act for simultaneous welfare of team and project
create an environment of functional accountability
have a vision of completed project
use project vision to drive your own behavior
serve as central figure in successful project team development
recognize team conflict as positive step
manage with an eye toward ethics
remember ethics is not an afterthought, but an integral part of our thinking
take time to reflect on project
Develop trick of thinking backwards
Leadership Tools and Techniques
modeling desired behavior
honesty
forward-looking
competent
inspiring
communicating project vision
enable other to act
inclusive tools
willing to change status quo
Leadership Task
practice transparency through visualization
create safe environment for experimentation
experiment with new technique and process
share knowledge through collaboration
Prioritization techniques
simple Scheme
MoSCoW prioritization
Monopoly Money
100-point method
Dot Voting or Multi voting
Kano Analysis
Requirements Prioritization Model
Simple Scheme
priority 1, 2 ,3, etc
could be problematic as many items become first priority
MoSCoW Prioritization
Must have
Should have
Could have
Would like to have, but not this time
Dot Voting or Multi-voting
each person gets a certain number of dots to distribute requirements
Monopoly Money
give everyone equal monopoly money
distribute funds to what they value most
100-point Method
each person is given 100 points
use that to distribute to individual req
Kano Analysis
help to understand customers satisfaction
Delighter/Exciter
Satisfier
Dissatisfier
Indifferent
Deliver value incrementally
reduce amount of rework
Minimal Viable Product (MVP)
refer to set of functionality that is complete to be useful, but small enough not to be entire project
usually a module in a software
Tools for Agile Projects
low-tech, high-touch over computer models
no stakeholder interaction
Low-Tech, High-Touch Tools
card, chart, whiteboard, wall
skip Gantt chart to Kanban board
Kanban/Task Board
“information radiator” - ensure efficient diffusion of info
make iteration backlog visible
Engage Stakeholder
short iteration and release keep them engage
keep them engage lead to stakeholder being more involved
identify risk and issue early
if some stakeholder causing problem, agile PM need to use interpersonal skill
need to have a process for escalating skatekholder issue
Methods of Stakeholder Engagement
get right stakeholder
cement stakeholder involvement
actively manage their interest
frequently discuss what done look like
show progress and capability
candidly discuss estimate and projection
Set a Shared Vision
ensure customer and agile project team has same vision.
Methods:
Agile Charter
Definition of “Done’
Agile Modeling
use case diagram
Data models
screen design
wireframes
personas
Definition of “Done” should be done for
user story
release
final project deliverable
Agile Modeling
Case Diagram
visually show how user would use an app
Agile Modeling
Data Model
how data are structured in table and their relationship
Agile Modeling
Screen design
simple screenshots
Agile Modeling
Wireframes
quick mock-up of product
“low-fidelity prototyping”
clarify what “done” look like
Agile Modeling
Personas
quick guides or reminder of key stakeholder and interest
provide description of user
be grounded in reality
be goal-oriented, specific, relevant
tangible and actionable
Communicating with Stakeholders most effective
face to face
two-way
knowledge sharing
info radiator
social media
Two-way communication
just dont ask for confirmation or concern, but actually listen to what they have to say
Knowledge sharing
use Kanban board or wireframe
low-tech like whiteboard
Levels of Conflict (1-5)
Level 1: problem to solve - sharing info
Level 2: Disagreement - Personal protection
Level 3: Contest - Must win
Level 4: Crusade - Protect one’s group
Level 5: World War - Must destroy other
Simple Voting
vote “for” or “against” it
Thump up/down/sideway
way of support, sideway if they can’t make up their mind
