Fundamentals of Agile Methodologies - Part II

Fundamentals of
Agile Methodologies - II
Compiled By:
Dr. Gopinath Ramakrishnan
Agile Coach & Process Transformation Specialist
Contact Information:
e-mail: gopi@rgopinath.com
LinkedIn: www.linkedin.com/in/gopinathr
Twitter: @gpnth
Website: www.rgopinath.com

Note
The contents of the following slides are
compiled from public domain works of
several persons/ organizations.
Their contribution is gratefully acknowledged
their copyrights and trademarks are
duly recognized.

Acknowledgements
• Agile 42: www.agile42.com
• Agile Alliance: www.agilealliance.org
• Agile Transformation Inc: www.agiletransformation.com
• Dzone: www.dzone.com
• Gear Stream: www.gearstream.com
• Henrik Kniberg: www.crisp.se/henrik.kniberg
• Jeff Sutherland : scrum.jeffsutherland.com
• Jurgen Appelo: www.jurgenappelo.com
• Ken Schwaber: kenschwaber.wordpress.com/
• Kent Beck: www.threeriversinstitute.org
• Mike Cohn: www.mountaingoatsoftware.com
• Mitch Lacey: www.mitchlacey.com
• Pete Deemer: www.goodagile,com
• Roman Pichler: www.romanpichler.com
• Ron Jeffries: xprogramming.com
• Scaled Agile Inc.: www.scaledagileframework.com
• Scrum Alliance: www.scrumalliance.org
• Scrum.org: www.scrum.org
• VersionOne: www.versionone.com
• Wikipedia: www.wikipedia.org

Contents
5. Sprint Planning
 Pre-requisites - Definition of Ready, Definition of Done,
Capacity Planning
 Sprint Planning Meeting - Sprint Goal, Sprint Backlog ,
Task Planning,
 Sprint Commitment (Capacity Based/ Velocity Based)
6. Sprint Execution and Monitoring
 Daily Scrum (Daily Standup Meeting)
 Backlog Refinement
 Task Board
 Burndown Charts
 Impediment List
7. Sprint Review
 Sprint Review Objective
 Potentially Shippable Increment
 Sprint Review Agenda
 Demo Workflow

Contents (contd..)
8. Sprint Retrospective
 Retrospective Objectives
 Retrospective Structure – 5 Steps
 Healthy Retrospectives
 Retrospective Prime Directive
9. Extreme Programming – Engineering Practices
 Customer Tests
 Continuous Integration
 Pair Programming
 Refactoring
 Simple Design
 Test-driven Development
 Metaphor
 Coding Standard

Contents (contd..)
10. Agile and Lean Architecture
 Software Architecture – Definition and Common
Themes
 Architecture & Agile Principles
 Architectural Epics and Architectural Runway
 Emergent Design and Intentional Architecture
 Lean Architecture
 7 Principles of Agile Architecture
 Agile Architect Role
11. Agile Values and Mindset
 Values – Agile Manifesto, Scrum & XP
 Teamwork & Collaboration
 Self-Organization & Delegation
12. Implementing Agile
 Implementation Challenges
 Critical Success Factors

5: Sprint Planning
Pre-requisites - Definition of Ready, Definition of Done
Capacity Planning
Sprint Planning Meeting - Sprint Goal, Sprint Backlog ,
Task Planning,
Sprint Commitment (Capacity Based/ Velocity Based)
(c) Dr. Gopinath Ramakrishnan, 2015

Definition of Ready (DoR) &
Definition of Done (DoD)

Definition of Ready (DoR)
• Explicit and Visible Sprint Entry Criteria for
Product Backlog and User Stories
• Avoids beginning work on features that are
not well defined
– Team to "push back“ such features
• Reduces “requirements churn" during the
Sprint

