Domain 1 - Agile Principles and Mindset (16% 19Q)

This domain focuses on the agile mindset, its fundamentals value and principles, the agile methodologies
and agile leadership.
The Agile Triangle: Agile Triangle is reversal of traditional triangle which means agile teams allows
scope to vary within the fixed parameters of cost and time. We aim to deliver the most value by X Date
within X Budget
Cost Time (Variable)

Scope (Fixed)
Agile Manifesto: The Agile Manifesto includes a statement of four values and twelve guiding principles.
The Four Values: The values of the left are more valued than the values on the right
Individual and Interactions over processes and tools: Focusing early on developing the individuals
involved in the project and emphasizing productive and effective interactions help set up a project for
success.
Working Software over comprehensive documentation: Focus on the purpose or business value we’re
trying to deliver rather than paperwork.
Agile approach to documentation is based on “just enough, Just in time and sometimes just because.
Just Enough- Agile Documentation should be barely sufficient – just enough to cover our needs.
Just-in Time – We don’t need to spend extra time to keep it updated as our requirements and designs
changed.
Just because – When documentation is required or requested.
Customer Collaboration over contract negotiation: This value reminds to be flexible and
accommodating rather than fixed and uncooperative.
Responding to change over following a plan.
The Twelve Principles
Satisfy customer with great systems: Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
Welcome change: Welcome changing requirements, even late in development. Agile processes harness
change for the customer’s competitive advantage.
Deliver Frequently: Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
Work with business: Business people and developers must work together daily throughout the project.
Motivate People: Build projects around motivated individuals. Give them the environment and support
they need and trust them to get the job done.
Face to Face Communication: The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
Measure Systems done: Working software is the primary measure of progress.
Maintain Sustainable pace: Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.
Maintain Design: Continuous attention to technical excellence and good design enhances agility.
Keep Simple: Simplicity–the art of maximizing the amount of work not done–is essential.
Team creates architecture: The best architectures, requirements, and designs emerge from self-
organizing teams.
Reflect and adjust: At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
Agile Methodologies:
Scrum: It is popular and light weight agile method which focuses at the project management level on
prioritizing work and getting feedback.
Scrum Pillars: The theory behind Scrum is based on the three pillars of transparency, inspection, and
adaptation.
Transparency: This involves giving visibility to those responsible for the outcome. Ex: Creating a
common definition of what done means to ensure that all stakeholders are in agreement.
Inspection: This involves doing timely check of how well the project is processing towards its goals.
Adaptation: This involves adjusting the team process to minimize further issues if an inspection shows
a problem or undesirable trend.
Scrum Values: There are 5 fundamentals values –
Focus, courage, Openness, commitment, and Respect
Scrum Process:
Sprints: A sprint (iteration) is a time-boxed iteration of one month or less in which team builds a
potentially releasable product.
Most Sprint are 1 or 2 weeks long and is like a mini project.
During Sprint, no changes are made that would affect the sprint goal. The scope might be clarified or
renegotiated as new information becomes available, but if a change has to made to the development team
members; that wouldn’t be done during a sprint.
A product owner can only cancel the sprint before a timebox is over if the sprint goal becomes obsolete
because of a change in business direction or technology conditions. When this happens, any incomplete
product backlog items are re-estimated and returned to product backlog.
The sequences of Activities within each sprint consists of sprint planning meeting, a development
period that include daily scrums, a sprint review meeting, and a sprint retrospective meeting.
Scrum Team Roles: Scrum teams are made up of the development team, the product owner, and the
Scrum Master.
Development Team: It is a group of professionals who build the product increments in each sprint.
 The members of the development teams are self-organizing – that is, they are empowered to manage
their own work.
 Scrum teams are also cross – functional; each team member can fulfil more than one of the roles needed
to complete the work.
Product Owner: Person is responsible for maximizing the value of the product by managing the
product backlog, or list of the work to be done. This includes ensuring that the work backlog items are up
to date and accurately prioritized based on business value.
 Product Owner is responsible for making sure that the business and the team have a shared
understanding of the project vision, goals, and the details of the work to be done.
 Product Owner is responsible for keeping the backlog prioritized and updated with the help of scrum
