1.

FUNDAMENTALS OF AGILE

THE GENESIS OF AGILE

The timeline above contains some key moments in the history of agile, and some other
interesting events taking place at that same time for reference.
 1970 – Waterfall Model was created (by Winston W Royce.) Interestingly enough some
of the risks he called out have been realized and are much of the reason we saw agile
come into existence.
 “I believe in this concept, but the implementation described is risky”.
 “The required design changes are likely to be so disruptive that the software
requirements upon which the design is based and which provides the rationale for
everything…. are violated. Either the requirements must be modified, or a substantial
change in the design is required. In effect the development process has returned to the
origin and one can expect up to a 100-percent overrun in schedule and/or costs.”
 1970 – Also, Gas is 36 cents per gallon. Wut?!
 1990 – Jeff Sutherland and Ken Schwaber conceived the Scrum process in the early 90’s.
 1991 – Also, the release of Nirvana’s Nevermind signified the start of the Grunge era that
would dominate the music scene up to the mid-90’s.
 1995 – Scrum is codified in 1995 in order to present it at a conference in Austin, Texas
(US) and published the paper “SCRUM Software Development Process”.
 Scrum was first tried and refined at Individual, Inc., Fidelity Investments, and IDX
(now GE Medical). These weren’t simply startups with greenfield development
efforts.
 1995 – Also, OJ Simpson was found NOT GUILTY!
 2001 – In February 2001, Jeff and Ken were amongst 17 software development leaders
creating the Manifesto for Agile Software Development. – Their goal was to take all the
good things they’ve learned and create a “charter” for others to use. By this time there
had been many variations of agility that evolved. The manifesto was taking the best of
the best and boiling it down to principles rather than a framework or methodology.
 2001 – Also, Lord of the Rings comes out in Theaters.

INTRODUCTION AND BACKGROUND- AGILE MANIFESTO AND PRINCIPLES

The Agile Manifesto is a brief document built on 4 values and 12 principles for agile software
development. The Agile Manifesto was published in February 2001 and is the work of 17
software development practitioners who observed the increasing need for an alternative to
documentation-driven and heavyweight software development processes.
The 4 Agile Values
The agile mentality has 4 overarching values differentiating it from traditional software
development processes.

For more information about the 4 values of agile software development, read our overview of the
4 agile values.
The 12 Agile Principles
In addition to its 4 values, The Agile Manifesto also outlines 12 principles for agile development
practices. These 12 principles emphasize things like “early and continuous delivery of valuable
software” and “continuous attention to technical excellence.” Ready for more? Read our
full overview of the 12 agile principles.
The 4 Agile Manifesto Values
Agile software development is built on these four values, which also serve as priority areas for
teams to concentrate their efforts-
1) Individuals and Interactions over Processes and Tools- The first value focuses on the
people, which is at the heart of the Agile process. The best procedures and resources can be used
to aid your projects, but they won't be effective unless your staff members are giving it their all.
Your crew is your most important asset. Here, communication is crucial because it allows people
to share ideas and produce better goods when they do so frequently.
2) Working Software Over Comprehensive Documentation- Teams would spend hours
producing lengthy documents containing technical specs, needs, and more before Agile
techniques were completely embraced. These lists would be created before programmers began
writing the code, which meant that the entire process would be delayed because it would take so
long to generate the documentation.

The goal of the Agile methodology is to condense the content in such documents into user
stories. The developer can begin working on the software and make it ready for release using the
information provided in these stories. The goal is to hasten the product launch and make early
adjustments to the product in order to enhance the software in subsequent iterations.
3) Customer Collaboration over Contract Negotiation- The Agile Manifesto's third value
recognizes the significance of customer collaboration. Contrary to contract negotiation, which
entails discussing product requirements with the client before the project begins and then
renegotiating those deliverables at a different stage, this is regarded as being preferable.
Customers are not involved in the development process, which causes teams to miss out on user
feedback that could improve the product.

You can routinely solicit feedback from your clients and consider their suggestions when you
involve them in the development process. While the programme is still being developed,
developers may learn a lot about users' unique demands and use that information to build the best
possible user experience.
4) Responding to Change over Following a Plan- Traditional approaches favoured as slight
change as possible since they understood that major changes may require a lot of time and
money. The goal was to develop a thorough plan that had a clear, linear course and avoided
obstructions whenever possible.

This inflexible approach is turned on its head by the Agile philosophy, which contends that
change can be advantageous to the software development process. By accepting change, you
make yourself more receptive to new opportunities and methods to grow. Agile teams can react
rapidly and make changes continuously because they operate in brief, iterative cycles. In the end,
this produces quality products.
Join our Agile Programme Management course to learn more about Agile Project
Management!
The 12 Agile Manifesto Principles
1) Satisfy Clients through Early and Continual Delivery-
Original Formulation- “Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.”
What is the most important piece of software development advice? Keep your client satisfied.
Instead of making your users wait for a single, large delivery, try to give software to them
frequently during the course of the project.
2) Welcome Fluctuating Requirements-
Original Formulation- “Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.”
Software engineers should be able to manage project changes made at the last minute. They
ought to be adaptable enough to swiftly transform these adjustments into enhancements,
reducing delays and ensuring a constant flow of work.
3) Deliver Value Persistently-
Original Formulation- “Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.”
Agile teams divide lengthy projects into manageable timeframes to ensure regular delivery.
These time frames are referred to as sprints in the Scrum methodology, and they typically last
between one and four weeks.
4) Communicate Better for Better Synchronization-
Original Formulation- “Business people and developers must work together daily throughout the
project.”
As discussed, Collaboration is essential to Agile Project Management. Daily communication
among project stakeholders reduces the possibility of misunderstanding and guarantees that
everyone's objectives stay congruent.
5) Reduce Micromanagement-
Original Formulation- ‘Build projects around motivated individuals. Give them the environment
and support they need and trust them to get the job done.”
The project is more likely to succeed if you have the correct individuals for the job. Choose the
ideal team carefully, give them the tools they require, and have faith in their ability to produce
outstanding results.
6) Communicate in Person-
Original Formulation- “The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.”
When teams can communicate face-to-face, barriers can be quickly broken. Co-locating teams is
a smart idea whenever it can help with communication and information flow. Zoom is an
excellent alternative to phone or email in a remote workplace, allowing employees to
communicate more effectively via video.
7) Produce a Working Software-
Original Formulation- “Working software is the primary measure of progress.”
You must produce top-notch software if you want to keep your clients happy. Your top priority
and success metric should be that; everything else is just a side note.
8) Maintain a Sustainable Working Rate-
Original Formulation- “Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace indefinitely.”
Agile teams must retain their speed and consistency throughout the whole project life cycle. This
indicates that they are resilient to delays in an environment that is continually changing.
9) Consistent Excellence Enhances Agility-
Original Formulation- “Continuous attention to technical excellence and good design enhances
agility.”
Agile emphasises continual improvement and innovation rather to merely producing one
excellent product and calling it a day. Every iteration ought to provide some form of new
improvement, feature, or update.
10) Simplicity is Vital-
Original Formulation- “Simplicity — the art of maximizing the amount of work not done — is
essential.”
The agile methodology emphasises meeting requirements and doing just enough to finish a task
without overcomplicating things. Avoid wasting time on extra stages that don't actually improve
your product.
11) Self-managing Teams Create More Value-
Original Formulation- “The best architectures, requirements, and designs emerge from self-
organizing teams.”
Why supervise teams when they are capable of working independently? You give ideas greater
room to grow and eventually provide better results by letting them operate within their own
structures.
12) Regularly Reflect at your Work Progress-
Original Formulation- “At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behaviour accordingly.”
Regular performance reviews allow you to identify problems before they become serious and
potential areas for development. Self-reflection is an important part of a good Agile team since it
enables them to stop using unhealthy practices and develop new ones.
OVERVIEW OF SCRUM
Scrum is a simple process model that is mainly used in software development. It focuses
on people, collaboration and self-managing. Reflecting, learning and adapting play an
important role. The goal is to deliver usable product increments regularly, to deal with
unpredictability, to solve complex problems and to become better and better. Scrum is based on
specific values, principles and practices. Below you will find an overview of the Scrum
Framework with its Roles, Artifacts and Events.

Th
e Scrum Framework as described in the Scrum Guide 2020
The Scrum Framework
Scrum is simple and consists only of a few elements. However, these must be applied
consistently for Scrum to be successful. In the above overview you can see the essential elements
of Scrum, which are also briefly described in the Scrum Guide. These are then described in a
summary below but in detail in the in my comprehensive book about Agile Project
Management and Scrum.
A Scrum project is carried out in successive, short work cycles (iterations) with the same
duration of a maximum of 30 days. These cycles are called Sprints in Scrum. In Sprints,
requirements from the Product Backlog, which is the prioritized collection of all requirements,
are converted into a potentially shippable Product Increment. This means that every Sprint
produces executable, tested and documented software that is of benefit to the customer..
Before the Scrum project can start, the requirements for the first Sprints must first be defined.
The requirements are usually described in user stories and each user story then represents
a Product Backlog Item (PBI). These are then filled and prioritized in the Product Backlog. New
requirements can be added to the Product Backlog at any time during project execution, existing
requirements can be changed or omitted.
At the start of each Sprint, the Sprint Planning is carried out. The Developers select so many of
the high prioritized items from the Product Backlog that they can implement in a Product
Increment in the Sprint. These requirements then define the Sprint Backlog. Then the Developers
start and realizes the requirements in the Sprint. The Daily Scrum takes place every day at the
same time and at the same place. This is a short meeting where the Developers exchanges ideas,
coordinates the work and identify impediments.
At the end of the Sprint, the results are reviewed by the Scrum Team and the stakeholders in
the Sprint Review and future adjustments are defined. After the Sprint Review, the Sprint
Retrospective takes place, in which the Scrum Team reflects on the collaboration, workflows and
impediments and defines improvement measures for the following Sprints.
The 3 Roles in Scrum
Scrum defines three roles, their tasks and accountabilities. The roles are:
 Product Owner
 Developers
 Scrum Master
