Module 4- Agile

Methodologies

06-03-2025 1
Syllabus
• Pair Programming – Refactoring – Dynamic Systems Development
(DSD) – Feature Driven Development (FDD) – Test Driven
Development (TDD), Agile Unified Process – Agile Failure Models -
Various reasons why agile fails?

06-03-2025 2
 Pair Programming

06-03-2025 3
Pair Programming
• Driver and Navigator working together on one task
• Roles changing often
• Collective responsibility for outcome
• Bringing together of multiple perspectives, experiences, abilities, and
expertise

06-03-2025 4
Roles
• Driver
• Actually types or writes down
• Explains actions taken
• Participates in brainstorming/planning
• Navigator
• Watches for tactical and strategic defects
• Questions
• Participates in brainstorming/planning

06-03-2025 5
Navigator Tips
• Delay a little to let driver find and correct their own mistakes (particularly typo-
level)
• If you’re getting bored/falling asleep, ask for the keyboard
• If the driver is getting frustrated, ask for the keyboard
• If you couldn’t take over at any point, ask questions or ask for the keyboard
• Use active listening
• Talk
• Ask questions

06-03-2025 6
Driver Tips
• If navigator bored/falling asleep, give them the keyboard
• If you’re tired, pass the keyboard
• If you’re frustrated with something, pass the keyboard
• Acknowledge navigator
• Explain what & why
• Talk
• Answer questions
• Don’t just dictate – brainstorm/design together

06-03-2025 7
06-03-2025 8
Why pair?
• Higher quality code
• Faster cycle time
• Enhanced trust/teamwork
• Knowledge transfer
• Enhanced learning
• More fun

06-03-2025 9
Why pair?
• Higher quality code
• Immediate reviews of all code written
• Multiple perspectives on how code should work
• People from different areas (UI/database, development/testing) working together –
no (incorrect) assumptions
• Each person learns from the other – increased skills
• Faster cycle time
• Less temptation/ability to get distracted on non-work things
• Less rework due to bad assumptions
• Fewer defects slip through, so less rework for defect repair
• Less interruption for pair
• More communication

06-03-2025 10
Why pair?
• Enhanced Trust/Teamwork
• People in pairs get to know each other better than people working solo
• Better understanding of people’s skills
• Shared events = common ground
• Knowledge Transfer
• Rotation of pairs means lots of combinations
• Lots of combinations make knowledge transfer exponential
• No one person is indispensible
• Fewer assumptions
• Enhanced Learning
• Each member of a pair has ongoing opportunities to learn from their partner
• More Fun
• Social interactions while still accomplishing work
• Shared events
• Studies show high numbers of people trying pair programming prefer it

06-03-2025 11
Why Pair Programming Works?
• Pair Pressure
• Pair Negotiation
• Pair Courage
• Pair Reviews
• Pair Debugging
• Pair Learning
• Pair Trust

06-03-2025 12
Why Pair Programming Works?
• Pair Pressure
• Each member doesn’t want to let the other down
• Improved adherence to procedures and standards
• Motivation to get a task done in a session while partner is available
• Pair Negotiation
• Working together to get the best solution
• Distributed Cognition
• Each pair member has
• Own set of skills, abilities, outlook.
• Shared goal of accomplishing task
• Suggested means of goal
• Brainstorming (building on ideas of others)

06-03-2025 13
Why Pair Programming Works?
• Pair Courage
• Having a partner agree with a fix or a solution adds confidence to the solution
• Two people expressing confusion are more confident to get the help they need
• Pair Reviews
• Members of pairs immediately review the code as it is written
• Two heads better than one
• Pair Debugging
• Effective debugging technique is to explain the problem to someone else
• Talking about the problem in a pair can lead to a solution becoming obvious
• Pair Learning
• Apprenticeship model (beginner acquires learning from observing expert)
• No two people are at the same levels of knowledge on software development
• Exposure to different approaches
• Pair Trust
• People in pairs get to know each other better than people working solo
• Better understanding of people’s skills
• Shared events = common ground

06-03-2025 14
Problems in Pair Programming
• Unavailability of partners
• Scheduling
• Experts/Skill Imbalances
• Concentration
• Disagreements
• Overconfidence
• Rushing
• Not for everyone

06-03-2025 15
Enabling Pair Programming
• Accessible workspace
• Communication
• Standards
• Knowledge of people’s specialties
• Pair rotation
• Group appraisal
• Smaller groups

06-03-2025 16
Workspace accessible to both
• Display visible to both people
• Side by side, not one in front of the other
• Keyboard/mouse available to either person