master or development team.
Scrum Master: This person is servant leader to the development team, removing any roadblocks to
their Progress, facilitating their events/meetings, and coaching the team members.
 Scrum Master assists Product owner in updating Product backup and communicates project vision,
project goals and details of the backlog items to the development team.
Scrum Activities/Events/Ceremonies: There are 5 Meetings. The last four of these meetings are planned
opportunities for inspection and adaptation.
1.Product Backlog Refinement: Everyone involved in the project gathers to discuss and update the
items in the backlog
2.Sprint planning meeting: Everyone gathers to determine what will be delivered in the upcoming sprint
and how that work will be achieved.
The product owner presents the updated backlog items, and the group discusses them to ensure that they
have a shared understanding.
The development team focuses what can be delivered in the sprint based on their estimates, projected
capacity, and past performance
3.Daily scrums: It is a 15- min timeboxed meeting that is held at the same time and place everyday while
the team is working toward the sprint goal.
The Scrum Master makes sure that the meeting happens every day and follows up on any identified
obstacles.
It is mainly for development team to synchronize their work and reports any issues they are facing.
The scope of this meeting is limited to 1) What have I done since the last daily scrum, 2) What do I plan
to do today and 3) Are there any impediments to my progress?
4.Sprint review meeting: It is held at the end of the sprint and includes the development team, Scrum
Master, and Product Owner.
The team demos the increment, or evolving product built in the sprint to product owner.
The Product Owner inspect the work to see whether it is acceptable – deciding if this is done or
explaining what is missing.
The team and the product owner discuss the increment and the remaining items in the product backlog
and makes any changes needed to the backlog and decides what to work on next.
5.Sprint retrospective meeting: After Sprint review, but before next sprint planning meeting, the
development team holds their final inspect and adapt activity for the sprint.
This meeting is specifically for development team members.
They discuss gather lesson learned and looks for opportunities for improvement
Scrum Artifacts: There are 3 tangible items that are produced or used by the team during a sprint
1.Product Increment: During each sprint, the members of the development team build an increment of
the solution.
To maximize the chances that the product increment will be acceptable, the team and product owner
needs to agree upon a definition of done before the team begins working on it so that everyone has shared
understanding of what “done” will look like for that increment.
2.Product Backlog: The product backlog is a prioritized list of all the work that needs to be done to build
the product – it serves as the single source for all the product requirement.
The items in the backlog are prioritized by the product owner and sorted so that the highest-priority
work is at the top of the list. The team will always try to work on these top-priority items.
The backlog is constantly being refined and process of adding more detail to the backlog items and
refining the estimates is the backlog refinement.
3.Sprint Backlog: The sprint backlog is the subset of items in the product backlog that have been
selected as the goal of specific sprint
It serves as a highly visible view of the work being undertaken and may only be updated by the
development team.
Scrums of Scrums: With larger projects multiple scrum teams might need to coordinate their work with
the approach called Scrums of Scrums.
This is a meeting in which representative from each team reports their progress to representative of
other team
Participant answer 4 questions: 1) What have I done since the last daily scrum, 2) What do I plan to do
today, 3) Are there any impediments to my progress and 4) Are you about to put something other Team
way?
This meeting takes place on a regular schedule, but not necessarily daily.