All three roles together are called Scrum-Team. In addition to these three “official” Scrum roles,
there are other important roles or stakeholders: Users, management, business and IT
representatives.
The 5 Scrum Events
Five events are defined in Scrum. These are activities and meetings related to the Sprint. The
following events are listed in the Scrum Guide:
 Sprint
 Sprint Planning
 Daily Scrum
 Sprint Review
 Retrospective
With the exception of the Sprint, which serves as a container for all other events, each Scrum
event is a formal opportunity to inspect and adapt something. These events are specifically
designed to enable critical transparency and inspection.
The 3 Scrum Artifacts
Besides the three roles and five events, Scrum also defines three artifacts. Artifacts are products
that are developed as intermediate or final results in software development. In Scrum, the
purpose of these is to provide maximum transparency about the key information in the project
and to structure the collaboration. The artifacts represent business value or work. They will help
the Scrum Team and all participants in the project with gaining the same understanding of the
information. These artifacts are the:
 Product Backlog
 Sprint Backlog
 Shippable Product Increment
Besides the three artifacts described in the Scrum Guide, there are others that have proven
themselves in Scrum practice. These are, for example:
 Product Vision
 Release Plan
 Taskboard
 Impediment Backlog
 Burndown Chart
 Team Backlog
 Velocity Chart
 Rules for Collaboration
 Themes and Parking Lot
In the Scrum Guide, you will find the chapter “Artifact Transparency” with the “Definition of
Done”. This is about the transparency of the defined artifacts regarding information, decisions,
quality and completion

EXTREME PROGRAMMING
Extreme programming is a software development methodology that’s part of what’s collectively
known as agile methodologies. XP is built upon values, principles, and practices, and its goal is
to allow small to mid-sized teams to produce high-quality software and adapt to evolving and
changing requirements.

What sets XP apart from the other agile methodologies is that XP emphasizes the technical
aspects of software development. Extreme programming is precise about how engineers work
since following engineering practices allows teams to deliver high-quality code at a sustainable
pace.
Extreme programming is, in a nutshell, about good practices taken to an extreme. Since pair-
programming is good, let’s do it all of the time. Since testing early is good, let’s test before the
production code is even written.
A Brief History of Extreme Programming
XP’s origin dates back to the 90s when Kent Beck — who would later become one of the authors
of the Agile Manifesto — created it when hired to lead Chrysler’s Comprehensive Compensation
System team.
The project had started in 1993 and by 1996 hadn’t progressed much. Since Beck was new to
managing a team, he decided the best course of action would be to teach his team members the
techniques and practices that worked for him. They started applying practices such as pair
programming and TDD with great success. Ron Jeffries — a friend of Beck and another author
of the Agile Manifesto — was brought in to coach C3’s team.
In 1999, Kent Beck formalized the practices, principles, and values of XP in his book Extreme
Programming Explained: Embrace Change.
How Does Extreme Programming (XP) Work?
XP, unlike other methodologies, is very opinionated when it comes to engineering practices.
Besides practices, XP is built upon values and principles.
Values provide purpose to teams. They act as a “north star” to guide your decisions in a high-
level way. However, values are abstract and too fuzzy for specific guidance. For instance: saying
that you value communication can result in many different outcomes.
Practices are, in some ways, the opposite of values. They’re concrete and down to earth, defining
the specifics of what to do. Practices help teams hold themselves accountable to the values. For
instance, the practice of Informative Workspaces favors transparent and simple communication.
Principles are domain-specific guidelines that bridge the gap between practices and values.

XP Values
The XP values: communication, simplicity, feedback, courage, and respect. Let’s look at each
one of them in more detail.

Communication: Lack of communication prevents knowledge from flowing inside a team. Often,
when there’s a problem, someone already knows how to solve it. But lack of communication
prevents them from learning about the problem or contributing to its solution. So, the problem
ends up being solved twice, generating waste.
Simplicity: Simplicity says you always strive to do the simplest thing that works. It’s often
misunderstood and taken as the simplest thing, period, ignoring the “that works” part.
It’s also crucial to remember that simplicity is highly contextual. What’s simple for one team, is
complex for another depending entirely on each team’s skills, experience, and knowledge.
Feedback: Feedback in more traditional, waterfall-like software development methodologies
often is “too little, too late”.
XP, however, embraces change and XP teams strive to receive early, constant feedback. If there
is a need to course-correct, XPers want to know that as soon as possible.

Feedback comes in many shapes and sizes. When you’re pair programming, the comments of
your peer are vital feedback. So are the opinions from other team members about an idea,
including the customer who, ideally, is a member of the team.
Tests are another source of precious feedback that go beyond the test results. Whether writing
tests is easy or hard is feedback too. If you’re having a hard time writing tests, your design is
probably too complex. Listen to the feedback and simplify your design.
Something that sounds like a great idea might not work that well in practice. So, finished code is
also a source of feedback, as is a deployed product.
Finally, bear in mind that there’s such a thing as too much feedback. If a team generates more
feedback than it can handle, important feedback may drop off the radar. It’s essential to then
slow down and figure out what causes the feedback excess and fix it.
Courage: Kent Beck defines courage as “effective action in the face of fear.” As a software
engineer, you have plenty to be afraid of and therefore plenty of opportunities to show courage.
It takes courage to speak the truth, especially unpleasant ones — for instance, honest estimates.
Giving and receiving feedback also takes courage. And it takes courage to avoid falling into
the sunk cost fallacy and discard a failing solution that received substantial investments.
Respect: A fundamental premise of XP is that everyone cares about their work. No amount of
technical excellence can save a project if there’s no care and respect.
Every person is worthy of dignity and respect, and that includes, of course, the people affected
by a software development project. When you and your team members respect and care about
each other, the customer, the project, and its future users, everyone gains
XP Principles
Principles provide more specific guidance than values. They’re guidelines that illuminate the
values and make them more explicit and less ambiguous.

For instance, based on the value of courage alone, you could conclude that it’s advisable to
tackle a big change at once in the program. However, the principle of Baby Steps tells us that big
changes are risky. So, you want to favor tiny ones instead.
Humanity: Humans create software for humans, a fact that’s often overlooked. But taking human
basic needs, strengths, and weaknesses into account creates products humans want to use. And a
work environment that gives you the opportunity for accomplishment and growth, the feeling of
belonging, and basic safety, is a place where you more easily take others’ needs into account.
Economics: In XP, teams heed the economic realities of software development all the time, they
constantly assess the economic risks and needs of the project.
For instance, they’d implement user stories according to their business value rather than
technical concerns.
Mutual Benefit: Following XP, you avoid solutions that benefit one party to the detriment of
another. For instance, extensive specifications might help someone else understand it, but it takes
you away from implementing it, and it delays it for your users.
A mutually beneficial solution is to use automated acceptance tests. You get immediate feedback
on your implementation, your colleagues get precise specifications in code, and users get their
features sooner. Plus, all of you get a safety net against regressions.

Self-similarity: If a given solution works at a level, it might also work at a higher or lower level.
For instance, obtaining early and constant feedback is at play at various levels in XP.
 at the developer level, programmers receive feedback from their work using the test-first
approach;
 at the team level, the continuous integration pipeline integrates, builds, and tests the code
several times a day;
 at the organization level, the weekly and quarterly cycles allow teams to get feedback and
improve their work as needed.
Improvement: According to the principle of improvement, teams don’t strive for perfection in an
initial implementation but for a good enough one, and to then learn and improve it continuously
with feedback from real users.
Diversity: You and your coworkers benefit from a diversity of perspectives, skills, and attitudes.
Such diversity often leads to conflict, but that’s okay.
Conflict and disagreement are opportunities for better ideas to arise when everyone plays by the
values of courage and respect. Courage to express opposing points of view, respect to expressing
those in a civil and empathetic way. And all of this is an exercise in effective communication.
Reflection: Great teams reflect on their work and analyze how to be better. XP offers plenty of
opportunities for that. Not just in its weekly and quarterly cycles, but in every practice it
promotes.
Feelings are important to consider in addition to logical analysis. Your gut can inform you before
you can reason about something. And so can talking to non-technical people, they can ask
questions that open up entirely new possibilities.
Flow: Traditional software development methodologies have discrete phases, which last for a
long time and have few feedback and course correction opportunities. Instead, software
development in XP occurs in activities that happen all of the time, in a consistent “flow” of
value.
Opportunity: Problems are inevitable in software development. However, every problem is an
opportunity for improvement. Learn to look at them that way and you’re far more likely to come
up with creative, goal-oriented solutions that also serve to prevent them from happening again.

