Infosys Global Agile Developer

Certification Refresher
Part – 1
Sections Covered (Agile Generic)

2
Agile Manifesto

3
Agile Principles

Customer satisfaction by rapid delivery of useful software

Welcome changing requirements, even late in development

Working software is delivered frequently (weeks rather than months)

Working software is the principal measure of progress

Sustainable development, able to maintain a constant pace

Close, daily co-operation between business people and developers

Face-to-face conversation is the best form of communication (co-location)

Projects are built around motivated and trustworthy individuals

Continuous attention to technical excellence and good design

Simplicity

Self-organizing teams

Regular adaptation to changing circumstances

4
Agile Software Development Methodologies
Feature-Driven
Development
(FDD) Kanban
Scrum

Extreme
Lean Software
Programming Methodologies
Development
(XP)

Crystal Scrumban
Dynamic Systems
Development
5
Method (DSDM)
 Agile methodologies

6
Scrum
• Iterative and incremental framework for application or product development
• Achieved through iterative cycles known as Sprint
• At the end of each Sprint, Scrum emphasizes for an fully tested integrated working software and potentially shippable product
• Sprints are strictly time boxed and occur sequentially
• End date of a Sprint does not get extended, irrespective of the completion of the work initially planned

7
Scrum Roles
Product Owner The Team Scrum Master
•Providing the vision of the project to the • Team size should ideally be • Helps the Scrum team to adopt
team around 7 persons (+/- 2) Scrum
•Maximizing the value of the project and • Recommended to be cross- • Helps the team to learn and apply
the work of the Scrum Team
functional with skills Scrum to achieve the desired
•Managing the Product Backlog
• Adheres to Scrum principles objective of the project
•Clearly expressing Product Backlog
items • Self-organized and decides what • Does not tell people what to do or
•Prioritizing the items in the Product to commit and how best to assign tasks, but facilitates the
Backlog accomplish that commitment process
•Ensuring that the Product Backlog is • Accountability of the work • Serves the Team, protects them
visible, transparent and clear product belongs to the team as a from outside interference,
•Change to a Product Backlog item’s whole educates and guides the Product
priority has to discuss with the Product Owner and the Team in use of
Owner Scrum
• Facilitates Scrum events
• Coaches the Team to be cross-
functional
• Removes impediments for the
Team’s progress
• Scrum Master cannot be the
Product Owner, manager of the
Team or the Project Manager
8
Scrum Events: Release Planning Meeting
• Establishes the plan and goals which needs to be achieved for the upcoming Release
• Turn the vision into a successful project in best possible way
• Establishes the goal of the release, high-priority Product Backlog items, major risks and overall features and functionalities
• A probable delivery date is agreed upon; the stakeholders can inspect the progress and make changes to this release plan
on a Sprint-by-Sprint basis

Estimate Decide the

Product Sprint
Backlog Length

Calculate
Fix the
the
release
number of
Date
sprints

9
 Scrum Events : Sprint Planning
• Work to be performed in a Sprint is planned
• Plan is created by collaborative work of the entire Scrum Team
• Consists of two parts, each one being a time-box of half of the Sprint Planning Meeting duration

Second Half: ‘HOW’ to deliver

Inputs:
Key Discussions:
 The Product Backlog
 Projected capacity of the Scrum Team during the Sprint • Discuss the rough architecture • Identify Data to be used and data
 The latest product Increment (if available) • Make design decisions sources
 Past performance of the Scrum Team (If available) • Identify tasks the team needs to do • Discuss Architectural patterns to be
• Identify components and interfaces applied
Output: • Identify dependencies • Discuss Testing strategy
 list of all the tasks with estimates • Identify the external integration points
 plan on how to accomplish the work selected
 Team estimates how much time each member has for Sprint-related work
 Determines how many Product Backlog items they can finish in that Sprint & the
First Half: WHAT to deliver approach for completing them
• Product Owner presents the prioritized Product Backlog to  Decomposes the Product Backlog items into tasks based on the understanding of
the Team the overall design
• Team discusses the requirements with the Product Owner  Tasks are decomposed to granular level to be completed in less than one day
• Understands the acceptance criteria for each item in scope  Sprint Backlog consists of the prioritized Product Backlog items for this Sprint
• Team decides on the Sprint Goal in agreement with the  Product Owner presence is optional
Product Owner  Team may renegotiate the items with the Product Owner if in case it has too much
• If there are issues in scope for the Sprint, Team discusses or too little work in hand
with the Product Owner for the reprioritization  Team may also invite people outside the scrum team i.e. SMEs to attend in order
to provide technical or domain advice
10
Scrum Events: Daily Scrum
During the meeting, each Team member explains:
• 15-minute time-boxed event for the team  What he or she has accomplished since last meeting
• Identify and remove impediments to development  What he or she is going to do before the next meeting
 What issues/obstacles are in his or her way