Product Backlog – Definition of Ready
Detailed Appropriately
Estimated
Emergent
Prioritized
Source:
Agile Product Management, Roman Pichler
Ensure higher priority items in the
Product Backlog are broken down into
smaller stories (< 13 SP) as compared
to lower priority stories
The product backlog is READY when about
1-2 Sprint's worth of User Stories at the
top of the backlog are READY

User Story – Definition of Ready (DoR)
• Meets most of the INVEST criteria
• Clarity in Description
• Prioritized & Ordered
– Taking into account value, constraints and risks from business,
technical and project management perspectives
• Acceptance Criteria Defined
– Supported by appropriate documentation (if needed for better
understanding )
• Dependencies Identified
– Should be resolvable with the Sprint
• Sized Small
– Should get DONE within the Sprint
• Can be Tested & Demoed

User Story - Definition of Done (DoD)
• Exit criteria for a User Story to be considered
“DONE".
• Checklist of necessary, value-added activities
to ensure user story quality
• By Default applicable to each User Story
• An agreement between all the members of
the Team on what does DONE mean in their
context

User Story - Definition of Done (DoD)
(contd..)
• Ideal Definition of Done
– defines all steps necessary to deliver a finished
increment from development till deployment in
production. No further work is needed.
• Realistic Definition of Done
– defines the steps the team is currently capable of
doing in one sprint.

https://www.mitchlacey.com/intro-to-agile/scrum/definition-of-done

http://www.scaledagileframework.com/a-scalable-definition-of-done/

DoD & DoR Changes with Experience

Don't let anything that's not
READY into your Sprint,
and
Don’t let nothing escape that's
not DONE

Sprint Planning Meeting
• Collaborative
– Entire Team participates along with the PO
• Time-boxed
– Max. 2 hrs per week of Sprint
• Purpose
– To arrive at a shared understanding with the PO on
the work that needs to be completed as per the
Definition of Done
• Two Parts:
– What work will be completed ?
– How it will be completed ?

Sprint planning meeting
Sprint prioritization
• Analyze and evaluate product
backlog
• Select sprint goal
Sprint planning
• Decide how to achieve sprint goal
(design)
• Create sprint backlog (tasks) from
product backlog items (user
stories / features)
• Estimate sprint backlog in hours
Sprint
goal
Sprint
backlog
Business
conditions
Team
capacity
Product
backlog
Techno-
logy
Current
product

Sprint Goal - Examples
• To provide a standardized middleware mechanism for the identified
customer service transactions to access backend databases
• This Sprint we will allow users to log-in to the site, retrieve a forgotten
password, and manage their own profile
• Customer Payment Sprint

Sprint Commitment (Forecast) –
Two Approaches
• Capacity Based Commitment
– Summation of estimated ideal hours for the
stories committed should be close (+/- 10 %) of
the sprint capacity
• Velocity Based Commitment
– Summation of Story points for the stories
committed should be close to the average velocity
of the past sprints

Sprint Backlog
• A highly visible, real-time picture of the tasks that
the team plans to accomplish during the Sprint
• Contains effort estimates for each task
• Estimates are in ideal hours
– Ideal hours is the hours that a task will take to
complete assuming there are no interruptions at all
• Task should be granular enough to get completed
between 4 to 8 hrs.
• Tasks may be added/modified/deleted by the
Team during the Sprint as per the team

Sprint Backlog (contd..)
Source : http://www.goodagile.com/scrumprimer/scrumprimer.pdf
Source : http://www.mountaingoatsoftware.com

Effective Practices : Planning
• Start planning only when Product Backlog is READY
• Plan for consistent Sprint lengths
• Progressive Refinement of Plans
• Plan for working on a sustainable pace
– Plan for only 5.5-6.5 hours of productive work per day
– Factor Support work in the estimates
• Adjust the Scope of the project to fit available resources and
schedule
• Treat an estimation as a forecast (rather than commitment at
any cost)
• Break down and estimate tasks at 4-8 hrs granularity

6: Sprint Execution & Monitoring
Daily Scrum (Daily Standup Meeting)
Backlog Refinement
Task Board
Burndown Charts
Impediment List