Redundancy: The redundancy principle says that if a given problem is critical, you must employ
many tactics to counter it.
Take defects. There isn’t a single tactic that can prevent all defects from escaping to production.
So XP’s solution is to stack a bunch of quality measures. Pair programming, tests, continuous
integration. Each a single line of defense, together a virtually impenetrable wall.
Failure: Failure isn’t waste when it results in knowledge. Acting and quickly learning what
doesn’t work is way more productive than inaction caused by indecision in choosing between
many options.
Quality: Often people think there’s a dilemma between quality and speed.
It’s the opposite: pushing for quality improvements is what makes you go faster.
For instance, refactoring — changing the structure of the code without altering its behavior — is
a practice that makes the code easier to understand and change. As a result, you become less
likely to introduce defects to the code, which allows you to deliver more value sooner by not
having to fix bugs.
Baby Steps: Big changes are risky. XP mitigates that risk by doing changes in tiny steps, at all
levels.
Programmers write code in tiny steps using test-driven development. They integrate their code to
the mainline several times a day, instead of only every few weeks or even months. The project
itself occurs in short cycles rather than long-lasting phases.
Accepted Responsibility: In XP, responsibility should be accepted, never assigned.
Responsibility should be accompanied by the authority to make decisions on what you’re
responsible for. The reverse also applies. You don’t want people making decisions if they don’t
have to live with their consequences.
Similarities and Differentiators
How does XP differ from traditional, non-agile methodologies?
Extreme programming, being part of agile, it’s all about embracing and welcoming change rather
than following rigid plans. It’s about iterative design rather than a big design upfront.
XP differs dramatically from traditional methodologies — i.e. waterfall — by avoiding long-
lasting phases.
 Instead of a planning phase, in XP you plan at the start of each development cycle which
usually lasts just a week.
 Instead of testing episodes, you test your application as soon as you can: that is before the
actual code is implemented.
 Instead of implementing features in isolation during long implementation phases and then
struggling to merge your contributions to the main line, you work in small chunks and
integrate those chunks as often as possible.

How is XP Different From The Other Agile Methodologies?

Extreme programming, by nature, has a lot in common with the other agile methodologies but
it’s also unique among them.
Most other development methodologies don’t say much, if anything at all, on how to do the
work.. XP, on the other hand, is highly opinionated when it comes to that and puts great
emphasis on software engineering practices.
Extreme Programming vs. Scrum
Scrum is a framework for helping teams develop complex projects in an adaptive manner. Scrum
doesn’t dictate how developers do the work. XP, as mentioned, puts much emphasis on good
programming practices.
Also, XP is obviously about programming. Scrum, on the other hand, can be applied to any
project that benefits from an iterative approach.
XP accepts changes to its components. Teams are allowed and even encouraged to tweak the
practices according to their specific needs. The Scrum Guide, on the other hand, is adamant in
stating that “While implementing only parts of Scrum is possible, the result is not Scrum.”
Also, Scrum is a framework that you need to fill out with methodologies and practices for doing
the work.
That means that it’s not only possible to use XP and Scrum together but extremely
recommended.
Key Roles and Responsibilities
According to Kent Beck, a mature XP team shouldn’t rely on rigid roles, but recognize that roles
can be useful for beginner teams, until they start to get in the way of collaboration.
That said, there are some common roles that people associate with XP:
 Customer: ideally, there should be a real customer on-site to answer questions, prioritize
user stories or collaborate with acceptance testing. When this isn’t possible, this role
could be fulfilled by a customer representative.
 Programmers: in an XP team, programmers estimate the effort needed to complete tasks
and stories, write automated tests, and implement the stories.
 Coach: Having a coach isn’t required, and many teams have achieved success without
one. However, having someone experienced in XP to coach a team can ensure the team
members follow the practices, turn them into habits and don’t revert to the old ways.
 Tracker: A tracker tracks the team’s progress metrics and talks with every team member
to identify roadblocks and figure out solutions. The tracker calculates the metrics that
indicate how well the team is doing, such as velocity and burndown charts, or the team
uses a digital scrum or kanban board that calculates them automatically.
Methods and Techniques
Methods and techniques are the practices in XP. They fall into three main groups: software
engineering, work environment, and project management.
FEATURE DRIVEN DEVELOPMENT
Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic
software process. The term "client" in FDD is used to represent what Agile Modeling (AM)
refers to as stakeholders or eXtreme Programming (XP) calls customers. FDD was first
introduced to the world in 1999 via the book Java Modeling In Color with UML, a combination
of the software process followed by Jeff DeLuca's company and Peter Coad's concept of features.
FDD was first applied on a 15 month, 50-person team for a large Singapore bank in 1997, which
was immediately followed by a second, 18-month long 250-person initiative. A more substantial
description is published in the book A Practical Guide to Feature-Driven Development as well as
the Feature Driven Development web site.
As the name implies, features are an important aspect of FDD. A feature is a small, client-valued
function expressed in the form For example, "Calculate the total of a sale", "Validate the
password of a user", and "Authorize the sales transaction of a customer". Features are to FDD
as user stories are to Scrum - they're a primary source of requirements and the primary input into
your planning efforts.
As you see in Figure 1 there are five main activities in FDD that are performed iteratively. The
first is Develop An Overall Model, the initial result being a high-level object model and notes. At
the start of an initiative your goal is to identify and understand the fundamentals of the domain
that your system is addressing, and throughout the initiative you will flesh this model out to
reflect what you're building. The second step is Build A Features List, grouping them into related
sets and subject areas. These first two steps map to the initial envisioning effort of
AMDD (see Figure 2). Next you Plan By Feature, the end result being a development, the
identification of class owners (more on this in a minute), and the identification of feature set
owners. The majority of the effort on an FDD team, roughly 75%, is comprised of the fourth and
fifth steps: Design By Feature and Build By Feature. These two activities are exactly what you'd
expect, they include tasks such as detailed modeling, programming, testing, and packaging of the
system.
Figure 1. The FDD lifecycle.

Figure 2. The lifecycle of AMDD.

An FDD initiative starts by performing the first three steps in the equivalent
of the DAD's Inception phase or XP's "iteration 0", the goal being to identify
the scope of the effort, the initial architecture, and the initial high-level plan.
Construction efforts occur in two-week (or less) iterations, similar to XP or
DAD teams, with the team iteratively working through all five steps as
needed. As with other agile software development processes, systems are
delivered incrementally by FDD teams.
There are six primary roles on an FDD team: Project Manager, Chief
Architect, Development Manager, Chief Programmer, Class Owner, and
Domain Expert. An individual will take on one or more roles on a team as
you would expect. The concept of a class owner is where FDD differs from
XP. XP includes a practice called Collective Ownership the idea of which is
that any developer can update any artifact, including source code, as required.
FDD takes a different approach in that it assigns classes to individual
developers, so if a feature requires changes to several classes then the owners
of those classes must work together as a feature team to implement it. Just
like programming pairs will model storm to think something through before
they code it, so will feature teams.
FDD also defines a collection of supporting roles, including:
 Domain Manager
 Release Manager
 Language Guru
 Build Engineer
 Toolsmith
 System Administrator
 Tester
 Deployer
 Technical Writer
FDD's five steps are supported by several practices. The first is domain object modeling, the
creation of a high-level class diagram and supporting artifacts that describes the problem domain.
Developing by feature and individual class ownership are also good practices, as is having
developers work together in feature teams. Inspections are an important aspect of FDD. FDD
also insists on regular builds, similar to XP, and configuration management. Finally, FDD
promotes a best practice called reporting/visibility of results, similar to XP and AM's philosophy
of open and honest

LEAN SOFTWARE DEVELOPMENT

Lean Software Development (LSD) is an agile framework that is used to streamline &
optimize the software development process. It may also be referred to as Minimum Viable
Product (MVP) strategy as these ways of thinking are very much alike since both intend to
speed up development by focusing on new deliverables.
Toyota has been credited to inspire the lean development approach which is meant for
optimizing production and minimize waste. Seeing Toyota’s lean approach many other
manufacturing teams started to follow the same strategy. And it was first adopted in software
development in 2003.
Advantages of LSD :
LSD has proved to improve software development in the following ways :
1. LSD removes the unnecessary process stages when designing software so that it acts as a
time saver as simplifies the development process.
2. With a focus on MVP, Lean Software Development prioritizes essential functions so this
removes the risk of spending time on valueless builds.
3. It increases the involvement power of your team as more and more members participate
due to which the overall workflow becomes optimized and losses get reduced.
Key Principles of Lean Software Development :
There are 7 established lean principles that come with a set of tactics, practices, and processes
that builds more efficient software products :
1. Eliminating the waste
2. Fast Delivery
3. Amplify Learning
4. Builds Quality
5. Respect Teamwork
6. Delay the commitment
7. Optimizing the whole system
The below figure illustrates the principles of LSD :
LEAN SOFTWARE DEVELOPMENT (LSD) PRINCIPLE

Eliminating the Waste: To identify and eliminate wastes e.g. unnecessary code, delay in
processes, inefficient communication, the issue with quality, data duplication, more tasks in
the log than completed, etc. regular meetings are held by Project Managers. Which allows
team members to point out faults and suggest changes in the next turn.

