This presentation has been compiled using material available in public domain. Copyrights of the owners and sources of the material used has been duly acknowledged.
1. 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
2. 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.
9. Definition of Ready (DoR) &
Definition of Done (DoD)
(c) Dr. Gopinath Ramakrishnan, 2015
10. 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
(c) Dr. Gopinath Ramakrishnan, 2015
11. 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
12. 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
(c) Dr. Gopinath Ramakrishnan, 2015
13. 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
(c) Dr. Gopinath Ramakrishnan, 2015
14. 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.
(c) Dr. Gopinath Ramakrishnan, 2015
21. 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 ?
(c) Dr. Gopinath Ramakrishnan, 2015
22. 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
23. 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
24. 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
(c) Dr. Gopinath Ramakrishnan, 2015
25. 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
(c) Dr. Gopinath Ramakrishnan, 2015
27. 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
(c) Dr. Gopinath Ramakrishnan, 2015
30. 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
31. 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
32. 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
33. 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
(c) Dr. Gopinath Ramakrishnan 2015
36. 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
(c) Dr. Gopinath Ramakrishnan 2015
37. 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
(c) Dr. Gopinath Ramakrishnan 2015
38. Product Backlog – Level of Details
Source : Agile Product Management with Scrum by Roman Pichler
39. 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
(c) Dr. Gopinath Ramakrishnan 2015
41. Task Board (Scrum Wall)
Source: Scrum and XP from the Trenches by Henrik Kniberg
42. 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
Source: Scrum and XP from the Trenches by Henrik Kniberg
43. Task Board – Warning Signs
43
Source: Scrum and XP from the Trenches by Henrik Kniberg
45. 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
(c) Dr. Gopinath Ramakrishnan 2015
46. 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
50. 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
(c) Dr. Gopinath Ramakrishnan 2015
51. 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
(c) Dr. Gopinath Ramakrishnan 2015
52. 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
53. Effective Practices:
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
6/2/2015 53(c) Dr. Gopinath Ramakrishnan 2015
54. Effective Practices:
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
6/2/2015 54(c) Dr. Gopinath Ramakrishnan 2015
56. 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
57. 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
58. 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
59. 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)
(c) Gopinath Ramakrishnan 2015
60. Sprint Review – Demo Workflow
• Story Description
• Story Acceptance Criteria
• Story Demo
• Quick Q & A (max. 5 mins)
[For each story that is being Demoed]
(c) Gopinath Ramakrishnan 2015
61. 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
63. 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
(c) Gopinath Ramakrishnan 2015
64. 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
(c) Gopinath Ramakrishnan 2015
65. 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
66. 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.
67. 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
(c) Gopinath Ramakrishnan 2015
Agile Retrospectives – Making Good Teams Great , Esther Derby & Diana Larsen
68. Retrospective Techniques - Sources
• Agile Retrospectives – Making Good Teams
Great , Esther Derby & Diana Larsen
• Agile Retrospective Resource Wiki
• Retr-O-Mat
(c) Gopinath Ramakrishnan 2015
69. 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
(c) Gopinath Ramakrishnan 2015
70. Effective Practices:
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
71. 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
(c) Gopinath Ramakrishnan 2015
74. 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
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt
75. 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
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt
76. 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
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt
77. 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
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt
78. 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
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt
79. 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
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt
80. 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
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt
81. 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
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt
82. 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
83. 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
(c) Gopinath Ramakrishnan 2015
84. 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
(c) Gopinath Ramakrishnan 2015
85. 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
86. Emergent Design
• Discovering and extending the design only as
necessary for the next increment
• Less economical as the system size increases
(c) Gopinath Ramakrishnan 2015
87. 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
(c) Gopinath Ramakrishnan 2015
88. 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
(c) Gopinath Ramakrishnan 2015
89. 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
(c) Gopinath Ramakrishnan 2015
90. 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
(c) Gopinath Ramakrishnan 2015
Based on: Lean Architecture for Agile Software Development by James Coplien and Gertude Bjornvig
91. 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
92. 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
(c) Gopinath Ramakrishnan 2015
93. 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
(c) Gopinath Ramakrishnan 2015
94. 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
(c) Gopinath Ramakrishnan 2015
95. 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
(c) Gopinath Ramakrishnan 2015
96. ‹‹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
(c) Gopinath Ramakrishnan 2015
97. 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
(c) Gopinath Ramakrishnan 2015
98. 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
(c) Gopinath Ramakrishnan 2015
100. 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
101. Case Study
Agile Architecture Journey @ IHS Inc.
http://www.slideshare.net/SeanDunnCDPEngP
MP/agile-2015-architecture-draft
102. 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.
(c) Gopinath Ramakrishnan 2015
103. 11: Agile Values and Mindset
Values – Agile Manifesto, Scrum & XP
Teamwork & Collaboration
Self-Organization & Delegation
105. 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/
108. 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
(c) Gopinath Ramakrishnan, 2015
http://www.amazon.in/The-Five-Dysfunctions-Team-Leadership/dp/0787960756
109. Agile Team Characteristics
• Shared Vision
• Collectively Responsible and Accountable
• High Trust Level
• Participative and Consensus based Decisions
• Positive Conflicts over Ideas
(c) Gopinath Ramakrishnan, 2015
110. 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
111. 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
6/2/2015 111(c) Gopinath Ramakrishnan, 2015
112. 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
6/2/2015 112(c) Gopinath Ramakrishnan, 2015
113. Working Collaboratively – An Example
Based on the Source:
http://www.infoq.com/resource/minibooks/kanban-scrum-minibook/en/pdf/KanbanAndScrumInfoQVersionFINAL.pdf
126. 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
(c) Gopinath Ramakrishnan 2015
127. 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
(c) Gopinath Ramakrishnan 2015
128. 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
(c) Gopinath Ramakrishnan, 2015
130. 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
131. “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
132. 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
133. 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!
135. 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
Source: Jurgen Appello’s presentation The Dolt’s Guide to Self-Organization http://www.slideshare.net/jurgenappelo/the-dolts-guide-
to-self-organization
138. 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
(c) Gopinath Ramakrishnan, 2015
139. 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