Daily Scrum (Daily Standup Meeting)

Daily Standup – Goals
• To help start the day well
• To support improvement
• To reinforce focus on the right things
• To reinforce the sense of team
• To communicate what is going on
(c) Dr. Gopinath Ramakrishnan 2015

The Daily Scrum
• Parameters
– Daily
– 15-minutes
– Stand-up
• Not for problem solving
– Whole world is invited
– Only Team Members, ScrumMaster, Product
Owner, can talk
• Helps avoid other unnecessary meetings

Everyone Shares
• These are not status for the ScrumMaster
– They are commitments in front of peers
What did I do yesterday?
1
What will I do today?
2
Is there any impediment in my
way?
3

Daily Standup – Anti Patterns
• Coming Late
• Irrelevant Talks
• Side Conversations
• Using Cellphones /Tablets
• Looking at the Facilitator/Manager while talking
• Talking too much
• Problem solving
• Not bringing out the issues/impediments openly
• Waiting till the Standup to raise
issues/impediments

Product Backlog Refinement
(Backlog Grooming) - Purpose
• Getting the Stories Ready for Sprints

Product Backlog Refinement (Grooming)
• PBI for upcoming Sprints reviewed and revised
– Collaboratively between the PO and the Team
– Approx. 10 % of Sprint Capacity allocated for Refinement
• Refinement includes but not limited to:
– Reordering
– Detailing/Consolidating
– Estimating
• A refined PBI :
– Meets “Definition of Ready” before Implementation begins
– Expected to fulfill “Definition of Done” criteria within a
single Sprint

Product Backlog - Qualities
• Detailed
– Higher Priority/Order items more detailed than the lower ones
• Estimated
– Coarse-grained estimates expressed in Story Points
• Emergent
– New Items added
– Existing items modified/reprioritized/removed
• Prioritized
– All Items prioritized and ordered

Product Backlog – Level of Details
Source : Agile Product Management with Scrum by Roman Pichler

Product Backlog Refinement Meeting -
Benefits
• Increases the clarity of the requirements
• Eliminates wasteful handoffs
• Creates buy-in and joint ownership
• Leads to efficient and effective Sprint Planning
Meetings

Task Board (Scrum Wall)
Source: Scrum and XP from the Trenches by Henrik Kniberg

Task Board – Visible Progress
End of Day 1
42
After Few Days
•White Notes are User Stories from the Product Backlog.
•Yellow Notes are Tasks in Sprint Backlog
•Stories are posted in the order of decreasing priority

Task Board – Warning Signs
43

Managing the sprint backlog
• Individuals sign up for work of their own choosing
– Work is never assigned
• Estimated work remaining is updated daily
• Any team member can add, delete or change the
sprint backlog
• Work for the sprint emerges
• If work is unclear, define a sprint backlog item with a
larger amount of time and break it down later
• Update work remaining as more becomes known

Hours
40
30
20
10
0
Mon Tue Wed Thu Fri
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Mon
8
16
8
12
Tues Wed Thur Fri
4
12
16
7
11
8
10
16 8
50

Burndown Chart – Typical Trends
48
https://help.rallydev.com/reading-burndown-chart

Impediment List
• Contains Items that prevents or slows down
the team from doing their Work
• Typical Impediments
– Hardware Failure
– Software/ Tools Unavailability
– Implementation Roadblocks
– Lack of Time/ People

Impediment List
• A mechanism to record and track the
impediments reported by team members
• Created and Maintained by ScrumMaster
• Impediments to be brought to recorded as
soon as they are identified
• ScrumMaster’s responsibility to remove
impediments

Effective Practices:
Sprint Execution and Monitoring
• High visibility of status of the work
– through Task Boards
• Incremental and Iterative Delivery
• Daily Scrum - Same Time, Same Place
• Sprint Timebox strictly enforced
• Sprint Backlog kept aligned to Sprint Goal
• Collaboration technologies to track progress
6/2/2015 52(c) Dr. Gopinath Ramakrishnan 2015