Fast Delivery: Previously long time planning used to be the key success in business, but in
the passage of time it is found that engineers spend too much time on building complex
systems with unwanted features. So they came up with an MVP strategy which resulted in the
building products quickly that included a little functionality and launch the product to market
and see the reaction. Such an approach allows them to enhance the product on the basis of
customer feedback.
Amplify Learning: Learning is improved through ample code reviewing, meeting that is
cross-team applicable. It is also ensured that particular knowledge isn’t accumulated by one
engineer who’s writing a particular piece of code so paired programming is used.
Builds Quality: LSD is all about prevent waste, keeping an eye on not sacrificing quality.
Developers often apply test-driven programming to examine the code before it is written. The
quality can also be gained to get constant feedback from team members and project managers.
Respect Teamwork: LSD focuses on empowering team members, rather than controlling
them. Setting up a collaborative atmosphere, keep perfect balance when there are short
deadlines and immense workload. This method becomes very much important when new
members join a well-established team.
Delay the Commitment: In traditional project management it often happens when you make
your application and it turns out to be completely unfit for the market. LSD method
recognizes this threat and makes room for improvement by postponing irreversible decisions
until all experiment is done. This methodology always constructs software as flexible, so the
new knowledge is available and engineers can make improvements.
Optimizing the whole system: lean’s principle allows managers to break an issue into small
constituent parts to optimize the team’s workflow, create unity among members, and inspire a
sense of shared responsibility which results in enhancing the team performance.
Weakness in LSD :
 Make it scalable as other frameworks since it strongly depends on the team involved.
 It is hard to keep pace so it is not easy for developers to work with team members as
conflict may occur between them.
 It leads to a difficult decision-making process as it is mandatory for customers to clearly
set their requirements for the development not to be interrupted.
Lean Software Development is one of the proactive approaches that drives your body through
productivity and cleanliness. It closely connects to Agile methodology, knowledge-sharing
experience, fast product delivery. All processes and stages of development are accurately built
to deliver the end product at minimum cost in a timely manner.

AGILE PROJECT MANAGEMENT

What Is Agile Project Management?
Agile project management is an iterative methodology used to guide a project through its life
cycle. This means that it divides the project into multiple smaller parts or iterations.
Once completed, the project team and stakeholders review each part and provide feedback.
Iterations are often known as sprints, especially in Scrum (a popular APM method). The critique
of the work session, or sprint, then determines the next step to take in the project life cycle.
The benefit of this technique is that problems are easily spotted along the way so that the team
can solve them more efficiently. Making tweaks and fixing small issues as they arise can save a
lot of time and resources later on in the project. This is because, if not addressed, a small error
could become bigger and affect more features as the project progresses.
So, APM is a very useful approach to help successfully complete a project on time. It is usually
used in software development to allow for adaptability and flexibility as opposed to following a
more linear project path.
How Does Agile Project Management Work?
Agile teams use quick feedback and continuous adaptation in the development of their software.
They also need to continuously evaluate their time and costs to ensure that they are still on track.
APM uses velocity, burnup, and burndown charts instead of Gantt charts, which more traditional
project management approaches used to track progress.
This type of approach also does not require the constant presence of the project manager. In
APM, the role of the project manager gets distributed throughout the team. This requires
thorough and consistent collaboration and communication so that each team member stays on
track.
Principles Of Agile Project Management
There are 12 principles of Agile Project Management outlined by the Manifesto for Agile
Software Development:
 The highest priority in APM is customer satisfaction. You can ensure this by
delivering software early and continuously.
 Agile projects welcome any changes in requirements.
 Teams deliver software frequently.
 APM involves collaborations between the development teams and managers or
stakeholders every day.
 Projects are built around motivated people.
 Face-to-face interaction is the best form of communication.
 The main measure of the project’s progress is functional software.
 The development of the software needs to be sustainable. Teams should be able
to uphold a consistent pace throughout a project.
 There should be an emphasis on technical excellence and design.
 APM values simplicity.
 The best results come from self-organized teams.
 Reflection and adaptation are important.
 Agile Project Management With Scrum
Scrum is a type of agile project management that involves a small team and a Scrum Master. The
Scrum Master helps to solve or clear away any obstacles that the team faces during the
development of the project.
In Scrum methodology, teams complete work in cycles called sprints – as mentioned earlier.
They also meet every day to discuss their progress, tasks, and any issues they are facing that
need to be solved.
At the end of each sprint, teams review the completed work and have a discussion about how
they can improve the next sprint. This is known as a Retrospective. Sprints can last anywhere
from a couple of days to one to two weeks.
This approach to project management is very efficient and effective. Team members are in
constant communication so that they are all on the same page and can help each other find the
best solutions to problems that arise.
This is very beneficial in software development projects as it allows for fast development and
testing.
Agile Project Management Tools
Below are some of the top agile project management tools that can help your team stay on track
and make room for adjustments as you go.
monday.com
monday.com has several useful features that make APM easier. These include reporting, time-
tracking, calendar, planning, and more. It is suitable for small and large businesses alike. This
application can help you keep all your remote team members in the loop and track everyone’s
progress.
Nifty
Nifty is a collaborative workspace application for agile teams. With this tool, you can plan out
your project and make note of all milestones. Nifty is a great all-round tool for seeing an
overview of your entire project as well as daily tasks and progress.
SpiraTeam
SpiraTeam by Inflectra is an agile software development management software that helps
manage all aspects of your project. This includes iterations, requirements, tasks, releases, and
bugs. This software is a more comprehensive tool for APM and is specifically designed for agile
methodologies – including Scrum.
Wrike
Wrike is an online platform that allows agile teams to collaborate in real-time. It promotes
communication between teams and is simple and easy to use. This tool can help to streamline the
project workflow and connect remote team members.
ReQtest
Last but not least, ReQtest’s Agile Board feature can help you gain a more holistic view of your
progress throughout the project life cycle. It also enables you to link to requirements, test tasks,
and bug reports so that you can find everything easily. Our tool can help track sprints and
identify any bottlenecks in your project.
The Digital Project Manager recommends ReQtest as “the most useful” tool to manage
requirements.
Conclusion
Agile project management is an excellent methodology for software development. This is an
effective and efficient approach to meeting client requirements in time and within budget.

DESIGN AND DEVELOPMENT PRACTICES IN AGILE PROJECT

his article overviews design strategies for agile software development teams. These strategies are
critical for scaling agile software development to meet the real-world needs of modern IT
organizations. The Agile approach to design is very different than the traditional approach,
and apparently more effective too. It is important to understand:
 Agile Design Practices
 Agile Design Philosophies
 Design Throughout The Agile Lifecycle

1. Agile Design Practices

There is a range of agile design practices, see Figure 1, from high-level architectural practices to
low-level programming practices. Each of these practices are important, and each are needed if
your team is to be effective at agile design.
Figure 1. Agile design practices.

2. Agile Design Philosophies