Promotes “Openness”
as everyone shares
information

Helps to synchronize
Reinforces the activities and
commitment effectively plan for
next 24 hours

Provides data
Helps to focus by
through updated
creating an
Sprint Burn Down
“anticipating culture”
chart on daily basis

Helps Team to respect

each other for their
11 knowledge
Scrum Events: Sprint Review & Sprint Retrospective
Sprint Review
• Held at the end of the Sprint
• Scrum Team demo’s what was developed in the sprint to the stakeholders
• Receive feedback on the progress made so far and decide the next course of action
• Product Backlog may get revised as an outcome of the Sprint Review meeting

The Sprint Review includes the following:

 Product Owner identifies what has been ‘Done’ and what has not been ‘Done’
 Team demonstrates the work that has been ‘Done’ and answers questions about the increment
 Product Owner discusses the Product Backlog as it stands
 The entire group discusses on what to do next

Sprint Retrospective
• Inspect the last Sprint with regards to people, relationships, process and tools Steps:
• Discuss what went well during the Sprint, what problems were faced and how they  Setting the Stage
were solved  Gather Data
• These include Scrum Team composition, meeting arrangements, tools, ‘Definition of  Generate Insights
Done’ and methods of communication  Decide What to Do
• Create a plan for implementing improvements to the way the Scrum Team works  Close the Retrospective
• Scrum master & team attend this meeting

12
Scrum Artifacts: Product Backlog

Product Backlog

An ordered and emerging

list of user needs (User
Product Owner articulates This evolves into a refined
Stories) plus anything else Continuously updated by Only a single Product
product vision at the start and prioritized list of
that is required to fulfill the Product Owner Backlog exists for a project
of the project features or requirements
the Product Vision” is
called Product Backlog

A Good Product Backlog Should be DEEP:

Detailed enough – To make the requirements very clear

– The Product backlog keeps emerging through new ideas and continuous feedbacks from the
Emergent customers

Estimated – The User stories must have the relevant points already

13 Prioritized – The User stories must be ordered based on their importance / priority
Scrum Artifacts: Release Burndown

Release
Burndown
Chart reflects the remaining
Product Backlog items across the
releases

X-axis contains the number of

Sprints for the release whereas
the Y axis contains the effort
remaining in the release

Depicts the progress of the

release on a real time basis

Available to all stakeholders of

the project

14
Scrum Artifacts: Sprint Backlog

Highly visible, real-time Comprises of all the tasks

picture of the work that Subset of Product Backlog that the Team identifies as
team plans to accomplish items necessary to meet the Sprint
during the Sprint goal

Gets updated by the Team At any point in time in a

throughout the Sprint by Sprint, total work remaining
updating the remaining in the Sprint Backlog items
effort for the tasks can be summed

15
 Scrum Artifacts: Sprint Burndown

• Represents the amount of Sprint Backlog work remaining in a Sprint across number of days
in the Sprint
Sprint •“Y” axis shows the remaining effort required to complete the work planned and the “X” axis
Burndown contains the number of days until the iteration deadline
• Shows the team their progress towards their goal in terms of how much work remains in the
future

If the actual line of the Burndown chart is behind (i.e. Lagging) the Ideal line, it indicates that the team is not on schedule or as per the plan.
Team needs to adjust, such as to reduce the scope of the work or to find a way to work more efficiently

16
Extreme Programming (XP): Fine Scale Feedback
The term XP is conceptualized from the execution of traditional software engineering practices at extreme
levels.
Following are its features:

1. Planning Game: to ensure work is planned incrementally. It is divided into two

parts:

Release Planning: meeting to shortlist requirements to be included in the

releases planned and timeline of each release. It has three phases: Fine Scale Continuous
Feedback Process

Iteration Planning: meeting by the Team to decide upon the tasks and activities,
to accomplish requirements planned for the iteration Shared Programmer
Understanding Welfare

17
Extreme Programming (XP): Fine Scale Feedback
2. Pair Programming:

• Coding is generally followed with code review, and in the extreme case, coding and Fine Scale Continuous
review can happen in parallel. Feedback Process
• Two persons work on the same code. While one programmer is doing the coding,
focusing on the code and program level details, the other programmer has the big
picture and continuously reviews the code
Shared
• The pairs are not fixed and keep on changing thereby helping everybody to be aware Programmer
Understandin
of the entire system Welfare
g
3. Test Driven Development:

• Developer writes the automated test cases before the actual code is written 4. Whole Team:
• Automated unit test cases should inevitably fail at the first attempt of run. If it does
not fail, it indicates the feature already exists or there are some problems with the • Team members are encouraged to be more
automated test case generalized than specialized
• The code is written and the automated test suite is run. Based upon the result, the • Customers are included as part of the Team who are
code is modified always available to respond to the queries and provide
• The units are usually kept small and code is refactored as and when required clarifications.