06-03-2025 17
Expectation of communication
• Ask to drive
• Ask questions
• Explain actions taken
Standards
• Standard tools reduce learning curve time in pairs
• Coding standards assist both members in following the code being
written and avoid disagreements on how to write something
Knowledge of people’s specialities
• Know who to pair with to achieve benefit in a given situation
• If a task overlaps two areas (e.g., UI and database), pair one person
from each area
06-03-2025 18
Pair Rotation
• No given pair of programmers is the right pair for every situation
• Rotation enables knowledge transfer
Group Appraisal
• More than one person now completes tasks
• Recognizing one person generally ignores contribution from other
team members who paired for part or all of the task
Smaller Groups
• Large groups benefit from pairing, but lose some of the trust and
knowledge transfer effects

06-03-2025 19
 Introduction to Refactoring
Refactoring is fundamental to agile programming

06-03-2025 20
Refactoring
• Refactoring is:
• restructuring (rearranging) code in a series of small, semantics-preserving transformations (i.e.
the code keeps working) to make the code easier to maintain and modify
• Refactoring is not just arbitrary restructuring
• Code must still work
• Small steps only so the semantics are preserved (i.e. not a significant re-write)
• Unit tests to prove the code still works
• Code is
• More loosely coupled
• More cohesive modules
• More comprehensible

• There are numerous well-known refactoring techniques

• You should be at least somewhat familiar with these before inventing your own
• Refactoring “catalog”
06-03-2025 21
When to refactor
• You should refactor:
• Any time that you see a better way to do things
• “Better” means making the code easier to understand and to modify in the future
• You can do so without breaking the code
• Unit tests are essential for this
• You should not refactor:
• Stable code that won’t need to change
• Someone else’s code
• Unless the other person agrees to it or it belongs to you
• Not an issue in Agile Programming since code is communal

06-03-2025 22
When Refactor
• When should you refactor?
• Any time you find that you can improve the design of existing code
• You detect a “bad smell” (an indication that something is wrong) in the code
• When can you refactor?
• You should be in a supportive environment (agile programming team, or
doing your own work)
• You are familiar with common refactoring
• Refactoring tools also help
• You should have an adequate set of unit tests

06-03-2025 23
Where did refactoring come from?
• Ward Cunningham and Kent Beck influential people in Smalltalk
• Kent Beck – responsible for Extreme Programming
• Ralph Johnson a professor at University of Illinois and part of “Gang of
Four-design Patterns” ( Erich Gamma, Richard Helm, Ralph Johnson,
and John Vlissides)
• Bill Opdyke – Ralph’s Doctoral Student
• Martin Fowler - http://www.refactoring.com/
• Refactoring: Improving The Design Of Existing Code

06-03-2025 24
Refactoring Process
• Make a small change
• a single refactoring
• Run all the tests to ensure everything still works
• If everything works, move on to the next refactoring
• If not, fix the problem, or undo the change, so you still have a working
system

06-03-2025 25
Forecasting constant change
• Constantly changing technology, coupled with evolving business
objectives makes it difficult to maintain and constantly increase
business value.
• Two paths to the future exist:
• Keep adding new functionality to an existing code base toward an eventually unmaintainable “throw-
away” state
• Continuously modify the system to provide a foundation for efficiently delivering not just the current
business value but future business value as well
• Refactoring
• Continuous refactoring can extend the useful life of an Enterprise’s investment in software assets as
long as possible, and users can continue to experience a flow of value for years to come.
• Refactors enable an emergent design to ensure the system continues to meet future business needs.
• Refactors are a special type of Enabler story in SAFe and, like any other Story, they must be estimable,
demonstrable, and valuable, as well as accepted by the Product
•
06-03-2025 26
Essence of Refactoring
• Modification of any software entity—a module,
method, or program—to improve its structure or
viability without changing the external functionality
• Refactors may accomplish such things as increases in
processing speed, sourcing different internal data, or
improving security concerns.
• Another type of refactoring involves streamlining some
aspect of the code to make it more efficient,
maintainable, or readable.
• Refactoring mandates that each change is tested
immediately to verify the accomplishment of the
desired goal.

06-03-2025 27
Sources of Refactors
• A refactor can be instigated by a
business Feature or can be a part
of larger refactoring initiative
required by some
new architectural Enabler.
• New user Stories may also require
some refactoring of code.
• Accumulated technical debt may
drive the team to refactor
certain components.
• Some refactors may be
necessitated by new Nonfunctional
Requirements.

06-03-2025 28
 Architectural Runway
• The Architectural Runway consists of the existing code, components,
and technical infrastructure needed to implement near-term features
with minimal redesign and delay

Enabler

06-03-2025 29
 An Enabler supports the activities needed to extend the
Type of Enablers Architectural Runway to provide future business functionality.