1. Agile designs are emergent, they're not defined up front. Your overall system design
will emerge over time, evolving to fulfill new requirements and take advantage of new
technologies as appropriate. Although you will often do some initial architectural
modeling at the very beginning of an intiative during "sprint 0" this will be just enough
to get your team going. Agilists don't need to get a fully documented set of models in
place before you may begin coding (although sometimes, just sometimes, you may need
to perform look-ahead modeling).
2. Your unit tests form much of your detailed design documentation. With a test-driven
development (TDD) approach to development you write a test and then you write just
enough domain code to fulfill that test. An important side effect of this approach is that
your unit tests not only validate your code, they also form the majority of your design
documentation in the form of executable specifications. TDD is complementary
to AMDD and is actually scaled by AMDD.
3. Design models need to be just barely good enough. You don't need to model every
single detail in your models, the models don't need to be perfect, and they certainly don't
need to be complete. Remember the last time you coded from a design spec (if you ever
did)? Did you really look at all the fine-grained details? No, because you were competent
enough to handle the details yourself.
4. Multiple models. Effective developers realize that each type of model has its strengths
and weaknesses, therefore they need to apply the right model(s) for the job at hand.
Because software development is complex you quickly realize that you need to know
about a wide range of models in order to be effective. All of the models mentioned in this
newsletter, and more, are described at the Agile Models Distilled page.
5. You typically only need a subset of the models. Although there are many modeling
techniques available to your, the fact is that any given team will only require a subset.
Think of it like this: in your toolbox at home you have a wide array of screwdrivers,
wrenches, pliers, and so on. For any given repair job you will use only a few of the tools.
Different jobs, different tools. You never need all of your tools at once, but over time you
will use them in a variety of manners.
6. Each model can be used for a variety of purposes. A UML class diagram can be used
to depict a high-level domain model or a low-level design, not to mention things in
between. Use cases can be used to model the essential nature of a process or the detailed
system usage description which takes into account architectural decisions. Never
underestimate how flexible you can be with models.
7. Designers should also code. Whenever a model is handed over to someone else to code
there is significant danger that the programmer will not understand the model, will miss
some of its nuances, or may even ignore the model completely in favor of their own
approach. Furthermore, even when hand-offs are successful you will discover that you
need far more details in your models than if you had simply coded it yourself. In short,
separating design from programming is a risky and expensive proposition. It is far more
effective to have generalizing specialists on your team that can both design and code.
8. Prove it with code. Never assume your design works; instead, obtain concrete feedback
by writing code to determine if it does in fact work.
9. Feedback is your friend. Never forget that you are a mere mortal just like everyone else
on your team. Expect to receive feedback -- I suggest you actively seek it -- about your
work and be prepared to consider it and act accordingly. Not only will your system be the
better for it, you will likely learn something in the process.
10. Sometimes the simplest tool is a complex CASE tool. When it comes to requirements I
prefer inclusive tools such as paper and whiteboards, but when it comes to design I tend
to lean towards sophisticated tools which (re)generate code for me. Like my grandfather
always said, you should use the right tool for the job.
11. Iterate, iterate, iterate. With an iterative approach to development you work a bit on
requirements, do a bit of analysis, do a bit of design, some coding, some testing, and
iterate between these activities as needed. You will also iterate back and forth between
working on various artifacts, working on the right artifact at the right time.
12. Design is so important you should do it every day. It is critical to think through how
you're going to build something, to actually design it, before you build it. Your design
efforts may take on the form of a sketch on a whiteboard, a detailed model created with a
sophisticated modeling tool, or a simple test that you write before you write business
code. Agile developers realize that design is so important that they do it every day, that
design isn't just a phase that you do early in the initiative before getting to the "real
work" of writing the source code.
13. Design for your implementation environment judiciously. Take advantage of features
of your implementation environment, but be smart about it. Trade-offs are normal, but
understand the implications and manage the risks involved. Every time you take
advantage of a unique performance enhancement in a product (such as a database,
operating system, or middleware tool) you are likely coupling your system to that product
and, thus, reducing its portability. To minimize the impact of your implementation
environment on your systems, you can layer your software and wrap specific features to
make them appear general to their users.
14. Document complicated things. If it is complicated, then document it thoroughly. Better
yet, invest the time to design it so it is simple. Remember the AM practice Create Simple
Content.
15. Do not over document. You need to document your design, but you shouldn't over
document either. Remember, users pay you to build systems, not to document them.
There is a fine line between under documenting and over documenting, and only through
experience are you able to find it. Be as agile as possible when it comes to
documentation.
16. Don't get sidetracked by the data community. Unfortunately many within the data
community believe that you require a serial approach to design, particularly when it
comes to databases. This belief is the result of either not understanding evolutionary
development or some misguided need to identify the "one truth above all else".
Evolutionary database design techniques such as agile data modeling, database
refactoring, and database regression testing work incredibly well in practice.
17. Remember user experience (UX). To your end user, the user interface (UI) is the
system. The implication is that an important aspect of your design is the UX. For more
information, see Introduction to Agile Usability and How to Integrate Design Into Your
Agile Process.

TEST DRIVEN DEVELOPMENT

TDD and Agile
The TDD approach originates from the Agile manifesto principles and Extreme programming.
As the name suggests, the test process drives SDLC. Moreover, it’s a structuring practice that
allows developers and testers to obtain optimized code that proves resilient in the long term.
Agile development demands frequent feedback to develop the expected outcome. In simple
terms, one can also term Agile development as Feedback Driven Development.
Unit Testing is a modular approach followed in testing, single-single functionality or part of the
code tested without waiting for other of code to be completed. - From the Article, Unit Testing
Techniques and Best Practices
Steps for the same are given below –
 Firstly, add a test.
 Run all the tests and see if any new test fails.
 Update the code to make it pass the new tests.
 Rerun the test and if they fail, then refactor again and repeat.
What are the benefits?

TDD is a programming technique that enables the developer to take a small step during building
software. It gives a way to think through one's requirements or design before the developer
writes functional code. Consider an example, developer write some code, then compile it, and
then test it. Maybe there are chances of failure. In this case, it becomes easy to find and fix those
defects if a developer had written two new lines of code than a thousand. TDD is most efficient
and attractive way to proceed in smaller steps.
Below are the benefits of TDD
 Development expenses are reduced
 Improved Code Quality
 Quality is enhanced
 Shortened Time to Market
 More productive as compared to attempting to code in giant steps.
 Fewer Bugs.
 Higher quality software.
 Focus on single functionality at a given point in time.
RPA is an automation technology in which RPA developers automate repetitive, manual
business processes through different RPA tools. Source: RPA Testing Methodology
How it works?
 Firstly, add a test.
 Run all the tests and see if any new test fails.
 Update the code to make it pass the new tests.
 Rerun the test and if they fail, then refactor again and repeat.
Test Driven Development Workflow
It promotes the idea of each test case testing one piece of functionality at a time. The workflow
of it is as follows –
 Write a concise, minimal test for a new piece of functionality. This test will fail since the
functionality isn’t implemented yet (if it passes, one knows that the functionality either already
exists or that the test isn’t designed correctly).
 Implement the new functionality and run all tests, both the new and pre-existing ones. Repeat
until all tests pass.
 Clean up the code and ensure that all tests still pass, then return to step 1.

Why it is important?
 Requirements - Drive out requirement issues early (more focus on requirements in depth).
 Rapid Feedback - Many small changes Vs. One significant change.
 Values Refactoring - Refactor often to lower impact and risk.
 Design to Test - Testing driving good design practice.
 Tests as information - Documenting decisions and assumptions.
It helps the programmer in several ways, such as -
 Improve the code.
 Side by side, increasing the programmer’s productivity.
Using Test Driven Development concept in one's programming skills -
 It will save the developer's time which is wasting rework.
 Able to identify the error/problem quicker and faster.
 The programmer will write small classes focused only on a single functionality instead of writing
the big classes.
 Whenever the code base gets more prominent, it becomes tough to change and debug the code.
Moreover, there is a high chance of mess up of the code.
But, if developers are using its technique -
 Means developers have automated tests.
 Writing the test cases for the program is a safe side for the programmers.
 It becomes easy to view what the error is, where it is and how it is paralyzing one's code.
Need for Test Driven Development
 Ensures quality – It helps in ensuring the quality by focusing on requirements before writing the
code.
 Keeps code neat and tidy – It assists in keeping the code clear, simple, and testable by breaking it
down into small achievable steps.
 Maintains Documentation – It provides documentation about how the system works for anyone
coming into the team later.
 Repeatable Test and rapid change – It builds a suite of repeatable regression tests and acts as an
enabler for rapid change.
Test-Driven Development in Python is an approach in which we build a test first, then fail the
test, and finally refactor our code to pass the test. Source: TDD in Python