Sprint Execution and Monitoring (contd..)
• Use engineering practices like :
– Pair programming, code reviews, unit testing,
refactoring, continuous integration
• Start Testing activities at the earliest possible day
• Test Automation at three levels
– Unit, Service and User Interface
• Test-driven development both at unit test level
and acceptance test level
• Pay Off Technical Debt at the earliest
– Technical debts examples - program/system crash,
performance deterioration, obsolete versions

Sprint Execution and Monitoring (contd..)
• Prefer Verbal Discussions for clarifying
requirements
• Strike a right balance between discussions
and documentation
– Documentation and Written Communications
supplement verbal discussions not vice versa
• Keep Product Backlog in a Single and Highly
Visible Location

7: Sprint Review
Sprint Review Objective
Potentially Shippable Increment
Sprint Review Agenda
Demo Workflow

Sprint Review Objectives
• To Get Feedback from the Stakeholders
through demo of Potentially Shippable
Increment (PSI)
• To Identify Product Backlog Items for
forthcoming Sprints
• To Motivate Team Members
• To Encourage Team Spirit
(c) Gopinath Ramakrishnan 2015

Increment
• Integrated, Potentially Shippable subset of the
product
• Delivered at the end of the sprint
• High enough quality to be given to users
• Meets the team's current Definition of Done
• Is acceptable to the product owner

The Sprint Review
• Team presents what it accomplished during
the sprint
• Typically takes the form of a demo of new
features or underlying architecture
• Informal
– 2-hour prep time rule
– No slides
• Whole team participates
• Invite the world

Sprint Review - A Typical Agenda
• Overview of the Sprint (PO/ SM)
– Sprint #; Sprint Start Date; Sprint End Date
– Sprint Goal
– Number of Stories Planned
– Number of Stories DONE
• Definition of DONE (Team Member)
• Demo of Stories (Team Member)
• General Feedback (Stakeholders external to the
team)
• Summary of the Feedback and Next Steps (PO)

Sprint Review – Demo Workflow
• Story Description
• Story Acceptance Criteria
• Story Demo
• Quick Q & A (max. 5 mins)
[For each story that is being Demoed]

Effective Practices : Sprint Review
• Plan in advance . Involve the entire team
• Invite all stakeholders
• Sensitize the stakeholder to the fact that the features being demonstrated
are not the final product
• Demonstrate software only from a clean and tested integration
environment that can be connected from the demo room
• Capture both positive and negative feedback
• Do not commit any features or work for the next Sprint during the Sprint
Review.
• Celebrate a successful review; Retrospect an unsuccessful review
6/2/2015
(C) Dr. Gopinath R., 2011
61

8: Sprint Retrospective
Retrospective Objectives
Retrospective Structure – 5 Steps
Healthy Retrospectives
Retrospective Prime Directive

Agile Principle # 12
At regular intervals,
the team reflects on
how to become more effective,
then tunes and adjusts its behavior accordingly.
Retrospectives Implement this Principle

Sprint Retrospective - Objectives
• To Reflect on how the last Sprint was executed
– with regards to people, relationships, process,
and tools
• To Identify what went well
• To Identify and Prioritize the improvements
• To Create Action Items for improvements

Sprint Retrospective
• Periodically take a look at what is and is not
working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
– ScrumMaster
– Product Owner
– Team
– Possibly customers and others

Start / Stop / Continue
• Whole team gathers and discusses what
they’d like to:
Start doing
Stop doing
Continue doingThis is just one
of many ways to
do a sprint
retrospective.

5- Step Retrospective
1. Set the Stage
– Preparing for the work you will do in the retrospective
2. Gather Data
– Creating a shared picture of what happened during the
iteration, release, or project
3. Generate Insights
– Analyzing and interpreting the data.
4. Decide What to Do
– Proposing , Prioritizing and Planning Actions
5. Close the Retrospective
– Summarizing the Retrospective Session
Agile Retrospectives – Making Good Teams Great , Esther Derby & Diana Larsen