Extreme Programming (XP): It is an agile method that is focused on software development best
practices.
XP Core Values: The core values of XP are:
1.Simplicity: This value focuses on reducing complexity, extra features, and waste.
2.Communication: This value focuses on making sure all the team members know what is expected of
them and what other people are working on.
3.Feedback: The team should get impressions of suitability early
4.Courage: It takes courage to allow our work to be entirely visible to others.
5.Respect: When people work together as a team, and everyone is accountable for the success or failure
of the project.
XP Team Roles:
1.Coach: It acts as mentor to the team, guiding the process and helping the team members stay on track.
The coach is also a facilitator – helping the team become more effective by reinforcing communication
both within and outside the team.
2.Customer: Business representative who provides the requirements, priorities, and business direction for
the project
Defines the product to be built, determines the priorities of its features, and confirms that the product
actually works as intended.
3.Programmer: They are developers who build the product by writing and implementing the code for
requested user stories.
4.Tester: They provides quality assurance and help the customer define and write acceptance tests for the
user stories. This role may be filled by the developers if they have required skills.
XP Core Practices:
Whole Team: The whole team practice is the idea that all the contributors to an XP project sit together in
the same location, as members of a single team.
XP emphasizes the notion of generalizing specialists, as opposed to role specialists. In other words,
anyone who is qualified to perform a role can undertake it—the roles are not reserved for people who
specialize in one particular area.
This practice helps optimize the use of resources, since people who can perform multiple jobs are able
to switch from one role to another as the demand arises.
The practice also allows for more efficient sharing of information and helps eliminate the possibility
that people in certain roles will be idle or overstretched at certain points in the project.
Planning Games: XP has two primary planning activities, or planning games—
1.Release planning: A release is a push of new functionality all the way to the production user. A project
typically has one or more releases, with no more than one or two releases in a single year.
During release planning, the customer outlines the functionality required, and the developers estimate
how difficult the functionality will be to build.
Armed with these estimates and priorities, the customer lays out the plan for the project delivery. Since
the initial attempts at estimating will likely be imprecise, this process is revisited frequently and improved
as the priorities and estimates evolve.
2.Iteration planning: Iterations are the short development cycles within a release that Scrum calls
“sprints.”
Iteration planning is done at the start of every iteration.
The customer explains what functionality they would like to see in the next iteration, and then the
developers break this functionality into tasks and estimate the work.
Based on these estimates and the amount of work accomplished in the previous iteration, the team
commits to the work items they think they can complete in the two-week period.
Small Releases: Frequent, small releases to a test environment are encouraged in XP, both at the iteration
level, to demonstrate progress and increase visibility to the customer, and at the release level, to rapidly
deploy working software to the end users.
Quality is maintained in these short delivery time frames by rigorous testing and through practices like
continuous integration, in which suites of tests are run as frequently as possible.
Customer Tests: As part of defining the required functionality, the customer describes one or more test
criteria that will indicate that the software is working as intended.
The team then builds automated tests to prove to themselves and the customer that the software has met
those criteria.
Collective Code Ownership: In XP, any pair of developers can improve or amend any code. This means
multiple people will work on all the code, which results in increased visibility and broader knowledge of
the code base.
This practice leads to a higher level of quality; with more people looking at the code, there is a greater
chance defects will be discovered.
There is also less of an impact to the project if one of the programmers’ leaves since the knowledge is
shared.
Code Standards: Although collective code ownership has its advantages, allowing anyone to amend any
code can result in issues if the team members take different approaches to coding. To address this risk,
XP teams follow a consistent coding standard so that all the code looks as if it has been written by a
single, knowledgeable programmer.
The specifics of the standard each team uses are not important; what matters is that the team takes a
consistent approach to writing the code.
Sustainable Pace: XP recognizes that the highest level of productivity is achieved by a team operating at
a sustainable pace.
While periods of overtime might be necessary, repeated long hours of work are unsustainable and
counterproductive.
The practice of maintaining a sustainable pace of development optimizes the delivery of long-term
value.
Metaphor: XP uses metaphors and similes to explain designs and create a shared technical vision.
These descriptions establish comparisons that all the stakeholders can understand to help explain how
the system should work. For example, “The billing module is like an accountant who makes sure
transactions are entered into the appropriate accounts and balances are created.”
Even if the team cannot come up with an effective metaphor to describe something, they can use a
common set of names for different elements to ensure everyone understands where and why changes
should be applied.
Continuous Integration: Integration involves bringing the code together and making sure it all compiles
and works together.
This practice is critical, because it brings problems to the surface before more code is built on top of
faulty or incompatible designs.
XP employs continuous integration, which means every time a programmer checks in code to the code
repository (typically several times a day), integration tests are run automatically. Such tests highlight
broken builds or problems with integration, so that the problems can be addressed immediately.
Test-Driven Development: Testing is a critical part of the XP methodology. To ensure good test
coverage so that problems can be highlighted early in development, XP teams often use the practice of
test-driven development.
With this approach, the team writes the acceptance tests prior to developing the new code.
If the tests are working correctly, the initial code that is entered will fail the tests, since the required
functionality has not yet been developed. The code will pass the test once it is written correctly.
The test-driven development process strives to shorten the test-feedback cycle as much as possible to
get the benefits of early feedback.
Refactoring: Refactoring is the process of improving the design of existing code without altering its
external behavior or adding new functionality.
By keeping the design efficient, changes and new functionality can easily be applied to the code.
Refactoring focuses on removing duplicated code, lowering coupling (dependent connections between
code modules), and increasing cohesion.
Simple Design: By focusing on keeping the design simple but adequate, XP teams can develop code
quickly and adapt it as necessary.
The design is kept appropriate for what the project currently requires. It is then revisited iteratively and
incrementally to ensure it remains appropriate.
XP follows a deliberate design philosophy that asks, “What is the simplest thing that could work?” as
opposed to complex structures that attempt to accommodate possible future flexibility.
Since code bloat and complexity are linked to many failed projects, simple design is also a risk
mitigation strategy.
Pair Programming: In XP, production code is written by two developers working as a pair. While one
person writes the code, the other developer reviews the code as it is being written—and the two change
roles frequently.
This practice may seem inefficient, but XP advocates assert that it saves time because the pairs catch
issues early and there is a benefit in that the two people will have a larger knowledge base.
Working in pairs also helps spread knowledge about the system through the team.
Kanban: It encourages modification and adaptation
Lean Product Development: It deals with developing new and better products.
Lean Principles (ABD2E2O)
1. Using visual management tools
2. Identifying customer-defined value
3. Building in learning and continuous improvement
Lean Concepts: Lean focuses on seven core concepts:
1.Eliminate waste: To maximize value, we must minimize waste. Waste can be partially done work,
delays, handoffs, unnecessary features, etc. Therefore, to increase the value we are getting from projects,
we must develop ways to identify, and then remove waste. (DE2MPWT)
Waste Description Example
Partially done work Work started, but not completed Code waiting for testing
Specs waiting for development
Extra Processes Extra work that does not add value Unused documentation
Unnecessary approvals
Extra Features Features that are not required Gold-plating
Technology features
Task Switching Multi-tasking between several different People assigned to multiple
projects when there are context-switching Projects
penalties
Waiting Delays waiting for reviews and approvals Waiting for prototype reviews
Waiting for document approvals
Motion The effort required to communicate or move Distributed teams
information or deliverables from one group Handoffs
to another; if teams are not co-located, this
effort may need to be greater
Defects Defective documents or software Requirements defects
that needs correction Software bugs
2.Empower the team: Rather than taking a micromanagement approach, we should respect the team
members’ superior knowledge of the technical steps required on the project and let them make local
decisions to be productive and successful.
3.Deliver fast: We can maximize the project’s return on investment (ROI) by quickly producing valuable
deliverables and iterating through designs.
4.Optimize the whole: We aim to see the system as more than the sum of its parts. We go beyond the
pieces of the project and look for how it aligns with the organization.
5.Build quality in: Lean development doesn’t try to “test in” quality at the end; instead, we build quality
into the product and continually assure quality throughout the development process, using techniques like
refactoring, continuous integration, and unit testing.
6.Defer decisions: We balance early planning with making decisions and commitments as late as
possible.
7.Amplify learning: This concept involves facilitating communication early and often, getting feedback
as soon as possible, and building on what we learn.
Kanban: Kanban board plays an important role to show the work items in each stage of the production
process as defined by the team.
Kanban Five Principles
Visualize the workflow: Having some way to visualize the workflow for intangible and invisible work
is very important for organizing, optimizing, and tracking it.
Limit WIP (work in progress): Restricting the amount of work in progress improves productivity,
increases the visibility of issues and bottlenecks, and facilitates continuous improvement.
Manage flow: By tracking the flow of work through a system, issues can be identified, and changes can
be measured for effectiveness.
Make process policies explicit: It is important to clearly explain how things work so the team can have
open discussions about improvements in an objective, rather than an emotional or subjective, way.
Improve collaboratively: Through scientific measurement and experimentation, the team should
collectively own and improve the processes it uses.
Kanban Pull System: Kanban teams employ a “pull system” to move work through the development
process, rather than planning their work in timeboxed iterations.
Each time a Kanban team completes an item of work, it triggers a “pull” to bring in the next item they
will work on.
Whenever there is an empty slot on the board, that’s a signal for the team to pull work from the previous
stages, if there are any items available. So work is continuously being pulled from the left side of the
board to the right side
Work in Progress (WIP): Work in progress (WIP), is the term given to work that has been started but
has not yet been completed. Excessive levels of WIP are associated with a number of problems,
including:
1.WIP consumes investment capital and delivers no return on the investment until it is converted into an
accepted product. It represents money spent with no return, which needs to limit.
2.WIP hides bottle necks in processes that slow overall workflow (or throughput) and masks efficiency
issues.
3.WIP represents risk in the form of potential rework since there may still be changes to items until those
items have been accepted. If there is a large inventory of WIP, there may in turn be a lot of scrap or
expensive rework if a change is required.
WIP Limits in Kanban: It refers to capping the number of items that can be in a given state of progress,
as defined by the columns on the team’s Kanban board. Once the limit at the top of a column is reached,
no new items may be moved into that column until another item is moved out. Lower WIP actually
increases a team’s productivity—it speeds up the rate at which the work is completed. The aim of WIP
limits is to optimize throughput of work, not to optimize resource utilization.
Feature Driven Development (FDD): In Feature-Driven Development (FDD) approach the project team
will first develop an overall model for the product, build a feature list, and plan the work. The team then
moves through design and build iterations to develop the features.
FDD Practices:
1.Domain object modeling: In this practice, teams explore and explain the domain (or business
environment) of the problem to be solved.
2.Developing by feature: This involves breaking functions down into two-week or shorter chunks of work
and calling them features.
3.Individual class (code) ownership: With this practice, areas of code have a single owner for
consistency, performance, and conceptual integrity.
4.Feature teams: These are small, dynamically formed teams that vet designs and allow multiple design
options to be evaluated before a design is chosen. Feature teams help mitigate the risks associated with
5.individual ownership.
6.Inspections: These are reviews that help ensure good-quality design and code.
7.Configuration management: This involves labeling code, tracking changes, and managing the source
code.
8.Regular builds: Through regular builds, the team makes sure the new code integrates with the existing
9.code. This practice also allows them to easily create a demo.
10. Visibility of progress and results: This practice tracks progress based on completed work.
Dynamic Systems Development Method (DSD): Provides suitability filters for assessing how well an
approach fits a project.
Eight DSDM Principles:
1. Focus on the business need
2. Deliver on time
3. Collaborate
4. Never compromise quality
5. Build incrementally from firm foundations
6. Develop iteratively
7. Communicate continuously and clearly
8. Demonstrate control
Crystal: It consists of a family of situationally specific, customized methodologies that are coded by
color names. Each methodology is customized by criticality and team size, which allows Crystal to cover
a wide range of projects, from a small team building a low-criticality system (Crystal Clear) to a large
team building a high-criticality system (Crystal Magenta).
Servant Leadership: Agile promotes a servant leadership model that recognizes it is the team members,
not the leader, coach, or ScrumMaster, who get the technical work done and achieve the business value.
The servant leadership approach redefines the leader’s role in relation to the team. It focuses the leader on
providing what the team members need, removing impediments to their progress, and performing
supporting tasks to maximize their productivity.
There are four primary duties a leader performs in this role of serving the team:
1.Shield the team from interruptions: Servant leaders need to isolate and protect the team members
from diversions, interruptions, and requests for work that aren’t part of the project. Business
representatives should make requests during the iteration planning meeting or submit them to the product
owner for inclusion in the backlog.
The leader must protect the team from external diversions. Breaking people away from focusing on the
project work and moving them back and forth between initiatives saps productivity. If the leader is able to
shield the team from noncritical external demands, their productivity will be enhanced. Physically co-
locating team members is an effective way to prevent external interference.
2.Remove impediments to progress: Servant leaders need to clear obstacles from the team’s path that
would cause delay or waste. These obstacles may include documentation or compliance activities that
divert the team from completing the objectives of the current iteration.
3.Communicate (and re-communicate) the project vision: Communicating and re-communicating the
project vision is critical to successfully leading a team. Only if stakeholders have a clear image of the
goals for the completed product and project can they align their decisions with, and work toward, the
common project objective. Communicating and re-communicating the project vision helps stakeholders
recognize these divergences and bring them back in-line with the project’s objectives.
4.Carry food and water: Servant Leader should provide the essential resources a team needs to keep
them nourished and productive. Such resources could include tools, compensation, and encouragement.