CONTINUOUS INTEGRATION
Continuous Integration Continuous Integration (CI) is the process of taking features from the
Program Backlog and developing, testing, integrating, and validating them in a staging
environment where they are ready for deployment and release. CI is the second aspect in the
four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration
(CI), Continuous Deployment, and Release on Demand (Figure 1). Figure 1. Continuous
integration in the context of the continuous delivery pipeline. Details Continuous integration is a
critical technical practice for each Agile Release Train (ART). It improves quality, reduces risk,
and establishes a fast, reliable, and sustainable development pace. With continuous integration,
the “system always runs,” meaning it’s potentially deployable, even during development. CI is
most easily applied to software solutions where small, tested vertical threads can deliver value
independently. In larger, multi-platform software systems, the challenge is harder. Each platform
has technical constructs, and the platforms must be continuously integrated to prove new
functionality. In complex systems comprised of software, hardware, and components and
services provided by suppliers, CI is harder still. But the fact remains: integrating and testing
components together frequently is the only practical way to fully validate a solution. As a result,
teams need a balanced approach, one that allows them to build quality in and receive fast
feedback on their integrated work. For purely software-based solutions, continuous integration is
relatively easy to achieve with modern tools. For more complex systems composed of hardware
and software, a ‘continuish integration’ approach is required (see the Enterprise Solution
Delivery article) to balance the economic trade-offs between frequency, the scope of integration,
and testing. The Four Activities of Continuous Integration As illustrated in Figure 2, SAFe
describes four activities associated with continuous integration: Develop describes the practices
necessary to implement stories and commit the code and components to version control Build
describes the practices needed to create deployable binaries and merge development branches
into the trunk Test end-to-end describes the practices necessary to validate the solution Stage
describes the practices necessary to host and validate the solution in a staging environment
before production Figure 2. Four activities of continuous integration Develop the Solution
Developing the solution refers to the implementation of stories by refining features from the
Program Backlog as may be needed and then coding, testing, and committing the work product
into the source control system. Testing in this activity tends to focus on unit and story-level
testing and most times requires test doubles (see Test-Driven Development) to replicate other
components or subsystems. Seven practices are associated with developing the solution: Break
features into stories – Splitting features into stories enables continuous delivery via small batches
and smooth integration. This may include creating user story maps to ensure that workflows are
designed to meet customer needs. Behavior-Driven Development (BDD) –BDD is a process
Product Owners and teams use to more thoroughly understand requirements and improve quality
by creating acceptance criteria and acceptance tests, and often automating them, before the code
is even written. BDD works with TDD and is more fully described here. Test-Driven
Development (TDD) – TDD involves writing the unit test first, then building the minimal code
needed to pass the test. This leads to better design, higher quality, and increased productivity.
TDD works with BDD and is more fully described here. Version control – Effective version
control allows teams to recover quickly from problems and to improve quality by making sure
the right components are integrated together. Aggregating assets under version control is a
leading indicator of continuous integration maturity. Built-in quality – Built-In Quality
prescribes practices around flow, architecture & design quality, code quality, system quality, and
release quality. Application telemetry – Application telemetry is the primary mechanism that
acquires and then uses application data to help determine the results of relevant hypotheses.
Threat modeling – In addition to the threat modeling done in the Architect activity of continuous
exploration, attention should be given during system design to possible vulnerabilities that may
be introduced into the system. Build the Solution During the build phase, teams continuously
integrate new code. This can be accomplished by automating the build and test tools to run upon
code commit. Passing versus not-yet-passing and broken automated tests are the real indicators
of progress. Automating code building enables teams to fix problems quickly, before they affect
larger parts of the system. Addressing a broken build should be the highest priority. A ‘gated
commit’ ensures software has passed the gate (e.g. unit tested, performance tested, and free of
known defects, etc.) before being checked into the main codebase or trunk. Code that passes the
gate is automatically integrated into the trunk; which removes the complications of managing
multiple branches. This trunk-based development helps to ensure the code can be reliably
released on demand without the need for costly code freezes or hardening iterations. There are
five practices which can help build the solution: Continuous code integration – Code commit
should automatically trigger compilation and testing of changes. Ideally, this happens on each
commit but should happen at least several times a day. Build and test automation – The
compilation process should be automated and include unit- and story-level tests to verify the
change. These tests often use test doubles to replicate other parts of the systems and enable fast
builds. Trunk-based development – Long-lived branches must be avoided. Teams should merge
back as quickly as they can, at least once per day, and all teams should work off a single trunk.
Gated commit – Committing to a single trunk is risky, as broken changes can impact many
teams. This is why only the changes that have been validated through the build and test process
are merged into the trunk. Application security – Code analysis tools inspect the code and third-
party packages for known vulnerabilities. Test the solution end-to-end While critical, automated
local story and component testing aren’t enough. In order to thoroughly test features, system-
level integration and testing are required. With the support of the System Team, the work of all
teams on the ART must be frequently integrated to assure that the solution is evolving as
anticipated, as Figure 3 illustrates. Figure 3. Integrating the work of all teams on the ART
System-level testing happens as frequently as possible during the iteration, ideally after every
commit. However, whatever the circumstances, such full-system integration must be
accomplished at least once per iteration. Otherwise, the late discovery of defects and issues
reflects back to earlier iterations, causing substantial rework and delays. There are five practices
which can help in end-to-end system testing: Test and production environment congruity –
Environment congruity assures that testing exercises the solution as it would behave in front of
live users and decreases the probability that defects will escape into production. Test automation
– Many types of tests need to be run: functional testing, integration testing, regression testing,
etc. The Agile Testing article details a testing matrix of what can and should be automated. Test
data management – To create stability, tests must be consistent and realistic, replicating
production as much as possible, and under source control. Service virtualization – Different
kinds of testing require different environments. Service virtualizations allow teams to simulate a
production environment without the costs and effort associated with creating and managing real
environments. Testing nonfunctional requirements (NFRs) – system attributes such as security,
reliability, performance, maintainability, scalability, and usability must also be thoroughly tested.
Continuous integration with suppliers – Suppliers bring unique contributions that can have a
significant impact on lead-time and value delivery. Their work must be continuously integrated
as well. It helps to adopt a shared integration cadence and establish objective evaluation
milestones. Validate on Staging Finally, the entire solution must be validated on a staging
environment, based on the following practices: Maintain a staging environment –A staging
environment, which matches production provides the place for such validation. Blue/Green
deployment – The blue/green pattern involves two environments–live (production) and idle
(staging). Changes flow continuously to the idle environment where they are staged until ready
to deploy to production. At that point, a switch is flipped (a load balancer is updated for
example), and the idle environment becomes the live environment, while the previous live
environment becomes the new idle environment. This enables continuous delivery, zero-
downtime deployment, and fast recovery from failures. System demo – This is the event where
stakeholders evaluate a solution’s readiness to be deployed to production. Enabling a Culture of
Continuous Integration Continuously integrating large and complex systems is a time-consuming
journey. The following section provides some suggestions for building a successful CI culture
and practice. Integrate often – The more frequently teams integrate, the quicker they find
problems. And the harder it is to do, the more often they need to do it—eliminating impediments
and adding automation along the way. This results in faster learning cycles and less rework.
Make integration results visible – When the integration process breaks, everybody should know
it broke and why. When it’s fixed, new tests should be added to detect the problem earlier and
prevent it from happening again. Fixing failed integrations is a top priority – Teams that just
keep working through integration failures fall short of the values and culture associated with
building a system that can be released into production at any time. To create the right sense of
urgency and importance needed to fix integration problems, teams often use flashing lights or
other notifications to draw attention to a broken build, and establish visible indicators displaying
the percentage of the time the system remains broken. Establish common cadence – Integration
points are more accessible when all the teams are moving at the same consistent rhythm. If full
CI can’t be accomplished during the course of an iteration, teams can make near-term trade-offs
on what can be integrated, while continuously improving their techniques and infrastructure
toward this goal. Develop and maintain proper infrastructure – Effective continuous integration
depends on the availability of test and staging environments. Infrastructure is, of course, an
investment. But Lean-Agile Leaders take the long view and make the investments necessary
today to increase velocity for the marathon ahead. Apply supportive software engineering
practices – Continuous integration is easier when the system is designed with those concerns in
mind. Test-first development and designing for testability call for more modular solutions and
separation of concerns, as well as using primary interfaces and physical test points. Enabling
Continuous Integration with DevOps Continuous integration involves crucial ‘development’
activities that originally inspired the ‘Dev’ in DevOps. These activities are focused on solution
development and pipeline flow through pre-production environments. Applying DevOps
thinking, practices, and tooling in this segment of the value stream enables rapid development,
frequent code integration, and built-in quality and compliance. As illustrated in Figure 4,
continuous integration is enabled by SAFe’s CALMR approach to DevOps (center) as well as
several practice domains (inner rings). Each of the four activities (in green) is a collaborative
effort that draws upon DevOps expertise from multiple domains to maximize delivery speed and
quality. Figure 4. DevOps enables continuous integration As an example, building solutions in
the continuous delivery pipeline crosses multiple DevOps domains. Checking code into version
control triggers the deployment pipeline to invoke automated merge, quality and security checks,
then to apply configurations stored as code to build shippable, full-stack binaries. Using DevOps,
this process typically turns source code into tested, deployable solutions in a matter of minutes.
All four continuous integration activities are enabled by DevOps, though with different
combinations of technical practices and tooling. For more detailed guidance on DevOps and how
it enables the continuous delivery pipeline, see the DevOps article series.

REFACTORING
Code refactoring is a process that involves restructuring a computer code base without adding new
features or changes to its external behavior. It generally consists of carrying out a series of small
changes to the code base that are minor enough to avoid introducing new errors. In other words, with
refactoring, you can simplify not from a functional point of view to increase software performance
and reduce potential errors but from a visual point of view. Refactoring improves the design of
existing code.

Why is it important?
There is a rule for all programmers - the code must be concise, well-structured and understandable to
the developers working with it. Even after a successful software development project, it is still
necessary to keep improving the system in order to provide new features and solutions. It so often
leads to code complexity as the enhancements are applied in a way that makes it harder to make
changes. Source code refactoring can help improve the code's maintainability and provide more
excellent readability. It can also help avoid standardization problems caused by the number of
developers contributing their own code. Besides that, refactoring helps minimize the amount of
technical debt that developers accumulate as a result of not taking advantage of opportunities to
improve the code.

Technical debt is the price a company will pay later for choosing a simpler, faster, yet less reliable
option today. Any compromise you make to release products or features faster in the present will
accumulate a greater volume of work to do in the future:
What are the benefits of code refactoring?
The indisputable benefits of refactoring:
 Improving the objective readability of the code by reducing or restructuring it.
 Encouraging developers to write software more thoughtfully, following a given style and criteria.
 Preparing a springboard for creating reusable pieces of code.
 Making it easier to find bugs in a large amount of code.
When to refactor
When adding features
The best time for refactoring is before adding new features or updates to existing code. Doing so can
help improve the product's quality. By cleaning the code base before adding new features or updates,
it helps to make the product more robust and easier to use in the future.
Rule of Three
1. When you are doing something for the first time, just get it done.
2. The second time around, you may be a bit faster, but the code still won't be as clean as it should be.
3. When you do something for the third time, start refactoring.
During a code review
This is the last chance to clean up the code before the product is launched. Doing so can help you
identify areas of the code that are worth fixing.
It's also a good time to start refactoring after the product has been launched. Since many developers
start working on code refactoring after the product has been released, it allows them to get more work
done before going on to the next project.

PAIR PROGRAMMING
Pair Programming Definition
Pair programming is a technique wherein two individuals collaborate on a single program. The
“driver” writes the code, while the “navigator” checks each line of code for errors.
Pair programming is a software methodology in agile in which two programmers work together
on a single workstation.
While one programmer, called the developer, writes the code, the other programmer, called the
observer or navigator, reviews every code line as it gets typed.
If the two programmers work together efficiently, it can significantly reduce
the development time, improve code quality, and decrease human error.
The programmers may also swap roles every few minutes to keep things fresh and lively in pair
programming.
It also helps the programmers share their knowledge by providing continuous feedback and
insights on the code. (Tap here to learn more about Chisel, the best product management
software.)

