Agile Primer Flashcards
1
Q
Key Drivers
A
- Scalability, To meet client need with higher efficiency by addressing the growing demand of work with multiple teams distributed across locations
- Profitability: Makes the best talent and cost advantages available to the client
- Achieving Cost Arbitrage: Reduces investments on large teams since various locations around the globe can deliver the same service as work happens across multiple locations in varied time zones
- Talent Management: Availability of teams with varied skills for optimal composition, of developers, architects, DBA, QA and functional experts across locations
2
Q
Brand ambassadors
A
Are usually the senior technical experts or business/domain experts who ensure the flow of information between dispersed Sprint teams of the project.
3
Q
Boundary spanners
A
Are the people who focus on enabling communication between multiple Sprint teams, ensuring that cross-team dependencies are identified and planned to avoid any blocking.
4
Q
Product Owner:
A
Responsible for business value and ROI (Return of Investment), requirement prioritization Specifies the overall project goal and vision
5
Q
Scrum Master:
A
Works closely with the Product Owner. Monitors tasks and progress and shields the team from external interferences and removes impediments
6
Q
Scrum Team:
A
Commits to deliverables and delivers independently while working in close collaboration
7
Q
Senior Technical Architect and Designers:
A
: Involves in early stage of the project to decide code structure and design standards. Resolves key design issues and ensures implementation of standards across the teams
8
Q
Integration Managers/Experts:
A
Keeps focus on integration challenges from early lifecycle
9
Q
Testing Experts:
A
Creates test strategies to be implemented by all teams
10
Q
12 pillars of the Agile Manifesto
A
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily co-operation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated and trustworthy individuals
- Continuous attention to technical excellence and good design
- Simplicity
- Self-organizing teams
- Regular adaptation to changing circumstances
11
Q
Agile methods
A
- Extreme Programming (XP),
- Dynamic System Development Method (DSDM),
- Feature Driven Development (FDD)
- Lean
- Kanban
12
Q
Scrum
A
- An iterative and incremental framework for application or product development.
- The development of the project is achieved through iterative cycles known as Sprints.
- At the start of each Sprint, a crossfunctional team selects items from Product Backlog and commits to complete the items by the end of that particular Sprint.
- The Sprints are strictly timeboxed and occur sequentially
- *Time box – It means a fixed time is allotted for an activity*
13
Q
Scrum Roles
A
- Product Owner
- Team
- Scrum Master
14
Q
Product owner
A
- Providing the vision of the project to the team
- Maximizing the value of the project and the work of the Scrum Team
- Managing the Product Backlog
- Clearly expressing Product Backlog items
- Prioritizing the items in the Product Backlog to best achieve goals and mission of the project
- Ensuring that the Product Backlog is visible, transparent and clear to all about what the team will work on next
15
Q
Scrum Team
A
- Team size in Scrum should ideally be around seven persons
- The team is recommended to be cross-functional with skills in analysis, development, testing, interface design, database design, architecture, documentation.
- It is self-organized and decides what to commit and how best to accomplish that commitment
- The accountability of the work product belongs to the team as a whole
16
Q
Scrum Master
A
responsible for ensuring that the Scrum team adheres to Scrum values, practices, and rules.
- Helps the Scrum team to adopt Scrum
- Helps the team to learn and apply Scrum to achieve the desired objective of the project
- Does not tell people what to do or assign tasks, but facilitates the process by supporting the Team to organize and manage itself
- Serves the Team, protects them from outside interference, educates and guides the Product Owner and the Team in use of Scrum
- Facilitates Scrum events
- Coaches the Team to be cross-functional.
- Removes impediments for the Team’s progress
17
Q
Scrum Events
A
- Release Planning Meeting
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective.
18
Q
Release Planning Meeting
A
The purpose of release planning is to establish a plan and goals, which the Scrum Team and the rest of the organization can understand and communicate.
Release planning aims to come up with a strategy to:
- Turn the vision into a successful project in best possible way
- Meet or exceed the desired customer satisfaction and return on investment
19
Q
Sprint Planning
A
The work to be performed in a Sprint is planned in the Sprint Planning Meeting. This plan is created by collaborative work of the entire Scrum Team. The Sprint Planning Meeting consists of two parts, each one being a time-box of half of the Sprint Planning Meeting duration.
- In the first part, team plans what will be delivered as part of the Sprint
- In the second part, team plans how to build this functionality
20
Q
Daily Scrum
A
The Daily Scrum meeting is a 15-minute time-boxed event for the Team to synchronize activities.
- What he or she has accomplished since last meeting
- What he or she is going to do before the next meeting
- What issues/obstacles are in his or her way
21
Q
Sprint Review
A
A Sprint Review Meeting is held at the end of the Sprint.
The Sprint Review includes the following:
- Product Owner identifies what has been ‘Done’ and what has not been ‘Done’
- Team demonstrates the work that has been ‘Done’ and answers questions about the increment
- Product Owner discusses the Product Backlog as it stands
- The entire group discusses on what to do next
22
Q
Sprint Retrospective
A
Sprint Retrospective occurs after the Sprint Review
- Inspect the last Sprint with regards to people, relationships, process and tools
- Discuss what went well during the Sprint, what problems were faced and how they were solved
- Identify and prioritize the major items that went well and those which could have been done differently. These include Scrum Team composition, meeting arrangements, tools, ‘Definition of Done’ and methods of communication
- Create a plan for implementing improvements to the way the Scrum Team works.
23
Q
Scrum Artifacts
A
Represent work or value in various ways
24
Q
Product Backlog
A
The Product Owner articulates product vision at the start of the project.
25
Release Burndown
The Release Burndown chart reflects the remaining Product Backlog items across the releases.
26
Sprint Backlog
The Sprint Backlog is a highly visible, real-time picture of the work that the Team plans to accomplish during the Sprint. It is the subset of Product Backlog items
27
Sprint Burndown
Sprint Burndown chart is a graphical representation reflecting the remaining effort for all the tasks that were committed during the Sprint, versus time (no. of days remaining in the Sprint)
28
XP Practices: Planning Game
The key planning process of Extreme Programming is called planning game to ensure work is planned incrementally. It is divided into two parts
* Release Planning
* Iteration Planning
29
Release Planning
This is a planned meeting to shortlist requirements to be included in the releases planned and timeline of each release. It has three phase
1. Exploration: Create User Story
2. Commitment: Team commits to date and functionality
3. Steering: Adjust plan and requirement change
30
Iteration Planning
This is a planning meeting by the Team to decide upon the tasks and activities, to accomplish requirements planned for the iteration.
1. Exploration: Create task cards
2. Commitment: Task estimation and allocation
3. Steering: Perform the tasks
31
Pair Programming
Entails the same wherein two persons work on the same code. While one programmer is doing the coding, focusing on the code and program level details, the other programmer has the big picture and continuously reviews the code.
32
Test Driven Development
Test Driven development is an Extreme Programming practice in which, developer writes the automated test cases before the actual code is written.
33
Whole Team
In Extreme Programming, the entire Team functions as a whole
34
Continuous Integration:
an Extreme Programming practice where the code base is integrated on a frequent basis from the start of the feature development.
35
Refactoring
It is the practice of regular improvement of existing design and code without affecting the functionality.
36
Small Release
Frequent and small release is another XP practice which is common across various Agile development methodologies
37
Coding Standards
In order to reduce defects in coding, protocols consisting of style and format for the source code are agreed upon by the Team. Rules need to be as per the standards defined by language vendors and/or customized by the Team.
38
Collective Code Ownership
Pair Programming practice of XP brings in the collective ownership of the overall code.
39
Simple Design
XP recommends the simple and best way to implement code.
40
Metaphor: It
It is usually a naming convention,
41
Sustainable Pace:
Team members need not work for more than 40 hours per week (ideally) to meet project deadlines as it hampers repeatable, predictable and consistent delivery.
42
XP Roles
Customer
* Creates user stories and prioritizes user stories for each release
* Addition/Modification/Deletion of user stories for each release
Programmers:
* Estimates for user stories along with the Team
* Builds the users stories as per the standards
Coach:
* Monitors XP process implementation and issue resolution on XP practices
* Mentors team members
Tracker:
Monitors the progress and alerts the Team
43
Kanban
Kanban is a Japanese word where Kan means “Visual” and ban means “Card” or “Board”. It is a framework which helps organizations and teams to visualize the work, identify to eliminate bottlenecks and achieve dramatic operational improvements in terms of throughput and quality.
This is best suited where the dynamic and frequent changing requirements are to be delivered faster e.g. Production Support types of projects which deals with tickets.
44
Kanban Principles
* Visualize work stages
* Limit Work in progress
* Measure and Manage flow
* Setup Explicit Process and Policies
* Implement feedback loop
45
Kanban board 4 stages
1. Received.(could be called as “Backlog” also)/ Acknowledged,
2. In-progress,
3. UAT
4. Done.
46
WIP limit
should not be more than the number of people working on the stage.
47
Kanban Metrics
* Cycle time / production lead time: This is time that elapses from the moment a team starts actively working on a task till the moment they are done
* Customer lead time: Time that elapses from the moment a customer or a user submits the work item to a backlog to the moment they can use it
* Throughput: A measure of productivity or efficiency which is typically a number of features delivered over time
* Work in Progress (WIP): Number of work items that are currently in progress in the whole process.
* Customer Takt: Available work time / customer demand during available work time
48
Cumulative Flow Diagram (CFD)
Cumulative Flow Diagram helps the team to visualize overall effort spent and the project progress. It is an important tool for the teams adopting Kanban.
49
Scrumban
Scrumban is a hybrid of Scrum and Kanban and was originally designed as a way to transition from Scrum to Kanban.
advantages:
* Improved quality
* Short lead time
* Kaizen (continuous improvement)
* Minimizing waste (all that is not adding value to the customer)
* Just-in-time approach to decisions whenever needed
50
Scrumban Situations
* Maintenance projects
* Event-driven work
* Help desk/support
* Hardening/packaging phases
* Projects with frequent and unexpected user stories or programming errors
* Sprint teams focused on new product development
* Work preceding Sprint development (backlog, R&D)
51
Scaled Agile
talks about executing large projects in agile mode
52
Scrum of Scrums Meeting
a forum where Scrum Team members have the opportunity to transparently discuss issues affecting their project and collaborate
53
Scaling Agile frameworks used at enterprise level
* Scaled Agile Framework (SAFe)
* Disciplined Agile Delivery (DAD)
* Large Scale Scrum (LeSS)
54
Scaled Agile Framework (SAFe)
primarily intended at scaling agile at portfolio or enterprise level. SAFe is based on proven success patterns for implementing Lean-Agile IT, software and systems development at enterprise scale.
55
Disciplined Agile Delivery (DAD)
a process decision framework that is people-first, learning-oriented hybrid agile approach to IT solution delivery
56
DAD roles
Primary Roles
* Stakeholder
* Team Lead
* Product Owner
* Team Member
* Architecture Owner
Secondary Roles
* Specialist
* Independent Tester
* Domain Expert
* Technical Expert
* Integrator
57
Large Scale Scrum (LeSS)
Scrum applied to many teams working together on one product
It’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible
58
InfyAgile
introduces regular collection and analysis of metrics information at a Sprint level, Release level and Project level to improve feedback loops and bring timely course correction
59
key drivers for adopting high maturity practices of CMMI
* Improve Project Performance
* Process Performance Capabilitiea
* Predictability
* Contractual Obligation
* Scalability
* Better Quality
* Institutionalization
60
CMMI
contains practices that cover project management, process management, systems engineering, hardware engineering, software engineering and other supporting processes used in development and maintenance.
61
goals in CMMI
Specific Goals, unique characteristics that must be present to satisfy the process area.
Generic Goals, A generic goal describes the characteristics that must be present to institutionalize processes in a given process area. An example of a generic goal is ‘The process is institutionalized as a defined process’.
62
Process Area
a cluster of related practices in an area that when implemented collectively, satisfies a set of goals considered important for making improvement in that area
63
Quick Function Point Analysis (FPA)
estimation method as a ‘Standardized Estimation Technique’ at proposal and post release stage for overall sizing and story point estimation at iteration/Sprint stage for user stories.
64
Configuration management (CM)
an important process area in Agile projects because of the need to support frequent change in the requirements, frequent builds (usually daily), multiple baselines and multiple CM supported workspaces (for example used by individuals or team members or for pair-programming).
65
continuous integration
The working software code is continuously added to the code base
66
key challenges of Agile practices
* Lack of understanding of the practice
* Unavailability of cross-functional teams
* Getting self-organized and disciplined
* Collaborative team functioning rather than command and control
67
Scrum Key Practices
* Daily Scrum
* Release and Sprint Planning
* Sprint Reviews and Retrospectives
* Burndown Charts
* Product Backlog and Sprint backlog
* Story Point Estimation
68
Extreme Programming Key Practices
* Pair Programming
* Test Driven Development
* Continuous Integration and Testing
* Refactoring
* Simple Design
* Release and Iteration Planning
* Small Releases
* Shared understanding through collective code ownership and metaphor
69
Feature-driven Development Key Practices
* Domain object modeling
* Inspections
* Regular Build
* Feature Teams
* Development by Feature
70
Dynamic System Development Method Key Practices
* Prototyping
* Functional Modeling
* Continuous Testing
* Time Boxed development
* Requirement Workshops
* MoSCoW Prioritization
71
Lean Key Practices
* Waste Elimination
* Value Stream mapping
* Pull system
* Measurements
72
Kanban Key Practices
* Limit work in process
* Visualize and manage workflow
* Implement Feedback Loops
73
Scrumban Key Practices
* Just-in-time cards
* Daily scrum (planning, review, retrospective as needed)
* Continuous Improvement
74
Management Practices
Requirement Workshop
Burndown Charts, Burndown charts are graphical representation of work or effort remaining to get completed against the time.
Mid Sprint Demo, These demos are important when Sprint duration is little longer, example 3 or 4 weeks.
Standardized Estimation Technique
Quantitative Project Management
Measurement Focus, done at sprint level and project/managing level
75
Epics
high-level product or application development requirements which can be broken down into list of sequential user stories.
76
3C technique
Card (User Story), Conversation and Confirmation (Acceptance Criteria).
77
User Stories should be:
* Independent
* Negotiable
* Valuable
* Estimable
* Small
* Testable
78
Product Backlog
a prioritized list of simplified requirements which is necessary to accomplish the intended delivery of the product/feature
79
Product Owner
takes business decisions with inputs from stakeholders and has complete ownership and appropriate authority on Product Backlog
80
Build automation
key engineering practice by Extreme Programming which ensures that code is integrated from the beginning.
81
Continuous Integration
software development practice of integrating the source code into a central repository frequently/continuously
82
Spike:
This is a method used when team follows ‘makeshift’ kind of development, which is meant for validating different technical approaches that are considered for developing another complex feature.
83
Tracer Bullet
: This is a process where a research development is done so that next developments are created on top of it
84
Social Knowledge Management:
Team shares the knowledge through discussion forums, wiki, blogs rather than having dedicated classroom sessions.
85
DevOps transition:
One of the challenges that large Agile teams (where we have separate teams for Ops and dev) face is the transition from development to support team.
86
CMMI
for development is considered as a reference model to cover activities for both products and services.