• Enablers can be used for any activities that support upcoming business
requirements and generally fall into one of four categories:
• Exploration enablers – These support research, prototyping, and
other activities needed to develop an understanding
of customer needs, including the exploration of prospective Solutions
and evaluating alternatives.
• Architectural enablers – These are created to build the Architectural
Runway, which allows smoother and faster development.
• Infrastructure enablers – These are created to build, enhance, and • Architectural enablers fix existing
automate the development, testing, and deployment environments. problems with the solution
They facilitate faster development, higher-quality testing, and a • Many NFRs appear over time as a
faster Continuous Delivery Pipeline. result of enabler
• Compliance enablers – These facilitate managing specific compliance
activities, including Verification and Validation (V&V), documentation
and signoffs, and regulatory submissions and approvals.

06-03-2025 30
Technical debt in Agile
• Technical debts are the part of
requirements that are omitted,
not done, or are at a lower
priority and low importance.
• It is also the cost of rework that is
caused in the requirements due
to omission or ignoring or made
due to first doing the easy
solution to the customer instead
of doing a long-term robust
solution.

06-03-2025 31
Specifying Refactors
• It is important to understand what value will
be achieved once the refactoring is
completed.
• Teams may wish to use the “ . . . so that . . . ”
portion of the user story voice form to foster
a shared understanding of purpose and value

06-03-2025 32
Splitting Refactors • As with user stories,
splitting refactors is
important, as it helps
sustain better
development flow.
• Methods for splitting
refactors

06-03-2025 33
Establishing Acceptance Criteria
• As with user stories, defining acceptance
criteria for refactors helps resolve
ambiguities.
• Acceptance criteria can often be used as a
natural basis for splitting.

Refector splitting from acceptance criteria:

1. Make synchronous non-configurable batch processing with a single query to the
dictionary, but without the debug logging.’
2. Add the capability to read the batch size from the file.
3. Process items asynchronously,’ and
4. Add debug logging functionality.

06-03-2025 34
Code Smells
• If it stinks, change it
• Code that can make the design harder to change
• Examples:
• Duplicate code
• Long methods
• Big classes
• Big switch statements
• Long navigations (e.g., a.b().c().d())
• Lots of checking for null objects
• Data clumps (e.g., a Contact class that has fields for address, phone, email etc.) -
similar to non-normalized tables in relational design
• Data classes (classes that have mainly fields/properties and little or no methods)
• Un-encapsulated fields (public member variables)

06-03-2025 35
 What is the difference between code optimization
and code refactoring?
Code Optimization Code Refactoring
• Improves resource efficiency, • Aims to improve the structure,
execution time, and performance of readability, and maintainability of the
the code. code.
• Focuses on improving the memory or • Looks to enhance code organization
processing time. without altering external behavior.
• May change the original code to • Retains intrinsic functionality while
achieve performance gains. enhancing the code quality.
• Involves changes to algorithmic or • Involves holistic restructuring,
low-level implementation details. simplifying, and clarifying code.
• May sacrifice code readability to • Usually, doesn’t consider performance
achieve performance targets improvements as the main goal

06-03-2025 36
1: switch statements
• switch statements are very rare in
properly designed object-oriented code
• Therefore, a switch statement is a simple and easily
detected “bad smell”
• Of course, not all uses of switch are bad
• A switch statement should not be used to
distinguish between various kinds of object

Switching on object type

Example 1: switch statements
• Reason for RF:
• Often code for a single switch can be scattered in different places in the
program.
• When a new condition is added, you have to find all the switch code
and modify it.
• As a rule of thumb, when you see switch you should think of
polymorphism.
• There are several well-defined refactorings for this case
• The simplest is the creation of subclasses

06-03-2025 Better handled by polymorphism 38

Example 1, continued

06-03-2025 39
How is this an improvement?
• Adding a new animal type, such as Amphibian, does not require
revising and recompiling existing code
• Mammals, birds, and reptiles are likely to differ in other ways, and
we’ve already separated them out (so we won’t need more switch
statements)
• We’ve gotten rid of the flags we needed to tell one kind of animal
from another
• We’re now using Objects the way they were meant to be used

06-03-2025 40
Example 2: Encapsulate Field
Moving Features between Objects

• Un-encapsulated data is a no-no in OO application design.

• Use property get and set procedures to provide public access to private
(encapsulated) member variables.

06-03-2025 41
Encapsulate Field

• You have a method that runs different code depending on the values of an enumerated
parameter.
• Create a separate method for each value of the parameter

06-03-2025 42
Self Encapsulate Field
• Problem: Using direct access to private fields inside a class.
• Solution: Create a getter and setter for the field, and use only them
for accessing the field.
Encapsulating Fields
• I have a class with 10 fields. This is a pain to set up for each one.
• Refactoring Tools
• NetBeans/Visual Studio refactoring examples