18
Extreme Programming (XP): Continuous Process

1. Continuous Integration:
• Code base is integrated on a frequent basis from the start of the feature
development
• An automated process in which builds are created from the common
Fine Scale Continuous source code repository
Feedback Process • Helps in identifying integration issues much ahead in the lifecycle which
reduces much of the rework cost.

2. Refactoring:
• Regular improvement of existing design and code without affecting the
functionality
Shared Programmer
Understanding Welfare • Helps to improve the overall code quality

3. Small Release:
• Smaller releases are planned which provide customer the confidence of
the overall progress
• Helps customer to provide suggestions for any changes and helps to
meet the overall goal
19
Extreme Programming (XP): Shared Understanding
The term XP is conceptualized from the execution of traditional software engineering practices at extreme levels.
Following are its features.

Coding Standards:
Fine Scale Continuous
Rules need to be as per the standards defined by language vendors and/or Feedback Process
customized by the Team

Collective Code Ownership:

Since the Team is cross-functional and entire team works in pairs which keep
changing, all parts of the code are known to everybody Shared Programmer
In case of error, any programmer is allowed to change the code Understanding Welfare
Simple Design:
XP recommends the simple and best way to implement code
Refactoring also facilitates this process of achieving simple design Programmer welfare:

Metaphor: • Team members need not work for more

A naming convention, which makes all the stakeholders understand what the than 40 hours per week (ideally) to meet
functionality is all about in detail project deadlines as it hampers repeatable,
predictable and consistent delivery

20
Extreme Programming (XP) : Roles

• Creates user stories and prioritizes user stories

Customer • Addition/Modification/Deletion of user stories

• Estimates for user stories along with the Team

Programmers • Builds the users stories as per the standards

• Monitors XP process implementation

Coach • Issue resolution on XP practices
• Mentors team members

• Monitors the progress

Tracker • Alerts the Team

21
Extreme Programming (XP) : Activities

Coding Testing Listening Designing

Most important activity Listen to clients to Creating the design

Focus on Test Driven
of Software understand business structure to organize
Development
Development logic logic of the system

Used to find out the Through test of every Effective Listening

Good design practices
software solution piece of code through through planning game
automated Unit Testing

Used to communicate
thoughts among Continuous Integration
programmers Testing

Working product is
nothing but code Acceptance Testing

22
Kanban: Principles

Kanban is a Japanese word where Kan means “Visual” and ban means “Card” or “Board”

Sample Kanban Board

Kanban is basically a signaling device that instructs the

moving of parts in a ‘pull’ production system

developed as part of the TPS (Toyota Production System)

Main aim is to minimize WIP (Work-In-Progress), or inventory

by making sure upstream process creates parts only if its
downstream process needs it

23
Kanban Principles
•Change management method which •After starting with the existing process,
starts with the existing process the team must agree for continuous,
•Changes are done in the system in incremental and evolutionary change
incremental and evolutionary way •Changes should be small and incremental
•Unlike Scrum, there is no specific process •Rapid and substantial changes may be
or roles defined in Kanban effective but it will be subjected to larger
Agree to resistance as well by the Team
Start with pursue
existing incremental,
process evolutionary
change

Respect the
current
Leadership at
process, roles,
all levels
responsibilities
and titles
•Kanban does not expect leadership from •Though Kanban suggest continuous
a specific set, rather the actions of incremental changes in the process, it
leadership at all levels in the respects current roles, responsibilities and
organization, are very much encouraged job titles
•Helps for the Team to gain the confidence as
they get started with Kanban
24
 Kanban: Practices

• Visualizing the work-flow and making it • Flow of work through every state in the
visible to understand how work proceeds workflow is observed, measured and
• Card wall with columns and cards is used informed • Early feedbacks from client and the
to visualize the flow of work • Incremental, continuous and evolutionary pull system
• Different states or steps in the workflow modifications to the system can be • Feedback from different stakeholders
are represented by the columns on the assessed to have negative or positive and processes helps to eliminate risk
card wall effects on the system and optimize delivery process

Improve
Collaboratively, Implement Make Policies
Visualize Limit WIP Manage flow
Evolve feedback loop Explicit
Experimentally

• Limiting WIP implies that a pull system • When teams have a common • Mechanism of a process of how work
is executed on either parts or the understanding of concepts about is truly done and how things actually
whole workflow work, process, workflow and risk, work
• Assigns explicit limits to the number of there is a shared understanding of • With clear understanding, it is possible
items that may be in progress at each problem to hold a more rational, empirical,
workflow state • Suggest enhancement actions which objective discussion of issues.
could achieve a consensus • More likely to facilitate consensus
25 around improvement suggestions.
Kanban Approach