Retrospective Techniques - Sources
• Agile Retrospectives – Making Good Teams
Great , Esther Derby & Diana Larsen
• Agile Retrospective Resource Wiki
• Retr-O-Mat

Healthy Retrospectives
• Entire Team is Engaged in Lively Discussions
– Work + Fun
• Identification of Action Items for Improvement
– Specific, Measurable, Attainable, Relevant, Timebound
• No Complaining & Finger Pointing

Sprint Retrospective
• First half of the retrospective - looking back to understand
what happened and why.
• Second half of the retrospective - looking forward and
deciding on a plan of action.
• Find out what problems the team wants to fix most.
• Don’t commit to more actions than can be completed before
the next retrospective.
• If the actions from last retrospective weren’t done, find out
why before adding any more.
6/2/2015 70(c) Gopinath Ramakrishnan 2015

Retrospective – Prime Directive
Regardless of what we discover,
We understand and truly believe that
everyone did the best job they could,
given
what they knew at the time,
their skills and abilities,
the resources available, and
the situation at hand.
Norman L. Kerth
http://www.retrospectives.com/pages/retroPrimeDirective.html

9: Extreme Programming (XP) –
Engineering Practices
Customer Tests
Continuous Integration
Pair Programming
Refactoring
Simple Design
Test-driven Development
Metaphor
Coding Standard
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt

XP Practices
Source: http://www.xprogramming.com/xpmag/whatisxp.htm

XP Practices: Customer Tests
• The Customer defines one or more automated
acceptance tests for a feature
• Team builds these tests to verify that a feature is
implemented correctly
• Once the test runs, the team ensures that it keeps
running correctly thereafter
• System always improves, never backslides

XP Practices: Simple Design
• Build software to a simple design
• Through programmer testing and design
improvement, keep the software simple and the
design suited to current functionality
• Not a one-time thing nor an up-front thing
• Design steps in release planning and iteration
planning
• Teams design and revise design through refactoring,
through the course of the project

XP Practices: Pair Programming
• All production software is built by two programmers,
sitting side by side, at the same machine
• All production code is therefore reviewed by at least
one other programmer
• Research into pair programming shows that pairing
produces better code in the same time as
programmers working singly
• Pairing also communicates knowledge throughout
the team

XP Practices: Test-Driven Development
• Teams practice TDD by working in short cycles of
adding a test, and then making it work
• Easy to produce code with 100 percent test coverage
• These programmer tests or unit tests are all collected
together
• Each time a pair releases code to the repository,
every test must run correctly

XP Practices: Refactoring
• Continuous design improvement process called
‘refactoring’:
– Removal of duplication
– Increase cohesion
– Reduce coupling
• Refactoring is supported by comprehensive testing--
customer tests and programmer tests

XP Practices: Continuous Integration
• Teams keep the system fully integrated at all
times
• Daily, or multiple times a day builds
• Avoid ‘integration hell’
• Avoid code freezes

XP Practices: Coding Standard
• Use common coding standard
• All code in the system must look as though
written by an individual
• Code must look familiar, to support collective
code ownership

XP Practices: Metaphor
• XP Teams develop a common vision of the system
• With or without imagery, define common system of
names
• Ensure everyone understands how the system works,
where to look for functionality, or where to add
functionality

Session 9:
Agile and Lean Architecture
Software Architecture – Definition and Common Themes
Architecture & Agile Principles
Architectural Epics and Architectural Runway
Emergent Design and Intentional Architecture
Lean Architecture
7 Principles of Agile Architecture
Agile Architect Role

Software Architecture –
A Set of Decisions about Software System
• Which structural elements to select ?
• What will be their public interfaces?
• How elements behave and collaborate ?
• How elements are integrated ?
• System Quality Attributes – Usability, Resilience,
Reliability, Performance, Scalability, Reusability
• Constraints – economic, technology, aesthetic