• Also:
• Rename Method
• Change Method Parameters

06-03-2025 44
3. Extract Class
• Problem: When one class does the work of two, awkwardness results.
• Solution:
• Break one class into two. For example, Having the phone details as part of the Customer class is not a
realistic OO model and also violates the Single Responsibility design principle.
• We can refactor this into two separate classes, each with the appropriate
responsibility.
4. Extract Method
• Sometimes we have methods that do too much. The more code in a single
method, the harder it is to understand and get right.
• It also means that logic embedded in that method cannot be reused elsewhere.
• The Extract Method refactoring is one of the most useful for reducing the
amount of duplication in code.

06-03-2025 46
4. Extract Method

06-03-2025 47
5. Extract Subclass
• Problem: When a class has features (attributes and methods) that would only be
useful in specialized instances,
• Solution: Create a specialization of that class and give it those features.
• This makes the original class less specialized (i.e., more abstract), and good design is about binding to
abstractions wherever possible.

06-03-2025 48
6. Extract Super Class
• Problem: When you find two or more classes that share common features,
• Solution: Consider abstracting those shared features into a super-class.
• Again, this makes it easier to bind clients to an abstraction, and removes duplicate code from the original classes.

06-03-2025 49
7. Extract Interface
• Problem: Some clients may need to know a Customer’s name, while others may only need to
know that certain objects can be serialized toXML.
• Having toXml() as part of the Customer interface breaks the Interface Segregation design
principle which tells us that it’s better to have more specialized interfaces than to have one multi-
purpose interface.

06-03-2025 50
7. Extract Interface

06-03-2025 51
8. Form Template Method - Before
• When you find two methods in subclasses that perform the same
steps, but do different things in each step,
• create methods for those steps with the same signature and move the original
method into the base class
Form Template Method - Refactored
9. Move Method - Before
• If a method on one class uses (or is used by) another class more than the class on which its
defined,
• move it to the other class, Turn the code of the original method into a reference to the new method in the other
class or else remove it entirely.
Move Method - Refactored
• The student class now no longer needs to know about the Course
interface, and the isTaking() method is closer to the data on which it
relies - making the design of Course more cohesive and the overall
design more loosely coupled
10.Replace Error Code with Exception
• A method returns a special code to indicate an error is better accomplished with
an Exception.

06-03-2025 56
11.Replace Exception with Test
• Conversely, if you are catching an exception that could be handled by
an if-statement, use that instead
 12. Nested Conditional with Guard
• A method has conditional behavior that does not make clear what the normal
path of execution is. Use Guard Clauses for all the special cases.

58
13. Rename Variable or Method
• Perhaps one of the simplest, but one of the most useful that bears repeating: If
the name of a method or variable does not reveal its purpose then change the
name of the method or variable.

06-03-2025 59
14. Replace Temp with Query
• Problem: using a temporary variable to hold the result of an
expression.
• Solution: Extract the expression into a method. Replace all references
to the temp with the expression.
• The new method can then be used in other methods and allows for
other refactorings.

06-03-2025 60
15. Remove Magic Numbers with Strings
• Magic numbers and strings are values hardcoded into your code.
• Using such values in your code makes the code less maintainable and
increases inconsistencies and errors due to mistypes.
• Instead of using hardcoded values, refactor your Java code to use
constants with descriptive names.

06-03-2025 61
Sample 1
• Suppose you have a simple
class that processes orders
and calculates subtotal cost,
tax rate, and total cost.

06-03-2025 62
Sample1: Solution-Extract Method

• You can refactor the code above

such that the code related to
calculating the subtotal, tax, and
total cost has been extracted
into separate
methods: calculateTax, calculate
Subtotal,
and calculateTotalCost as shown
below.
• This makes the class more
readable, modular, and reusable.

06-03-2025 63
Sample2

• Number processor
for calculating
total and Average

06-03-2025 64
Extract Method: by removing duplicate code
• In the refactored example,
extracted the duplicate
logic for summing up the
number into
the calculateSum method.
Both calculateTotal and cal
culateAverage methods
now utilize
the calculateSum method
to calculate the sum.

06-03-2025 65
Sample 3

06-03-2025 66
Sample2: Extracting Method and simplify using
ternary operator
• We can simplify the
example above by
extracting
the calculateItemPrice lo
gic
to calculateItemPrice and
applyDiscount and
simplify the conditionals
by using ternary
operators instead.

06-03-2025 67
Sample 3

06-03-2025 68
Extract class: Single Responsibility Principle

06-03-2025 69