Agile Flashcards
Agile Manifesto Values
While items on the right are valuable, items on the left are MORE valuable..
1. Individuals and Interactions over Process and tools
- people should interact, people undertake projects not tools
- problems get solved by people, not processes
2. Working software over comprehensive documentation
- focus on delivering value vs paperwork. Agile documents should be barely sufficient
- delivering software/product comes first than creating documentation
- Agile dramatically simplifies paperwork
3. Customer Collaboration over Contract negotiation
- be flexible, accommodating and not fixed/uncooperative
- manage change, don’t suppress change
- shared definition of ‘DONE’
4. Responding to change over following a plan
- spend effort and energy responding to changes. Products/software have high rate of change
What is Agile?
- it is an umbrella term (includes other incremental or iterative methods)
There are over 12 agile methodologies.. - SCRUM is the most common method of Agile
- common methods are EXTREME PROGRAMMING (XP), LEAN DEVELOPMENT, and KANBAN
XP (Extreme programming): Core values
- SIMPLICITY (Reduce complexity, extra features, waste)
- COMMUNICATION (team member should know what’s expected, Daily standup is key to communication)
- FEEDBACK (Get impressions of correctness early, failing fast allows for faster improvements)
- COURAGE (Allow work to be visible to others)
- RESPECT (People work together, everyone is accountable for success or failure, recognize people are different and work differently)
XP Practices
- RELEASE PLANNING
Push functionality all the way to production user. Customer outlines functionality required - ITERATION PLANNING
short development cycles of 1–2 weeks (like sprint in scrum). Customer explains functionality they would like in iteration. Developer estimates work - SMALL RELEASE
frequent releases given to test. Demonstrates progress - CUSTOMER TEST
customer describes tests to show software is working. Team builds automated tests to prove working of software - COLLECTIVE CODE OWNERSHIP
anyone can improve or amend code. Increase visibility and knowledge - CODING STANDARD
consistent coding standard - SUSTAINABLE PACE
periodic overtimes are ok. repeated long work hours are counterproductive - METAPHOR
XP uses metaphors and similarities to explain technical vision - CONTINUOUS INTEGRATION
bring code together and make sure it works
critical because it brings problems to surface - TEST DRIVEN DEVELOPMENT
team writes test prior to developing code. So that code is written according to test. - PAIR PROGRAMMING
code written by 2 developers. Provides real time reviews. Also spreads knowledge about the system. More eyes on it, the less bugs on it! - SIMPLE DESIGN
Code is always testable, browsable, understandable and explainable. Complex design is replaced by simple design. - REFACTORING
‘Remove redundancy, eliminate unused functionality and rejuvenate obsolete designs’
Basically, keep code clean and concise
Lean software development
Principles:
- Visual management tools,
- Identifying customer defined value
- Building in learning and continuous improvement
1. Eliminate Waste (partially done work, delays, handoffs)
2. Empower the team
3. Deliver Fast
4. Optimize the whole
5. Build quality in (throughout development process)
6. Defer decisions (plan early but take decisions/commit as late as possible)
7. Amplify learning (Facilitate communication, get feedback early)
7 Wastes identified in Lean:
1. Partially done work
2. Extra Processes
3. Extra features
4. Task switching (no focus on 1 task is bad)
5. Waiting (for approval, for signoff)
6. Motion (any motion that has no value)
7. Defects
Kanban Development
- Kanban in Japanese is signboard.
5 principles of Kanban
1. Visualize the work
2. Limit WIP
3. Manage flow
4. Make process policy explicit
5. Improve collaboration
Little’s Law
Cycle times are proportional to queue lengths (predict completion times based on queue)..
Tuckman’s five stages of Team Development
Forming - Start. No many conflicts or communication (Role of PM: DIRECTING)
Storming - Team has conflicts. Learn about other’s ideas & disagree (Role of PM: COACHING)
Norming - team agrees upon the best way to build deliverables (Role of PM: SUPPORTING)
Performing - team performs well without conflicts (Role of PM: DELEGATING)
Adjourning - Project completed. Team reassigned
Decomposing Requirements
Epics (Entire software or lots of features combined) – Features (particular pieces of software which could be used as a release) – Stories (little breakdown of features) – Tasks (actual work to be done)
User Stories
User story is within a product backlog, which is typically 1–3 days of work. Every requirement is a user story.
Common Structure of User story:
As a <User> I <need to/ want> goal, so that <Value>
Example of User Story:
As a payroll clerk (User type), I want to be able to view a report
of all payroll taxes (goal), so that I can pay them on time (value)</Value></User>
3Cs of user stories:
Card
Conversation
Confirmation
INVEST Independent Negotiable Valuable Estimable Small Testable
Types of Iterations
Iteration 0
- set the stage for development efforts
- doesn’t build anything
Development iteration
- actual product increment work
Iteration H (hardening sprint or release)
- done at end to clean up code or producing documentation
Iteration 0 — Dev iteration — Dev iteration — Dev iteration — Iteration H
Spikes (few hours of work before iteration is done)
Architectural Spike
- Periods of time for proof of concept
Risk-Based Spike
- Team investigates to reduce or eliminate risk
- A risk-based spike is when the team investigates whether a new method, process, or tool will reduce or eliminate risks
Story maps and Product Roadmap
- Story map is a high level planning tool showing when features will be delivered and what is included in each release
- When story maps are complete, they form the product roadmap
Lead Time and Cycle Time
Lead time - how long something takes to go through the entire process
Cycle time - part or subset of the lead time. How long it takes to go through a part of the process.
Cycle time is related to the work in progress (WIP). You want to limit your cycle time or WIP
Cycle time = WIP/Throughput
Throughput - Amount of work that can be done in a time period
Variance and Trend Analysis
Variance - how far apart things are from the plan(?)
Trend - provides insight into future issues
Lagging metrics - provides info on something that has already happened
Leading metrics - provides info on something that is or is about to happen