Software Architecture – Common
Themes
• The highest-level breakdown of a system into its
components
• A shared understanding of major components of
the system and how they interact
• The decisions that are hard to change
• Subjective
• Multiple architectures in a system
• What is architecturally significant can change
over a system's lifetime

Architecture & Agile Principles
Agile Principle # 11
– The best architectures, requirements, and designs
emerge from self-organizing teams.
Agile Principle # 9
– Continuous attention to technical excellence
and good design enhances agility.
Agile Principle #10
– Simplicity--the art of maximizing the amount
of work not done--is essential.
Source: http://www.agilealliance.org

Emergent Design
• Discovering and extending the design only as
necessary for the next increment
• Less economical as the system size increases

Architectural Epics
• Large, technology development initiatives with wide impact
on schedule, scope and organization
• Examples
– Building UI framework to port ‹‹applications to mobile devices.
– Building a common installer and licensing mechanism
– Implementing an industry security standard
– ‹‹Refactoring back-office applications to run 64-bit servers.
– ‹‹Supporting latest version of the customer’s platform
– ‹‹Implementing the new UI standard for corporate branding.
– ‹‹Replacing the search engine’s underlying database with MySQL

Architectural Runway
• Technological infrastructure necessary
– for delivering high priority business features
without excessive delay-inducing redesign
• To be incrementally built and tested behind
the scene
– while delivering business features

Intentional Architecture
• A set of purposeful, planned
architectural epics
–that enhance solution design,
performance and usability
• Common architectural vision, strategy,
and governance model
–to provide guidance for inter-team design
and implementation synchronization

Intentional Architecture must be a
Lean Architecture!
Lean Architecture Traditional Architecture
Easy to introduce large changes as
requirements emerge
Limits large changes
Defers full scale implementation .
Focuses first on lightweight APIs and
descriptions of relationships
Rushes into implementation to force
code reuse or compliance to standards (at
platforms and library levels) OR
No implementation at all
Lightweight Documentation Documentation-focused, to describe the
implementation or compensate for its
Absence.
Focus on domain expertise, end-user
experience, end-user mental model
Focus on technical aspects ( for e.g.
cohesion and coupling), tools and
notations
Collective planning and Collaboration Specialized planning and control
Based on: Lean Architecture for Agile Software Development by James Coplien and Gertude Bjornvig

7 Principles of Agile Architecture
[As per Scaled Agile Framework (SAFe)]
• ‹‹Principle #1: Design emerges. Architecture is a
collaboration.
• Principle #2: The bigger the system, the longer the
runway.
• Principle #3: Build the simplest architecture that can
possibly work.
• ‹Principle #4: When in doubt, code it or model it out.
• ‹‹Principle #5: They build it, they test it.
• ‹‹Principle #6: There is no monopoly on innovation.
• ‹‹Principle #7: Implement architectural flow.
Source : http://www.scaledagileframework.com/agile-architecture

Principle #1:
Design emerges. Architecture is a collaboration
• Fast, local control of Emergent Design
• Global control of Intentional
Architecture
• Intentional Architecture constrains
Emergent Design
• Emergent Design influences and
corrects Intentional Architecture

Principle #2:
The bigger the system, the longer the runway
• Smaller system runway
– Enough to support a single iteration or release
• Bigger system runway
– Takes longer than single release cycle to build
– Needs more foresight, investment and planning
to build

Principle #3:
Build the simplest architecture that can possibly
work
• Simple, common language to describe the system
• Solution model close to problem domain
• Continuous refactoring
• Object/Component interfaces express their intent
• Simplify both design and team communication
• Enables evolution of maintainable and extensible
solution

Principle #4:
When in doubt, code it or model it out
• Obtain fast feedbacks through
– Spikes (Technical/ Functional), Rapid prototyping
– A/B tesing
• Lightweight Agile modeling constructs
– Domain modeling
– Use-case modeling