Pair programming and TDD

TDD (Test Driven Development) is a programming method in which we write a test first and
then implement it.
Not just using TDD and pair programming and developing using clean code and DDD (Domain
Driven Design) concepts are some of the most effective techniques. It helps to keep the codebase
maintainable.
It plays out, especially when working on a complex domain and business logic project.
When you have people who have been taught in TDD and can guide new programmers, pair
programming using TDD is an excellent approach.
Teaching TDD is crucial because numerous incorrect methods are displeased with TDD.
Most programmers connect by pairing programming to solve an issue without using TDD.
How does pair programming work?
One person is the “driver,” and the other is the “navigator” in pair programming. The driver is
the individual who is actively writing code at the keyboard. The navigator looks around, double-
checks the code, and maintains an eye on the larger picture.
Pair programmer’s alternate duties frequently to keep both pairs engaged. They also collaborate
on deciding which tasks to complete.
When working in a team, developers take turns playing two roles. At the same time, one
programmer is the driver. Writing the code, another one is the navigator, reviewing the code and
providing all necessary directions and information to the former.
The objective is to alternate these responsibilities at 15-minute to 1-hour intervals.
Some businesses employ pair programming, whereas others do not. That’s because pair
programming has both benefits and drawbacks that you should think about before applying it in
your organization.
How to do pair programming remotely?
Traditional pair programming and remote pair programming are very similar.
Pair programming involves you and another software developer (or prospective software
developer) sitting in front of a computer. And taking turns typing code using only one keyboard.
The driver is the one who is typing on the keyboard.
They will be in charge of considering the classes, variables, functions, and algorithms that must
get coded for the program to achieve its goal.
As they code, this individual will strive to verbalize as much of their thought process as possible.
The navigator is the other person. They’ll sit next to the driver, but they won’t be writing any
code.
Instead, the navigator will pay close attention to the code the driver is producing and will offer
advice and ideas as needed.
The navigator will offer suggestions and research answers to impending concerns and
challenges. Also, works as a sounding board for the driver’s thoughts.
The Driver and Navigator will trade roles regularly. Thus the navigator will now be the driver
and create the code. You can change responsibilities every 30–40 minutes or whenever you
finish developing a particular feature or function.
What are the strategies for effective pair programming?
Make plans together:
Plan what you’ll do and your objectives before you begin programming. Is this a new
construction project? Troubleshooting? Are you looking for someone to mentor a junior
developer?
Make sure you and your partner are on the same page. The most experienced developer may be
in charge of planning, but this isn’t necessary. Plan with your partner and include them in the
process.
Prepare for your pair programming session by following these steps:
 What is the goal, the task?
 The session’s duration
 When should positions be changed?
 Any interests that you have
Among the most significant errors developers make is swapping roles too frequently or not when
it comes to pair programming.
The frequency with which you must switch roles gets determined by your degree of experience.
And the duration of the session.
You can only swap one time if the session is less than 60 minutes long. Having only one person
lead could be more efficient if the session is shorter, but you can still switch halfway through.
Ensure to have a good internet connection and be in a place without much noise:
It’s good to turn on your video camera when pair programming, even if it’s unnecessary.
What you say is crucial. Your colleague will be more engaged if you use a video camera. Both
parties can have a more enjoyable session.
Always utilize headsets for audio communication. You don’t need to go overboard with
expensive professional audio equipment.
Everything which makes you feel at ease would suffice. A headset that allows you to hear the
other person clearly and that they can understand you is sufficient.
Limit micromanagement:
A developer micromanaging during a pair programming session is one of the most unpleasant
behaviors.
It is more common than you might think, and it defeats the point of pair programming. To create
a safe atmosphere for collaboration that encourages developers to share their knowledge.
Stay courteous:
The matching experience is made even worse by a lack of patience. When dealing with persons
of varying skill levels, this might happen. Especially if a more experienced developer doesn’t
give their partner enough time to comprehend their code.
It may be tempting to break their flow to rectify faults rapidly, but this would harm their flow
and confidence. You can always pen down your thoughts and come back to them later.
It will allow you to determine whether the issue is truly one that needs to get addressed or if it
got previously discussed.
Stay away from external distractions:
There are numerous hurdles and distractions to overcome, especially while working remotely.
Notifications by phone, emails, and door-to-door delivery, for example.
If you are leading the pair programming, these distractions are simpler to deal with. Still, you
may drift away occasionally if you are following.
While pairing, ignore any emails or other media. Schedule meetings that will not interfere with
your session. Take pauses and set aside time for things other than programming.
Continuous interactions:
Pair programming can be complicated. It’s easier when one person has difficulties keeping up or
feels like they’re working alone. To avoid this, communicate with your partner. It will make the
session more interactive.
AGILE TESTING
Agile is an iterative development methodology, where the entire project team participates in all
the activities. The requirements evolve as the iterations progress, through collaboration between
the customer and the self-organizing teams. As Coding and Testing are done interactively and
incrementally, during the course of development, the end-product would be of quality and
ensures customer requirements.
Every iteration results in an integrated working product increment and is delivered for User
Acceptance Testing. The customer feedback thus obtained would be an input to the next /
subsequent Iterations.

Continuous Integration, Continuous Quality

Continuous Integration is the key for Agile Development success. Integrate frequently, at least
daily such that you are ready for a release as and when required. Testing in Agile becomes an
essential component of all the phases of the development, ensuring continuous quality of the
product. Constant feedback from everyone involved in the project adds to the quality of the
product.
In Agile, communication is given utmost importance and the customer requests are received as
and when necessary. This gives the satisfaction to the customer that all the inputs are considered
and working quality product is available throughout the development.
Agile Methodologies
There are several Agile Methodologies that support Agile Development. The Agile
Methodologies include −
Scrum
Scrum is an Agile development method that emphasizes on team-centric approach. It advocates
participation of the entire team in all the project development activities.
XP
eXtreme Programming is customer-centric and focuses on constantly changing requirements.
With frequent releases and customer feedback, the end-product will be of quality meeting
customer requirements that are made clearer during the process.
Crystal
Crystal is based on chartering, cyclic delivery and wrap up.
 Chartering involves forming a development team, carrying out a preliminary feasibility
analysis, arriving at an initial plan and the development methodology.
 Cyclic Delivery with two or more delivery cycles focuses on the development phase and
final integrated product delivery.
 During Wrap up, deployment into the user environment, post-deployment reviews and
reflections are performed.
FDD
Feature Driven Development (FDD) involves designing and building features. The difference
between FDD and other Agile Development Methodologies is that the features are developed in
specific and short phases separately.
DSDM
Dynamic Software Development Method (DSDM) is based on Rapid Application Development
(RAD) and is aligned to the Agile Framework. DSDM focuses on frequent delivery of the
product, involving users actively and empowering the teams to make quick decisions.
Lean Software Development
In Lean Software Development, focus is on eliminating waste and giving value to the customer.
This results in rapid development and product of value.
Waste includes partially done work, irrelevant work, features that are not used by the customer,
defects, etc. that add to delays in delivery.
The Lean Principles are −
 Eliminate Waste
 Amplify Learning
 Delay Commitment
 Empower the Team
 Deliver Fast
 Build Integrity in
 See the Whole
Kanban
Kanban focuses on managing work with an emphasis on just-in-time (JIT) delivery, while not
overloading the team members. The tasks are displayed for all the participants to see and for the
Team Members to pull work from a queue.
Kanban is based on −
 Kanban Board (Visual and Persistent across the Development)
 Work-in-progress (WIP) Limit
 Lead Time
Agile Testing Methodologies
The testing practices are well defined for every project, whether Agile or not, to deliver quality
products. Traditional Testing principles are quite often used in Agile Testing. One of them is
Early Testing that focuses on −
 Writing Test Cases to express the behavior of the system.
 Early Defect Prevention, detection and removal.
 Ensuring that the right test types are run at the right time and as part of the right test level.
In all the Agile Methodologies we discussed, Agile Testing in itself is a Methodology. In all the
approaches, Test Cases are written before Coding.
In this tutorial, we will focus on Scrum as the Agile Testing Methodology.
The other commonly used Agile Testing Methodologies are −
 Test-Driven Development (TDD) − Test-Driven Development (TDD) is based on
coding guided by tests.
 Acceptance Test-Driven Development (ATDD) − Acceptance Test-Driven
Development (ATDD) is based on communication between the customers, developers
and testers and driven by pre-defined Acceptance Criteria and Acceptance Test Cases.
 Behavior-Driven Development (BDD) − In Behavior-Driven Development (BDD)
testing is based on the expected behavior of the software being developed.
Agile Testing Lifecycle
In Scrum, the Testing activities include −
 Contributing to User Stories based on the expected behavior of the System depicted as
Test Cases
 Release Planning based on Test Effort and Defects
 Sprint Planning based on User Stories and Defects
 Sprint Execution with Continuous Testing
 Regression Testing after the completion of Sprint
 Reporting Test Results
 Automation Testing