26
Kanban Benefits
 Introduction of process, visualization and optimization

 Limiting WIP resulting in greater focus on quality thus achieving customer satisfaction

 Support for Just-In-Time planning and execution for application maintenance teams

 Predictable lead times based on WIP (Work in progress) limits allow committing to SLAs (service-level agreements) and make realistic release
plans, based on critical business needs

 Focus on maximizing the flow of work, based on continuous planning and execution

 Use transparency to drive process improvement

 Organizational maturity improves leading to improved decision making and better risk management

 Minimized Waste

 Less process overhead

 More accurate and predictable pace ensures team members are never overloaded

 Enables fast reprioritization so as to accommodate changes according to the market demand

 Better estimated lead times and thereby effort required

27  Flexibility to react to continuous changing priorities of work items

 Planning & Estimation

28
Planning & Estimation
Essential in software projects to
achieve predictability, reducing
the risks involved and to set a
basic expectation to all
Planning gives the project team stakeholders Estimation is to forecast project
a perspective on how to meet
related variables i.e. effort,
the objective in a systematic
scope, schedule
way

Agile planning balances the effort and Software projects are typically controlled by four major variables i.e.
investment in planning with the knowledge that Schedule, Scope, Cost, and Effort
we will revise the plan through the course of Estimation is a process to forecast these variables to develop or
the project maintain software
3 main challenges faced during estimation:
This is done to avoid the weaknesses like:
• Uncertainty
• Concentrating on activities rather than delivered
• Self-knowledge
feature
• Consistency of Method used for Estimation
• Ignoring the prioritization
Standardized and scientific estimation methods:
• Ignoring the existence of uncertainty
• Helps towards maintaining minimal variance between the planned
• Using estimations as commitments
estimates and actual values for maximum estimation accuracy
• Provides better client experience

No single method fits all estimation needs for a project

29 Different methods of estimation for different stages
Planning & Estimation Stages

30
Planning & Estimation: Project Level
Project Level planning is required to understand:
• Highest level of planning that focuses on impending activities of the project and its
Overall vision
ultimate goal
Roadmap • Creates the macro image of the project and its importance for the stakeholders
• Helps project teams to create priorities and estimations
Value delivery
• Product Owner (or Client/Business manager) is the primary stakeholder involved in
Planning for better risk coverage this activity
• Planning at Project level involves infrastructure planning, quality management
Creation of Product Backlog planning, environment setup planning, tools and reuse planning, build automation
Defining the Releases and continuous integration planning

Important aspects of planning includes

1. Product Backlog: explained in earlier slide

2. Workshop:
• main purpose of conducting workshops is for gathering, understanding and prioritizing requirements, mainly during the Initiation phase
• group of people collaborate to present different ideas to reach a predetermined objective supported by an impartial facilitator
• there should be a clear idea on what is required and what should be the outcome
• usually conducted to compress timelines (i.e. defining the Releases) and reach a consensus/decision faster
• not the same as brainstorming
• workshops are worthwhile to do once in every 6 months, just to review the direction of the project

31
Planning: Project Level
3. Application Life Cycle Management:
• aids in managing Agile projects by providing mechanisms to deliver software more predictably and to drive business value
• supports development process, project management, metrics and dashboards, compliance reports, sharing artifacts within team
• used for planning and estimating user stories and sharing it within team
• used for building a Product Backlog, Sprint Backlog, establishing team commitment and velocity, visualizing team activity and project
progress via Burn Down charts and reporting on team progress
• efficiently capture, self-assign and manage their tasks

ALM tool facilitates the following activities of the distributed Agile project:

Product and Release Planning i.e. for planning and managing Agile requirements, epics,
stories, and goals across multiple projects, teams, and portfolios

Sprint planning and Tracking i.e. for iteratively planning user stories, defects, tasks, tests,
and impediments in a single environment

Managing project artifacts (Product and Sprint backlog items, Source Code, Development
and Testing artifacts, Test reports)

Managing reports (Release and Sprint Burn Down charts)

Tracking process information (who does what and when)