‹‹Principle #5:
They build it, they test it
• Designers responsible for Testability
• Large scale system testing for
– functional, operational, performance, reliability
• Automated testing infrastructure built
– to enable ongoing system-level testing
• Testing infrastructure evolve with evolving
architecture

Principle #6:
There is no monopoly on innovation
• Architects not the only source of innovation
• Innovation from anyone and anywhere
• Ideas synthesized into architectural runway
• IP (Innovation-Planning) sprints

Principle #7:
Implement architectural flow
• Architects continuously extend the
architectural runway
– by interacting with Agile Release Train
• Avoid the delays and overhead
– introduced by starting and stopping projects every
time there is a new initiative.
• Provide visibility and transparency, provide
work-in-process limits, actively manage queue
lengths

Agile Architecture Process at Scale
http://agilemodeling.com/essays/agileArchitecture.htm

Agile Architect Role
• Architectural Scout
• Technology Researcher
• Maker of a few big decisions
• Information Conduit
• Facilitator of Design Discussions
• Design Skills Coach
Source:
http://www.slideshare.net/SeanDunnCDPEngPMP/agile-2015-architecture-draft

Case Study
Agile Architecture Journey @ IHS Inc.
http://www.slideshare.net/SeanDunnCDPEngP
MP/agile-2015-architecture-draft

Agile Architects
• Balance the needs of multiple stakeholders
• Use efficient agile techniques in their own
working practices and delivery processes
• Make sure that neither they nor other agile
developers compromise the larger picture.

11: Agile Values and Mindset
Values – Agile Manifesto, Scrum & XP
Teamwork & Collaboration
Self-Organization & Delegation

Values - Agile Manifesto, Scrum & XP

The Agile Manifesto
We are uncovering better ways of developing software by doing it
and helping others to do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.
Agile Alliance Members
http://www.agilemanifesto.org/

Scrum & XP Values
Scrum
• Commitment
• Focus
• Openness
• Respect
• Courage
XP
• Simplicity
• Feedback
• Communication
• Respect
• Courage
(c) Gopinath Ramakrishnan, 2015

The Five Dysfunctions of a Team
1. Absence of Trust
2. Fear of Conflict
3. Lack of Commitment
4. Avoidance of Accountability
5. Inattention to Results
http://www.amazon.in/The-Five-Dysfunctions-Team-Leadership/dp/0787960756

Agile Team Characteristics
• Shared Vision
• Collectively Responsible and Accountable
• High Trust Level
• Participative and Consensus based Decisions
• Positive Conflicts over Ideas

Effective Practice - Team Structure
• Team size : 5 to 9 members (Two-pizza teams)
• Prefer Feature Team over Component Team structure
• Team Composition
– Include all needed skills
– Balance technical and domain skills
– Seek diversity of thought
– Consider how team members have worked together in
past
• Avoid assigning team members to multiple projects
• Do not combine Scrum Master and Product Owner
roles
6/2/2015 110(c) Gopinath Ramakrishnan, 2015

Effective Practices - Teamwork
• Develop shared responsibility and commitment
to deliver
• Reduce hand-offs between team members
• Don’t keep too many partially completed items
towards the end of the Sprint
• Commit to an optimum mix of sizes of product
backlog items during Sprint Planning
• Encourage Team learning and Knowledge Sharing
• Avoid Knowledge Waste
– Minimize work interruptions, hand-offs
– Don’t fail to capture any acquired knowledge

Effective Practices: Distributed Teams
• Acknowledge Cultural Differences
• Build Trust by Emphasizing Early Progress
• Get Together in Person
– Seeding Visits, Contact Visits, Travelling Ambassadors
• Increase Documentation
– Supplement High-level User Stories with detailed specifications
– Written Status Reports, e-mails, minutes of the meeting
• Encourage Lateral Communication
• Meetings
– Include time for small talk; share the time zone pain; identify yourself while
speaking
• Scrum of Scrums