Testing is iterative and sprints based as depicted in the diagram given below −
AGILE TOOLS.
The best agile project management tools: free and paid
1. Jira Software
2. Monday.com
3. Asana
4. Trello
5. Airtable
6. Clickup
1. Jira Software
If you spend just five minutes scouting the web for an agile tool, chances are, you’ll come across
Atlassian’s Jira Software. Originally created for bug tracking, Jira is now a work management
powerhouse. Jira Software, sometimes referred to as JIRA, is geared specifically towards agile
software development teams. But with customizable workflows, JIRA can be useful for teams of
all kinds. There are both cloud-based and locally-hosted options.
With how prominent Atlassian is in the world of agile, we’re not surprised that JIRA addresses
everything that agile teams might need, regardless of which methodology they use. For example,
scrum teams can take advantage of easy backlog refinement, scrum reports, sprint planning,
scrum boards, and more.
Kanban users can use JIRA to host their kanban board, manage workflow with work-in-progress
limits (WIP), and create kanban reports like cumulative flow diagrams and control charts. JIRA
also works great for hybrid methodologies and scaled agile frameworks.
Pros:
 Is a well-established software in the world of agile and software development (trust
factor)
 Is able to track projects across multiple teams within an organization through higher-tier
plans (Premium and up)
 Includes specialized scrum features
 Offers app marketplace to get even more out of your JIRA platform
 Includes chat feature to promote team collaboration and communication
Cons:
 Can seem complex in the beginning
Pricing:
 Jira Software offers four tiers: Free, Standard, Premium, and Enterprise. If your needs
include advanced roadmaps, advanced management of dependencies, capacity planning,
and project archiving, you’re better off getting at least the Premium plan.
2. monday.com
monday.com is an all-in-one platform that lets you manage work and collaborate with your team
(and even across teams within an organization). Any team, agile or not, can use this software.
But agile teams in particular will find monday.com handy for planning iterations, bug
tracking, retrospectives, backlogs, product roadmaps, product launches, and more.
Boards are one of the core features for monday.com, and there are 200+ customizable templates
to get you started. For even more agile-friendly resources, you can head over to the newly-
launched app marketplace. One of these apps, called Live Collab, is perfect for sprint planning
sessions, and it even has a built-in Planning Poker feature for estimating user stories.
If monday.com had a calling card, it’d be this: flexibility. There are so many things you can do
with this software because of its wildly customizable features. Design your own workflows. Use
the automation features to save yourself from mundane tasks. Ask yourself, “Wouldn’t it be cool
if…” and monday.com will likely have a way for you to do it.
Pros:
 Is one of the more customizable options from this list
 Is visually appealing with its clean, modern interface
 Can apply to any type of team and industry
 Includes integrations with many workplace favorites like Outlook, Microsoft Teams,
Dropbox, and Slack
Cons:
 Can be overwhelming at first since it’s so customizable
 Doesn’t include a built-in chat feature, so you’ll need to an integration for
communication
Pricing:
 Monday.com offers five tiers: Free, Basic, Standard, Pro, and Enterprise. Free offers
unlimited boards and docs to teams of no more than two people. Basic, a good starting
point for teams, starts at $8/user monthly.
3. Asana
Asana’s thing is sticking to a few core features and doing them really well. This tool is for teams
who favor simplicity to hit the ground running over extensive customization. With Asana, it’s
easy to visualize work however you like. There are six different views that you can switch back
and forth to: board, timeline, list, calendar, progress tracker, and forms. Organize work with a
drag-and-drop board. Create a board for a project and start adding in sections and subtasks to add
order. Agile teams will find that Asana’s templates help with agile processes like bug tracking,
sprint planning, creating agendas for standups and retrospectives, and roadmap planning.
Integrations include Microsoft Teams, Slack, Gmail, and our very own Clockwise. Clockwise is
a smart calendar assistant that handles scheduling conflicts for you and optimizes your calendar
for much-needed Focus Time.
Pros:
 Covers all of the basics that a team might need to get started on a project in an organized
way with its core features
Cons:
 Might not suit your needs if you’re seeking total flexibility and customization (custom
roles and statuses are offered by ClickUp for example, which isn’t available in Asana)
 Doesn’t include a built-in chat feature, so you’ll need to an integration for
communication
Pricing:
 Asana offers four tiers: Basic, Premium, Business, and Enterprise. Basic can be used by
individuals and small teams to manage their daily to-dos. It functions more as a task
management tool with very lightweight project management. For agile project
management, we recommend getting Premium for project planning features like timeline,
unlimited dashboards, and reporting.
4. Trello
This one’s for the minimalists. Like JIRA, it’s also brought to us by Atlassian. At its core, Trello
lets teams build virtual and interactive boards, of which lists and cards are the building blocks.
To get started, simply create a board for your project, then lay out your tasks and subtasks
into lists and cards.
Among agile teams, the most popular way to use Trello is by creating lists for To Do, Doing,
and Done, which function as swimlanes. Create cards for each one of your user stories or tasks,
and track an item’s progression from To Do–Doing–Done.
What’s so great about this software is that you choose the level of functionality. Keep it simple
by using it for task management (like the method we laid out above), or expand into team
collaboration and project management territory. For example, you can add comments, due dates,
checklists, attachments, notification preferences, and automations for every card. You can even
assign cards to members, so that everyone knows what they’re responsible for.
Trello Premium gives you access to a number of views (apart from the standard board view),
which include timeline view, table view (which is essentially a spreadsheet), calendar view,
dashboard view, and map view (for when your cards have locations).
On top of that, Trello offers a huge library of templates, some of which cater specifically to agile
processes like sprints and retrospectives. Trello’s integrations, which they call Power-Ups,
include Confluence, Slack, Dropbox, Google Drive, and Evernote.
If your biggest pain point is lack of organization, Trello has what you’re looking for.
Pros:
 Is easy to get the hang of
 Can be as minimal or as intensive of a tool as you like
Cons:
 Doesn’t include a built-in chat feature. To communicate with your team members, you’re
restricted to the comments section of each card. Or, you’ll have to use a separate Power-
Up for messaging capabilities.
Pricing:
 Trello offers four tiers: Free, Standard, Premium, and Enterprise. Free is awesome if
you’re looking for task management, but if you plan on having multiple boards — maybe
you want to make a board for each sprint, or maybe a board for every retrospective, just
for example, then the Standard plan, which starts at $5 per user monthly, will better suit
your needs. And don’t forget, if you want more than one way of viewing your project,
then you’ll want to get Premium which starts at $10 per user monthly.
5. Airtable
Airtable makes spreadsheets fun again. (Seriously!) Airtable refers to themselves as a relational
database. Here’s what that means according to Airtable, “A database is essentially a collection of
organized information, and a relational database is a type of database that uses related tables to
organize information. When you use a relational database, not only can you better model how
different concepts, projects, or people are related to one another, you can also avoid duplicated
info and conflicts in your workflow.”
Airtable allows me to easily view, manage, and manipulate information in a number of different
layouts, which is incredibly beneficial and convenient. I also like how clean the user interface is
and how easy it is to get going with a new project.
Integrations include Gmail, Typeform, Evernote, Github, Google Calendar, Slack, and even
some of the other apps mentioned here like Asana and Trello.
Pros:
 Works for people who love spreadsheets but are frustrated with the outdatedness of most
spreadsheet software
Cons:
 Doesn’t include a built-in chat feature
 Can be difficult to use at first
 Allows fees to add up quickly due to its pricing model
Pricing:
 Airtable offers four tiers: Free, Plus, Pro, and Enterprise. If you’re asking us, things start
to get really good when you have the Pro plan which starts at $20 per user monthly.
Before that, you’re not really able to take advantage of the features that are distinctly
Airtable, like syncing data between tables.
6. ClickUp
ClickUp is trusted by big names, like Google and Squarespace. Yet it’s one of the newer
companies to enter the project management space. ClickUp promotes themselves as
a productivity platform, first and foremost. Their mission is based on the premise that when
everything’s in one place, you get more done.
ClickUp is also one of the only two apps on this list to have a built-in chat feature to
communicate with your colleagues (because commenting isn’t always the most efficient way to
discuss in real-time). While the other apps offer integrations for messaging, with Click-Up and
JIRA, you can start messaging with other team members right out the gate.
Let’s cover agile features, shall we? Agile teams use ClickUp for bug tracking, sprint
management, product launches. There are even Sprint Widgets that you can add to your
dashboard for burndown/burnup charts, velocity, cumulative flow, cycle time.
There’s also an app center, ClickApps, where you can find tools that have been adapted for
specific needs like assigning story points just for example.
There are over 1,000 integrations available on ClickUp, from time tracking apps and cloud
storage to developer apps and everything in between. Popular integrations include Slack and
Zoom.
Pros:
 Includes a built-in messaging feature. Save your team from window- and tab-switching
(and email!) when you need to communicate.
Cons:
 May call for a learning curve in the very beginning of using this software
Pricing:
 Clickup offers four tiers: Free, Unlimited, Business, and Enterprise. The cool thing about
their pricing model is that Free offers many of the same features that the higher tiers do
— just with a limited amount of uses. It’s sort of like a trial run with no time limit.