Managing communication tools (discussion forum, chat, information-sharing,

notifications
32 to users etc
Estimation: Project Level
• Functional requirements are at high level and are still at Epic or Feature level
• Estimation is required at this stage, as this will help in prioritization and planning the Releases
• Estimation during Project Initiation stage should be either a group activity, results should be compared and differences
to be resolved
• project assumptions and risk should be highlighted clearly
• Epics are sized using “Quick Function Point Estimation” (or any similar technique

•Briefs the entire team about the project objectives, business initiatives and the corresponding timelines
Product Owner or deadlines for the completion of the project

•Ensures the software developed will meet the requirements and the correct/expected functionality
Clients & Business Stakeholders •Responsible for participating in the estimation meetings, provide clarification to any doubts/queries
that arise during this activity

Project Manager •Responsible for performing estimation along with the developers and designers

Developers and Designers •Design and build the application to meet the requirements

Testers •Validates the system from functional and non-functional requirements perspective
33
Estimation: Project Level

34
Planning: Release Level
• Organizing and scheduling user stories (i.e. functional/non-functional requirements) that are to be converted into the
working software by the team and delivered for that release
• Team decides number of Sprints, for each of the Release in a time-boxed manner
• Release plan can also mention how long a Sprint will be, how big the team will be, who will be working in the team,
when the first Sprint will start, when the last Sprint will finish, number of Sprints, for each of the Release, duration,
goal and content for each Sprint and Release
• Releases are recommended to be planned anywhere between three to six months based on business context for the
annuity (long duration i.e. more than one year) projects and one to three months for the non-annuity projects

To achieve a highly efficient Release plan, it

should be established based on  Helps the team to deliver the expected project output in an
incremental basis to the client which helps them to get an early
feedback
 In the beginning of each Release and Sprint, the planning is revisited
Satisfying all the
stakeholders
and scope is revised due to changing requirements
needs/expectations  The project team can decide to have additional Sprints or Releases
during the course of the project depending on the dynamics at that
point of time
Capability of Readiness to
completion of provide maximum
the scope within business value and
the available ensuring right
capacity sequence of
releases
35
 Planning: Release Level (Various activities involved)

Determine Objective of Release

-Various factors on which the project success
can be evaluated are time of completion, ROI
(Return on Investment)
Estimate the User Stories

-Product Owners definition of success will be -Identify and estimate the size
Prioritize User Stories
generally driven by these factors. Leading (complexity) of the Product Backlog
indicators to asses these factors are items (i.e. User Stories) based on the Select Stories and Define
schedule, effort or cost business value associated with them -Product owner prioritizes the user Release Date
stories available, so that Agile team
-Product Owner discusses the desired can work on it accordingly based on -Release end date is defined collaboratively with
-Estimates provides key inputs that the business necessity common consensus
objective in Release planning meeting needs to be considered for the
Release planning to define the time -If it is functionality or feature driven, estimates user
lines for the Release as well as for the -Product Owner consults the team stories identified by Product Owner and team are
-When the objective is time\date driven summed up and divided by average velocity of team
duration of the Sprint length while prioritizing, sequencing user
output, Product Owner will expect the from the past releases (if available, else taken from
release to be finished by said date. If the stories for the Release
similar projects)
objective is driven by functionality, Product Prioritization Techniques are defined in
Owner will expect ‘x’ functionalities to be earlier slides This will give number of Sprints required to complete
completed by the end of the Release the desired set of functionalities based on which the
Release end date can be defined

-If it is a date-time driven project, number of Sprints are

defined based on the working days. In this case, the
Release end date would be defined based on logical end
of the various modules/functionalities in the software
or the user stories from prioritized list

36
Estimation: Release Level

37
 Estimation types

• Estimation is done for a user story based on its relationship with one or more reference
• Similar sized user stories are grouped and estimation is done for them together
• For example, a user story “Ability to add payee” is estimated for 40 hrs. If the complexity of user story “Ability to edit payee” is half
of add payee, then the effort required for this story would be 20 hrs

38
Estimation types

Uses estimation cards, which is based on Fibonacci series. It is a relative sizing technique and based
on consensus of the team.
Following are the steps followed
• Each member / estimator has a deck of cards, with each card having a valid estimate
• Moderator (who generally does not play) reads a story and it is then discussed briefly
• Product Owner answers any questions that are raised
• Each estimator selects the card representing their estimate and keeps it facing down (hidden)
• Cards are simultaneously turned over so all can see them
• If estimates differ, then the highest and lowest estimator provides justification
• Re-estimate until consensus is reached on the story points

 T-shirt sizing – Each User Story is classified based on t-shirt sizes as XL (eXtra Large), L
(Large), M (Medium), S (Small), XS (eXtra Small) etc.
 Fibonacci series – Relative sizing is done based on Fibonacci series 0, 1, 2, 3, 5, 8, 13,
20, 40, 100,

39
Planning : Sprint Level
• Starts the first day of the Sprint and allows the team to be
more specific on what they are going to deliver at the end of
the Sprint
• Team takes inputs from the Scrum Master and prioritized list
from Product Owner
• Team decides on what they can take from the prioritized
backlog for this Sprint, detail out the tasks for each user story
and assign it to themselves

The Sprint Planning meeting consists of two parts. Explained in

Slide no. 10

Ideally, for a Sprint with 4-weeks duration, the Sprint Planning

meeting happens for one day i.e. 8 hours out of which first four
hours are for the Part-1 and second four hours for the Part-2.

40
Estimation: Sprint Level
• Bottom-up estimation is used in Sprint Planning and tasks are estimated in days /
hours, total of which gives the actual effort for the User Story
• Tasks can be defined related to design, coding, test scenarios, unit testing, test case
execution
• Sprint success means all the parameters are set as part of Definition of Done
• Team members have to own the tasks and estimate for them separately
• Time can be categorized as programming time and non-programming time
• During Release Planning, estimation is done based on relative sizing and gets
automatically considered. During Sprint planning, each task should be estimated by
respective owners
• Tasks are estimated in ideal time. Estimation of ideal time for Tasks translates the
size (measured in story points) to a detailed estimate of effort. This effort is typically
measured in terms of actual days or actual hours. Task estimation is meant for Sprint
Backlog and its existence is within the Sprint Example
Team picks a User Story which may be sized to 5 Story Points. Break it down into a number of smaller working
tasks like designing, implementing and testing.

Team members are asked to sign up for the tasks and estimate the actual effort, measured in hours or
days, for their tasks

When a team uses ideal time for estimating, they refer exclusively time required to get a feature or task
done by the programmer compared to other features or tasks

The effort remaining is displayed in a common place (i.e. Burndown Charts) so that the team is aligned to
meet the estimated goal
For ideal time estimation of tasks, individual team members pick up an activity and provide estimates. If
41 there is a disagreement in these estimates among the team members, then they discuss it and come to
consensus.
Good Practices
1. Estimation for User Story Points:
• Story Point Estimations are reflection of 3 factors
Volume of Work
Complexity
Doubt (i.e. uncertainty/ambiguity in solution)
• Ensure that an estimate reflects the collective understanding of team

2. Team Planning
• Involve the whole team for planning
• With higher involvement, commitment is more from team members
• Team inclined for higher value delivery

3. Frequency of Estimation
• If estimation is difficult, Agile team increases the feedback from the Product Owner to get more clarifications in the
following ways:
1. Shorten the time for estimation and increase it to take feedback about accuracy of estimate
2. Increase the frequency of estimating
3. Sketch out options and get feedback from the client before doing detailed estimation

4. Re-Plan
• Re-plan often, at start of Sprint or Release
• Relevance of the plan has to be evaluated at start of each Release or Sprint and plan is updated
42 • Keeping the relevance of the current plan helps achieve the target
 Good Practices
5. Develop Multiple Estimates:
If requirements and assumptions are unclear, the team develops multiple estimates
• Communicate the assumptions or constraints of the estimates to the relevant stakeholders rather than just the numbers
• Discuss the constraints/assumptions with the relevant stakeholders (i.e. Client or Product Owner)
• Client can provide feedback to better align the team's understanding with the business drivers

6. Consider Learnings while Planning:

• At Sprint retrospective, there is learning about the project which is discussed by the team
• Team must acknowledge learning and consider it while planning

7. Validate Estimates:
• Team to validate estimates by comparing them with other estimates/experiences, use simple rules, and intuitive decision making
• Once the team has agreed on an estimating unit, they should ensure to implement it consistently and stick to its original definition
• Especially in the projects initial Sprints, everyone should resist the urge to try mapping these units to time units with any exact precision

8. Leave some slack while planning:

• Recommended not to plan 100% of every team member’s time on development activities
• Team spends time in non-development activities as well like detailing out user stories whenever required, collaborating with other team
members, attending daily stand up meetings, participating in backlog grooming sessions, clarifying requirements, updating ALM tool, Sprint
Retrospective and Sprint Review
• Plan for approximately 6 hours of effort for development activities and the rest for non-development activities
43
 Soft Skills

44
Characteristics of Agile Team Scenarios where certain soft skill and mindset related aspects
can cause failure of Agile projects
• Lack of learning inquisitiveness among Team members
Needs to be • Lack of collaboration among stake holders
quick at learning • Lack of ownership
&
• Interpersonal Conflicts
comprehending
the project • Unwillingness to share and take additional responsibility
requirements • Absence of open and transparent working attitude
Trust, flexibility
and a great deal
Self-organized
of openness
and disciplined Transparency, Discipline and commitment to work
among the team

Soft skills of a Agile Team member

members
Ready to speak about the road block
Characteristics
of Agile Team Self-organized and motivated
Direct
interaction with Strong at collaboration and communication
the client Not directed or
manager managed by a
Very high degree of learnability
(Product Owner) Project Manager
on a regular
basis Ready to accept the change
Takes decision
on project Believe in Team work

45 Able to negotiate and mange interpersonal conflict

 Behavioral Aspects
• Show high degree of learnability and ready to accept change, proactive in
• Manager doesn’t drive the team. So proactive in raising any concern taking responsibilities, being self-managed and collaborative
at any point of time • Agile coach (or the Scrum master) helps out the team and resolves conflicts
• Sprints are time boxed and also all the meetings. Important to be in a constructive way as a Negotiator. Before going to the coach, team
regular, disciplined and time bound completion of activities member should ask 2 questions:
• Should be flexible to interchange the roles they play based on the 1. Have I shared my concerns with person I am in conflict with?
requirement for the Sprint 2. Do I need an intermediary person to help me sort the issues?
• Two imp pillars: Listening and Questioning. Articulation skills, clarity • Plan approximately 6 hours of every day work for the committed user
of speech, initiate ideas, clarify them, bring other members into stories. Rest for issue resolution and planned/unplanned meetings. Team
discussion (Specially new & less experienced) should handle non-value adding activities like:
• Good analytical skills for problem solving by root cause analysis, Procrastination Unnecessary long breaks
quick, fast and accurate in the analysis Unofficial calls Visitors

• Stand-up meeting should give energy. Clear

sense of the purpose and a clear
understanding what needs to be done.
• Application Lifecycle Management tool used
distinguish this from ‘false urgency’
for planning and tracking Agile projects.
• Meetings expose problems in the project to
Common features are Product Backlog,
the entire team, provides better
Sprint Backlog, Release and Sprint Burndown
opportunity on improvement. Be proactive
charts. Team should update remaining effort
in identifying better ideas and share with
for the tasks they are working upon.
each other
• Each member knows the strength and
• Meetings to be conducted by doing focused
weakness of the team, visual way of tracking
and constructive discussions so that Team
for transparency
member’s attention to the end objective is
• Helps to plan better and improve in the next
never lost
iteration. What went well’, ‘What didn’t go
• Communicate regularly and supportive
well’ & ‘What can be improved’
46
towards each other, and work effectively
 Mind Set Shift
Traditional Mind set Agile Mind shift

• The traditional mindset is to follow all processes and • Mind shift is needed, when working in Agile to move from
methods to achieve the goal constraining change to embracing and leading change
Embracing

• • Practices such as incremental delivery and continuous

Change

No changes are encouraged by the team during the course

of implementation feedback
• Lot of constrains in terms of working collaboratively and • Show regular progress so that necessary corrections are
innovatively done during the course
• Win win situation for both client and the project team

• Team members used to focus on assigned tasks for • Self-organized and self directing teams.
Self-Organizing

completion • Each team member is accountable for self-assignment and

• No awareness on the bigger picture or overall purpose of the completing the assigned work
Teams

project • Team jointly accountable for solving the business problem

• Disconnect in understanding the client/business objective, and project issues
less motivation and no innovation • Self-driven and self-motivated team
• Higher connect with client/business, higher motivation, and
increased innovation
• Focus on collaboration between all the stakeholders and
Collaboration

• Practices based mindset

delivering valuable business outcome
• Behavior based mindset
• Shifting towards embracing the change
• Joint accountability on all the activities
47
• Focusing on value based outcomes
 Transforming from a Traditional Project Team Member to Agile Project
Team Member
• Each Sprint involves a cross-functional team working in all
• Agile methods break Releases into small Sprints functions: planning, requirements analysis, design, coding,
which involve minimal planning • Agile development has Daily unit testing, and acceptance testing.
• Sprints are short time frames (time-boxed) Stand-up meetings • At the end of the Sprint, a working product is
• Last from one to four weeks • Max. for 15 mins demonstrated to stakeholders (Sprint Review)
• Multiple Sprints would be required by the team • What they did the previous day • Helps project team to adapt to changes quickly based on
to release a working software or new features • What they intend to do today the feedback from the stakeholders at the end of the
• What their roadblocks are Sprint

• Agile team has a customer representative, e.g. Product

Owner • Feedback during the incremental development
• Available for the team to answer mid-Sprint questions process increases awareness
• Responsibility of each team member to use the • Helps the project team to develop solutions To improve product quality and
with positive alternatives enhance project agility implement:
availability or time of the Product Owner effectively for
• Team members provide feedback to each other • Continuous Integration
any clarifications/misinterpretation of the functional
that contains a clear purpose, which is specific • Automated Unit Testing
requirements
and descriptive, and offers positive alternatives • Pair Programming
• Test-Driven Development
• Motivated team and has continuous interaction with the • Design Patterns
Product Owner • Code Refactoring
• Technical expertise needed to gather requirements, and During Sprint Retrospective:
develop and test new product line • What to start in the subsequent Sprint
• Soft skills, leadership competencies, and an understanding of • What to stop from the subsequent Sprint onwards
how to apply those skills in a more malleable, people-focused • What should be continued from the previous Sprint to the
48 setting next Sprint
Waste Elimination
 ‘Waste’ is from the Lean principles
 Introduced in the manufacturing industry
 In Software terms, any feature or functionality or process step that neither adds value nor is used are considered as waste
 Should be eliminated from the system/product/process
 Everything is waste which does not add value to the client

49
Waste Elimination
Type Description Ways to eliminate

Extra Features • Providing or developing more  Team must ensure that they get the right information and clarity on scope
functionality than what is required and prioritization of these features (User Stories)
or asked for  Team members to participate in the Release Planning meeting and provide
• Occurs because of improper their inputs from the feasibility, interpretations and implementation of these
understanding of the product vision, stories
or scope of the project by the team  Team should take frequent feedback from the relevant stakeholders to
validate their understanding of the requirements and providing the right
solution or functionality
Delays • Anything that takes or causes more  Team should identify only the mandatory process which would be needed for
time for a value added activity that Sprint
• Caused due to  Should not take any activities which they cannot understand or have no
1. unwanted processes knowledge
2. too many things in progress  All dependencies should be sorted out by continuous collaboration with the
3. dependencies (internal/external) required stakeholders. If there is any dependency with the Architect for
4. assumptions/clarifications example, for any important review during the Sprint, it has to be identified
upfront and planned appropriately. When the team members are distributed
across locations, they should proactively plan for all logistics and backup plans
for any Video/Audio conferences so that they can avoid any delays due to
infrastructure constraints
 Must get all their assumptions clarified at the right time

50
Waste Elimination
Type Description Ways to eliminate

Partially done • User Stories which does not meet the criteria of  Complexity of User Stories should be assessed appropriately so
work ‘Definition of Done’ or has incomplete tasks are that the team can pick it up accordingly. If needed, request the
considered as partially done work Product Owner to explain the stories in further detail
• Occurs due to technical complexity that was not  When stuck somewhere, proper support/aid should be looked
appropriately anticipated during the Sprint Planning for. Cross-functional teams should be leveraged
meeting, or wait time (long gap) between the tasks  Take inputs from the team members while decomposing the user
that were identified for the story completion, or story into tasks
inadequate tasks identification
Defects • indicates erroneous functionality that produces in-  Get the complete understanding of the user story by getting
correct output clarifications from Product Owner or required stake holders
• Caused due to  Acceptance criteria against each User Story is must. If ignored
1. improper understanding of the User Story leads to inconsistencies in the final acceptance
2. failing acceptance criteria  Right skills while working on the project and if required undergo
3. team member’s technical skill incapability trainings to get equipped with right skill sets
4. involvement of testing activities  Involve testers for planning, and strategizing the testing activities
right from the Release stage and during every Sprint Planning
stage
Hand-offs • passing the work or tasks from one person to  Have cross-functional teams
another  Usage of flowcharts and wireframes
• occurs due to nature of tasks required for the user  Executing the tasks at one location as much as possible
story, or if teams are distributed between different
locations, or lack of visibility of the information
51
Waste Elimination
Type Description Ways to eliminate

Context Switching • happens when team members have not  External dependencies related to infrastructure, or environment
completed the present activities and starts dependencies should be identified up front during sprint planning.
working on another activities Impediments discussed in daily stand-up meeting and let the Scrum
• Occurs due to Master work on them
1. shared team, i.e. same members are  Ensure that the User Stories are prioritized during the Sprint Planning
asked to work on another project in parallel meeting else team members would be juggling between stories during
2. various interruptions on the ongoing the Sprint
activities  Team members allocated to a project must be dedicated teams. In
3. improper coordination between the team Agile, assigning the team member’s effort across various projects
members would lead to lower productivity of the individuals as well as for the
overall team
Relearning • reinventing the wheel and not using the  Regular activities for sharing knowledge amongst themselves. Team
existing knowledge repository available members to participate in all the team meetings
amongst the team  Plan for creating the just enough documentation as this is one of the
• Caused due to important artifact for knowledge sharing especially if there are exits or
1. improper knowledge-sharing practices with replacements within the team
in the team  When the teams are distributed, it is very important to leverage the
2. lack of needed content or documentation technology aids i.e. WebEx, Skype, Video/Audio Conferencing, etc. as
3. because of distributed teams per feasibility for interacting with different team members across
location and share the knowledge

52
 THANK YOU

© 2018 Infosys Limited, Bengaluru, India. All Rights Reserved. Infosys believes the information in this document is accurate as of its publication date; such information is subject to change without notice. Infosys
acknowledges the proprietary rights of other companies to the trademarks, product names and such other intellectual property rights mentioned in this document. Except as expressly permitted, neither this
documentation nor any part of it may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, printing, photocopying, recording or otherwise, without the
prior permission of Infosys Limited and/ or any named intellectual property rights holders under this document.