Working Collaboratively – An Example
Based on the Source:
http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/KanbanAndScrumInfoQVersionFINAL.pdf

Source:
http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/KanbanAndScrumInfoQVersionFINAL.pdf

Working Agreement
• Ground Rules for the Team Members for
– Better Team Work
– A High Quality Potentially Shippable Feature
• Team forms and follows the Ground Rules
– Rules not imposed by bosses
• Describes positive behaviors to be exhibited &
good practices to be followed

A Working Agreement Effective if it …
• Is Actionable
• Addresses Issues of Highest Importance
• Is Supported by every Team member
• Has a Limited Number of Clear-cut Rules (just 5
to 7)
• Is Based on Definition of Ready, Definition of
Done, Agile Principles and Values
• Is Displayed Prominently in the Team Work Area

Working Agreement – An Example
• We will be on time for meetings and actively
participate in them
• We will communicate in an open and transparent
manner
• We will not hesitate to ask help from others if we
are stuck with a problem
• We will work to ensure that high priority stories
are DONE at the earliest during the Sprint
• We will not check-in the code in the main branch
before getting it reviewed and unit tested

Self-Organization and Delegation

Self-organization… a definition
“Self-organization is a process of attraction and
repulsion in which the internal organization of a
system, normally an open system, increases in
complexity without being guided or managed by
an outside source.”
Source: http://en.wikipedia.org/wiki/Self-organization

“Self-organization requires that the system is
surrounded by a containing boundary. This
condition defines the "self" that will be developed
during the self-organizing process.”
Source: http://amauta-international.com/iaf99/Thread1/conway.html

The containing boundary has a chance to
direct self-organization
towards value
Source: Jurgen Appello’s presentation The Dolt’s Guide to Self-Organization http://www.slideshare.net/jurgenappelo/the-dolts-guide-
to-self-organization

Don’t go here! Go there!

Skill/Will Matrix
http://danspira.files.wordpress.com/2010/04/skill-will-matrix-advice-1.gif

1. Tell: make decision as the manager
2. Sell: convince people about decision
3. Consult: get input from team before decision
4. Agree: make decision together with team
5. Advise: influence decision made by the team
6. Inquire: ask feedback after decision by team
7. Delegate: no influence, let team work it out
The Seven Levels of Authority

12: Implementing Agile
Implementation Challenges
Critical Success Factors

Why Agile Projects Fail ?
• Lack of Experience with Agile Methods
• Company Philosophy or Culture at odds with core agile
values
• Lack of Management Support
• External Pressure to follow traditional waterfall process
• Lack of support for cultural transition
• A broader organizational or communications problem
• Unwillingness of team to follow agile
• Insufficient Training
[Based on VersionOne report - 9th Annual State of Agile Survey 2015]
http://info.versionone.com/state-of-agile-development-survey-ninth.html

What Impedes Agile Adoption ?
• Ability to change organization culture
• Not enough personnel with agile experience
• General organizational resistance to change
• Pre existing rigid/waterfall framework
• Management support
• Management concerns about lack of upfront planning
• Business/user/customer availability
• Concerns about a loss of management control
• Confidence in methods for scaling agile
• Concerns about the ability to scale agile
• Development team support
• Perceived time and cost to make the transition
• Regulatory compliance
[Based on VersionOne report - 9th Annual State of Agile Survey 2015]
http://info.versionone.com/state-of-agile-development-survey-ninth.html

Critical Success Factors for Agile
Transition

Critical Success Factors
• Agile Mindset
• Emphasis on Customer Value
• Empirical Approach
• Cross-functional Team
• Self-organization
• Collaboration
• Automation
• Coaching

Fundamentals of Agile Methodologies - Part II

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Fundamentals of Agile Methodologies - Part II

Similar to Fundamentals of Agile Methodologies - Part II (20)

Recently uploaded

Recently uploaded (20)

Fundamentals of Agile Methodologies - Part II