SlideShare a Scribd company logo
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
(c) Dr. Gopinath Ramakrishnan, 2015
Definition of Ready (DoR) &
Definition of Done (DoD)
(c) Dr. Gopinath Ramakrishnan, 2015
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
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
(c) Dr. Gopinath Ramakrishnan, 2015
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
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
https://www.mitchlacey.com/intro-to-agile/scrum/definition-of-done
http://www.scaledagileframework.com/a-scalable-definition-of-done/
(c) Dr. Gopinath Ramakrishnan, 2015
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
Capacity Planning
Sprint Planning Meeting
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
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
(c) Dr. Gopinath Ramakrishnan, 2015
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
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
(c) Dr. Gopinath Ramakrishnan, 2015
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
(c) Dr. Gopinath Ramakrishnan 2015
Backlog Refinement
Product Backlog Refinement
(Backlog Grooming) - Purpose
• Getting the Stories Ready for Sprints
(c) Dr. Gopinath Ramakrishnan 2015
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
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
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
(c) Dr. Gopinath Ramakrishnan 2015
Task Boards
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
Source: Scrum and XP from the Trenches by Henrik Kniberg
Task Board – Warning Signs
43
Source: Scrum and XP from the Trenches by Henrik Kniberg
Burndown Charts
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
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
A sprint burndown chart
Hours
Burndown Chart – Typical Trends
48
https://help.rallydev.com/reading-burndown-chart
Impediment List
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
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
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
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
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
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)
(c) Gopinath Ramakrishnan 2015
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
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
(c) Gopinath Ramakrishnan 2015
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
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
(c) Gopinath Ramakrishnan 2015
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
(c) Gopinath Ramakrishnan 2015
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
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
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
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
Source: http://cs.brown.edu/courses/cs161/notes/xp.ppt
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
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
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
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
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
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
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
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
(c) Gopinath Ramakrishnan 2015
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
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
(c) Gopinath Ramakrishnan 2015
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
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
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
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
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
(c) Gopinath Ramakrishnan 2015
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
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
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
‹‹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
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
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
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.
(c) Gopinath Ramakrishnan 2015
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
Teamwork & Collaboration
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
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
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
6/2/2015 111(c) Gopinath Ramakrishnan, 2015
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
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
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
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
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
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
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
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
(c) Gopinath Ramakrishnan 2015
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
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
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
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
Source: Jurgen Appello’s presentation The Dolt’s Guide to Self-Organization http://www.slideshare.net/jurgenappelo/the-dolts-guide-
to-self-organization
12: Implementing Agile
Implementation Challenges
Critical Success Factors
Implementation Challenges
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
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
(c) Gopinath Ramakrishnan, 2015

More Related Content

What's hot

Agile Transformation v1.27
Agile Transformation v1.27Agile Transformation v1.27
Agile Transformation v1.27
LeadingAgile
 
Agile Scrum Training Process
Agile Scrum Training ProcessAgile Scrum Training Process
Agile Scrum Training Process
Clarion Marketing
 
AGILE@DELOITTE AGILE LANDSCAPE v02
AGILE@DELOITTE AGILE LANDSCAPE v02AGILE@DELOITTE AGILE LANDSCAPE v02
AGILE@DELOITTE AGILE LANDSCAPE v02
Chris Webb
 
Understanding Scrum in 30 Minutes
Understanding Scrum in 30 MinutesUnderstanding Scrum in 30 Minutes
Understanding Scrum in 30 Minutes
Altaf Najvani
 
Sprint Planning in Scrum and How to do it without Tearing Your Eyes Out
Sprint Planning in Scrum and How to do it without Tearing Your Eyes OutSprint Planning in Scrum and How to do it without Tearing Your Eyes Out
Sprint Planning in Scrum and How to do it without Tearing Your Eyes Out
Jason Knight
 
Exploring Agile Transformation and Scaling Patterns
Exploring Agile Transformation and Scaling PatternsExploring Agile Transformation and Scaling Patterns
Exploring Agile Transformation and Scaling Patterns
Mike Cottmeyer
 
Kanban for Portfolio Management
Kanban for Portfolio ManagementKanban for Portfolio Management
Kanban for Portfolio Management
Gaetano Mazzanti
 
The Importance of having a Sprint Goal
The Importance of having a Sprint GoalThe Importance of having a Sprint Goal
The Importance of having a Sprint Goal
Abdul Muhaimin
 
Agile transformation 1.3
Agile transformation 1.3Agile transformation 1.3
Agile transformation 1.3
Krystian Kaczor
 
Agile Transformation | Mike Cottmeyer
Agile Transformation | Mike CottmeyerAgile Transformation | Mike Cottmeyer
Agile Transformation | Mike Cottmeyer
LeadingAgile
 
2017 Scrum by Picture
2017 Scrum by Picture2017 Scrum by Picture
2017 Scrum by Picture
Pawel Lewinski
 
Successful Agile Transformation - The NCS Story
Successful Agile Transformation - The NCS StorySuccessful Agile Transformation - The NCS Story
Successful Agile Transformation - The NCS Story
NUS-ISS
 
Scrum Temelleri
Scrum TemelleriScrum Temelleri
Scrum Temelleri
Ozan Ozcan
 
A New Introduction to Jira & Agile Product Management
A New Introduction to Jira & Agile Product ManagementA New Introduction to Jira & Agile Product Management
A New Introduction to Jira & Agile Product Management
Dan Chuparkoff
 
Being Agile with Scrum - koders.co
Being Agile with Scrum - koders.coBeing Agile with Scrum - koders.co
Being Agile with Scrum - koders.co
Ender Aydin Orak
 
SAFe (Scaled Agile Framework) 5 mins overview - Roni Tamari
SAFe (Scaled Agile Framework) 5 mins overview - Roni TamariSAFe (Scaled Agile Framework) 5 mins overview - Roni Tamari
SAFe (Scaled Agile Framework) 5 mins overview - Roni Tamari
AgileSparks
 
Scrum - Agile Methodology
Scrum - Agile MethodologyScrum - Agile Methodology
Scrum - Agile Methodology
Niel Deckx
 
Product Owner Roles and Responsibilities | Edureka
Product Owner Roles and Responsibilities | EdurekaProduct Owner Roles and Responsibilities | Edureka
Product Owner Roles and Responsibilities | Edureka
Edureka!
 
Agile Estimation & Capacity Planning
Agile Estimation & Capacity PlanningAgile Estimation & Capacity Planning
Agile Estimation & Capacity Planning
Mazhar Khan
 
Agile software development
Agile software developmentAgile software development
Agile software development
Mat Siems
 

What's hot (20)

Agile Transformation v1.27
Agile Transformation v1.27Agile Transformation v1.27
Agile Transformation v1.27
 
Agile Scrum Training Process
Agile Scrum Training ProcessAgile Scrum Training Process
Agile Scrum Training Process
 
AGILE@DELOITTE AGILE LANDSCAPE v02
AGILE@DELOITTE AGILE LANDSCAPE v02AGILE@DELOITTE AGILE LANDSCAPE v02
AGILE@DELOITTE AGILE LANDSCAPE v02
 
Understanding Scrum in 30 Minutes
Understanding Scrum in 30 MinutesUnderstanding Scrum in 30 Minutes
Understanding Scrum in 30 Minutes
 
Sprint Planning in Scrum and How to do it without Tearing Your Eyes Out
Sprint Planning in Scrum and How to do it without Tearing Your Eyes OutSprint Planning in Scrum and How to do it without Tearing Your Eyes Out
Sprint Planning in Scrum and How to do it without Tearing Your Eyes Out
 
Exploring Agile Transformation and Scaling Patterns
Exploring Agile Transformation and Scaling PatternsExploring Agile Transformation and Scaling Patterns
Exploring Agile Transformation and Scaling Patterns
 
Kanban for Portfolio Management
Kanban for Portfolio ManagementKanban for Portfolio Management
Kanban for Portfolio Management
 
The Importance of having a Sprint Goal
The Importance of having a Sprint GoalThe Importance of having a Sprint Goal
The Importance of having a Sprint Goal
 
Agile transformation 1.3
Agile transformation 1.3Agile transformation 1.3
Agile transformation 1.3
 
Agile Transformation | Mike Cottmeyer
Agile Transformation | Mike CottmeyerAgile Transformation | Mike Cottmeyer
Agile Transformation | Mike Cottmeyer
 
2017 Scrum by Picture
2017 Scrum by Picture2017 Scrum by Picture
2017 Scrum by Picture
 
Successful Agile Transformation - The NCS Story
Successful Agile Transformation - The NCS StorySuccessful Agile Transformation - The NCS Story
Successful Agile Transformation - The NCS Story
 
Scrum Temelleri
Scrum TemelleriScrum Temelleri
Scrum Temelleri
 
A New Introduction to Jira & Agile Product Management
A New Introduction to Jira & Agile Product ManagementA New Introduction to Jira & Agile Product Management
A New Introduction to Jira & Agile Product Management
 
Being Agile with Scrum - koders.co
Being Agile with Scrum - koders.coBeing Agile with Scrum - koders.co
Being Agile with Scrum - koders.co
 
SAFe (Scaled Agile Framework) 5 mins overview - Roni Tamari
SAFe (Scaled Agile Framework) 5 mins overview - Roni TamariSAFe (Scaled Agile Framework) 5 mins overview - Roni Tamari
SAFe (Scaled Agile Framework) 5 mins overview - Roni Tamari
 
Scrum - Agile Methodology
Scrum - Agile MethodologyScrum - Agile Methodology
Scrum - Agile Methodology
 
Product Owner Roles and Responsibilities | Edureka
Product Owner Roles and Responsibilities | EdurekaProduct Owner Roles and Responsibilities | Edureka
Product Owner Roles and Responsibilities | Edureka
 
Agile Estimation & Capacity Planning
Agile Estimation & Capacity PlanningAgile Estimation & Capacity Planning
Agile Estimation & Capacity Planning
 
Agile software development
Agile software developmentAgile software development
Agile software development
 

Viewers also liked

Agile quiz answers
Agile quiz answersAgile quiz answers
Agile quiz answers
Altimetrik
 
TCS IT QUIZ QUESTIONS(tcstechbytes2012.blogspot.in)
TCS IT QUIZ QUESTIONS(tcstechbytes2012.blogspot.in)TCS IT QUIZ QUESTIONS(tcstechbytes2012.blogspot.in)
TCS IT QUIZ QUESTIONS(tcstechbytes2012.blogspot.in)
Pooja Shankar
 
Agile Project LifeCycle
Agile Project LifeCycleAgile Project LifeCycle
Agile Project LifeCycle
Shaun Smith, MSPM, PMP
 
User story estimation with agile architectures
User story estimation with agile architecturesUser story estimation with agile architectures
User story estimation with agile architectures
Raffaele Garofalo
 
Architectural runway
Architectural runwayArchitectural runway
Architectural runway
DmitriyViktorov
 
Software architecture in an agile environment
Software architecture in an agile environmentSoftware architecture in an agile environment
Software architecture in an agile environment
Raffaele Garofalo
 

Viewers also liked (6)

Agile quiz answers
Agile quiz answersAgile quiz answers
Agile quiz answers
 
TCS IT QUIZ QUESTIONS(tcstechbytes2012.blogspot.in)
TCS IT QUIZ QUESTIONS(tcstechbytes2012.blogspot.in)TCS IT QUIZ QUESTIONS(tcstechbytes2012.blogspot.in)
TCS IT QUIZ QUESTIONS(tcstechbytes2012.blogspot.in)
 
Agile Project LifeCycle
Agile Project LifeCycleAgile Project LifeCycle
Agile Project LifeCycle
 
User story estimation with agile architectures
User story estimation with agile architecturesUser story estimation with agile architectures
User story estimation with agile architectures
 
Architectural runway
Architectural runwayArchitectural runway
Architectural runway
 
Software architecture in an agile environment
Software architecture in an agile environmentSoftware architecture in an agile environment
Software architecture in an agile environment
 

Similar to Fundamentals of Agile Methodologies - Part II

aa.pdf
aa.pdfaa.pdf
aa.pdf
MANYAGOEL14
 
Introduction to Scrum
Introduction to ScrumIntroduction to Scrum
Introduction to Scrum
Avidan Hetzroni
 
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdfTeaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Bijay Jayaswal, SPC4, RTE, CSM, PMP, MS, MBA
 
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdfTeaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Bijay Jayaswal, SPC4, RTE, CSM, PMP, MS, MBA
 
IntroSCRUM
IntroSCRUMIntroSCRUM
An introduction to Agile & Scrum
An introduction to Agile & ScrumAn introduction to Agile & Scrum
An introduction to Agile & Scrum
Mahdi Taghizadeh
 
Agile Practice Workshop at Eye Care Leaders
Agile Practice Workshop at Eye Care LeadersAgile Practice Workshop at Eye Care Leaders
Agile Practice Workshop at Eye Care Leaders
Syed Nazir Razik ACP, CSM, PMP
 
Essentials of Scrum
Essentials of ScrumEssentials of Scrum
Essentials of Scrum
eikitakeuchi
 
Agile Framework based on PMBOK 6th Edition.pdf
Agile Framework based on PMBOK 6th Edition.pdfAgile Framework based on PMBOK 6th Edition.pdf
Agile Framework based on PMBOK 6th Edition.pdf
AliAfrazAjmal
 
Agile IT Project Management
Agile IT Project ManagementAgile IT Project Management
Agile IT Project Management
Supreeth Rajan
 
Software Development Guide To Accelerate Performance
Software Development Guide To Accelerate PerformanceSoftware Development Guide To Accelerate Performance
Software Development Guide To Accelerate Performance
Zaid Shabbir
 
Introduction to agile and scrum
Introduction to agile and scrumIntroduction to agile and scrum
Introduction to agile and scrum
Inova LLC
 
Scrum rules
Scrum rulesScrum rules
Scrum rules
fredarwin
 
SCRUM methodology
SCRUM methodologySCRUM methodology
SCRUM methodology
Dhanashree Kulkarni
 
Agile.pptx
Agile.pptxAgile.pptx
Agile.pptx
Rafeeq T
 
Agile tutorial
Agile tutorialAgile tutorial
Agile tutorial
Chen-Tien Tsai
 
Scrum
ScrumScrum
Scrum
somyaadwan
 
Agile project management tips and techniques
Agile project management tips and techniquesAgile project management tips and techniques
Agile project management tips and techniques
Bhawani N Prasad
 
Overview of Agile methodology & Scrum
Overview of Agile methodology & ScrumOverview of Agile methodology & Scrum
Overview of Agile methodology & Scrum
Srinivasan Ganesan
 
Scrum
ScrumScrum

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

aa.pdf
aa.pdfaa.pdf
aa.pdf
 
Introduction to Scrum
Introduction to ScrumIntroduction to Scrum
Introduction to Scrum
 
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdfTeaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
 
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdfTeaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
Teaching Scrum Fundamentals_A Quick Guide to Getting Started.pdf
 
IntroSCRUM
IntroSCRUMIntroSCRUM
IntroSCRUM
 
An introduction to Agile & Scrum
An introduction to Agile & ScrumAn introduction to Agile & Scrum
An introduction to Agile & Scrum
 
Agile Practice Workshop at Eye Care Leaders
Agile Practice Workshop at Eye Care LeadersAgile Practice Workshop at Eye Care Leaders
Agile Practice Workshop at Eye Care Leaders
 
Essentials of Scrum
Essentials of ScrumEssentials of Scrum
Essentials of Scrum
 
Agile Framework based on PMBOK 6th Edition.pdf
Agile Framework based on PMBOK 6th Edition.pdfAgile Framework based on PMBOK 6th Edition.pdf
Agile Framework based on PMBOK 6th Edition.pdf
 
Agile IT Project Management
Agile IT Project ManagementAgile IT Project Management
Agile IT Project Management
 
Software Development Guide To Accelerate Performance
Software Development Guide To Accelerate PerformanceSoftware Development Guide To Accelerate Performance
Software Development Guide To Accelerate Performance
 
Introduction to agile and scrum
Introduction to agile and scrumIntroduction to agile and scrum
Introduction to agile and scrum
 
Scrum rules
Scrum rulesScrum rules
Scrum rules
 
SCRUM methodology
SCRUM methodologySCRUM methodology
SCRUM methodology
 
Agile.pptx
Agile.pptxAgile.pptx
Agile.pptx
 
Agile tutorial
Agile tutorialAgile tutorial
Agile tutorial
 
Scrum
ScrumScrum
Scrum
 
Agile project management tips and techniques
Agile project management tips and techniquesAgile project management tips and techniques
Agile project management tips and techniques
 
Overview of Agile methodology & Scrum
Overview of Agile methodology & ScrumOverview of Agile methodology & Scrum
Overview of Agile methodology & Scrum
 
Scrum
ScrumScrum
Scrum
 

Recently uploaded

Transform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR SolutionsTransform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR Solutions
TheSMSPoint
 
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...
XfilesPro
 
GreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-JurisicGreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-Jurisic
Green Software Development
 
KuberTENes Birthday Bash Guadalajara - Introducción a Argo CD
KuberTENes Birthday Bash Guadalajara - Introducción a Argo CDKuberTENes Birthday Bash Guadalajara - Introducción a Argo CD
KuberTENes Birthday Bash Guadalajara - Introducción a Argo CD
rodomar2
 
Modelling Up - DDDEurope 2024 - Amsterdam
Modelling Up - DDDEurope 2024 - AmsterdamModelling Up - DDDEurope 2024 - Amsterdam
Modelling Up - DDDEurope 2024 - Amsterdam
Alberto Brandolini
 
zOS Mainframe JES2-JES3 JCL-JECL Differences
zOS Mainframe JES2-JES3 JCL-JECL DifferenceszOS Mainframe JES2-JES3 JCL-JECL Differences
zOS Mainframe JES2-JES3 JCL-JECL Differences
YousufSait3
 
Oracle 23c New Features For DBAs and Developers.pptx
Oracle 23c New Features For DBAs and Developers.pptxOracle 23c New Features For DBAs and Developers.pptx
Oracle 23c New Features For DBAs and Developers.pptx
Remote DBA Services
 
Oracle Database 19c New Features for DBAs and Developers.pptx
Oracle Database 19c New Features for DBAs and Developers.pptxOracle Database 19c New Features for DBAs and Developers.pptx
Oracle Database 19c New Features for DBAs and Developers.pptx
Remote DBA Services
 
How Can Hiring A Mobile App Development Company Help Your Business Grow?
How Can Hiring A Mobile App Development Company Help Your Business Grow?How Can Hiring A Mobile App Development Company Help Your Business Grow?
How Can Hiring A Mobile App Development Company Help Your Business Grow?
ToXSL Technologies
 
Measures in SQL (SIGMOD 2024, Santiago, Chile)
Measures in SQL (SIGMOD 2024, Santiago, Chile)Measures in SQL (SIGMOD 2024, Santiago, Chile)
Measures in SQL (SIGMOD 2024, Santiago, Chile)
Julian Hyde
 
Mobile App Development Company In Noida | Drona Infotech
Mobile App Development Company In Noida | Drona InfotechMobile App Development Company In Noida | Drona Infotech
Mobile App Development Company In Noida | Drona Infotech
Drona Infotech
 
All you need to know about Spring Boot and GraalVM
All you need to know about Spring Boot and GraalVMAll you need to know about Spring Boot and GraalVM
All you need to know about Spring Boot and GraalVM
Alina Yurenko
 
E-commerce Development Services- Hornet Dynamics
E-commerce Development Services- Hornet DynamicsE-commerce Development Services- Hornet Dynamics
E-commerce Development Services- Hornet Dynamics
Hornet Dynamics
 
ALGIT - Assembly Line for Green IT - Numbers, Data, Facts
ALGIT - Assembly Line for Green IT - Numbers, Data, FactsALGIT - Assembly Line for Green IT - Numbers, Data, Facts
ALGIT - Assembly Line for Green IT - Numbers, Data, Facts
Green Software Development
 
How to write a program in any programming language
How to write a program in any programming languageHow to write a program in any programming language
How to write a program in any programming language
Rakesh Kumar R
 
316895207-SAP-Oil-and-Gas-Downstream-Training.pptx
316895207-SAP-Oil-and-Gas-Downstream-Training.pptx316895207-SAP-Oil-and-Gas-Downstream-Training.pptx
316895207-SAP-Oil-and-Gas-Downstream-Training.pptx
ssuserad3af4
 
Enums On Steroids - let's look at sealed classes !
Enums On Steroids - let's look at sealed classes !Enums On Steroids - let's look at sealed classes !
Enums On Steroids - let's look at sealed classes !
Marcin Chrost
 
8 Best Automated Android App Testing Tool and Framework in 2024.pdf
8 Best Automated Android App Testing Tool and Framework in 2024.pdf8 Best Automated Android App Testing Tool and Framework in 2024.pdf
8 Best Automated Android App Testing Tool and Framework in 2024.pdf
kalichargn70th171
 
Energy consumption of Database Management - Florina Jonuzi
Energy consumption of Database Management - Florina JonuziEnergy consumption of Database Management - Florina Jonuzi
Energy consumption of Database Management - Florina Jonuzi
Green Software Development
 
UI5con 2024 - Keynote: Latest News about UI5 and it’s Ecosystem
UI5con 2024 - Keynote: Latest News about UI5 and it’s EcosystemUI5con 2024 - Keynote: Latest News about UI5 and it’s Ecosystem
UI5con 2024 - Keynote: Latest News about UI5 and it’s Ecosystem
Peter Muessig
 

Recently uploaded (20)

Transform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR SolutionsTransform Your Communication with Cloud-Based IVR Solutions
Transform Your Communication with Cloud-Based IVR Solutions
 
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...
 
GreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-JurisicGreenCode-A-VSCode-Plugin--Dario-Jurisic
GreenCode-A-VSCode-Plugin--Dario-Jurisic
 
KuberTENes Birthday Bash Guadalajara - Introducción a Argo CD
KuberTENes Birthday Bash Guadalajara - Introducción a Argo CDKuberTENes Birthday Bash Guadalajara - Introducción a Argo CD
KuberTENes Birthday Bash Guadalajara - Introducción a Argo CD
 
Modelling Up - DDDEurope 2024 - Amsterdam
Modelling Up - DDDEurope 2024 - AmsterdamModelling Up - DDDEurope 2024 - Amsterdam
Modelling Up - DDDEurope 2024 - Amsterdam
 
zOS Mainframe JES2-JES3 JCL-JECL Differences
zOS Mainframe JES2-JES3 JCL-JECL DifferenceszOS Mainframe JES2-JES3 JCL-JECL Differences
zOS Mainframe JES2-JES3 JCL-JECL Differences
 
Oracle 23c New Features For DBAs and Developers.pptx
Oracle 23c New Features For DBAs and Developers.pptxOracle 23c New Features For DBAs and Developers.pptx
Oracle 23c New Features For DBAs and Developers.pptx
 
Oracle Database 19c New Features for DBAs and Developers.pptx
Oracle Database 19c New Features for DBAs and Developers.pptxOracle Database 19c New Features for DBAs and Developers.pptx
Oracle Database 19c New Features for DBAs and Developers.pptx
 
How Can Hiring A Mobile App Development Company Help Your Business Grow?
How Can Hiring A Mobile App Development Company Help Your Business Grow?How Can Hiring A Mobile App Development Company Help Your Business Grow?
How Can Hiring A Mobile App Development Company Help Your Business Grow?
 
Measures in SQL (SIGMOD 2024, Santiago, Chile)
Measures in SQL (SIGMOD 2024, Santiago, Chile)Measures in SQL (SIGMOD 2024, Santiago, Chile)
Measures in SQL (SIGMOD 2024, Santiago, Chile)
 
Mobile App Development Company In Noida | Drona Infotech
Mobile App Development Company In Noida | Drona InfotechMobile App Development Company In Noida | Drona Infotech
Mobile App Development Company In Noida | Drona Infotech
 
All you need to know about Spring Boot and GraalVM
All you need to know about Spring Boot and GraalVMAll you need to know about Spring Boot and GraalVM
All you need to know about Spring Boot and GraalVM
 
E-commerce Development Services- Hornet Dynamics
E-commerce Development Services- Hornet DynamicsE-commerce Development Services- Hornet Dynamics
E-commerce Development Services- Hornet Dynamics
 
ALGIT - Assembly Line for Green IT - Numbers, Data, Facts
ALGIT - Assembly Line for Green IT - Numbers, Data, FactsALGIT - Assembly Line for Green IT - Numbers, Data, Facts
ALGIT - Assembly Line for Green IT - Numbers, Data, Facts
 
How to write a program in any programming language
How to write a program in any programming languageHow to write a program in any programming language
How to write a program in any programming language
 
316895207-SAP-Oil-and-Gas-Downstream-Training.pptx
316895207-SAP-Oil-and-Gas-Downstream-Training.pptx316895207-SAP-Oil-and-Gas-Downstream-Training.pptx
316895207-SAP-Oil-and-Gas-Downstream-Training.pptx
 
Enums On Steroids - let's look at sealed classes !
Enums On Steroids - let's look at sealed classes !Enums On Steroids - let's look at sealed classes !
Enums On Steroids - let's look at sealed classes !
 
8 Best Automated Android App Testing Tool and Framework in 2024.pdf
8 Best Automated Android App Testing Tool and Framework in 2024.pdf8 Best Automated Android App Testing Tool and Framework in 2024.pdf
8 Best Automated Android App Testing Tool and Framework in 2024.pdf
 
Energy consumption of Database Management - Florina Jonuzi
Energy consumption of Database Management - Florina JonuziEnergy consumption of Database Management - Florina Jonuzi
Energy consumption of Database Management - Florina Jonuzi
 
UI5con 2024 - Keynote: Latest News about UI5 and it’s Ecosystem
UI5con 2024 - Keynote: Latest News about UI5 and it’s EcosystemUI5con 2024 - Keynote: Latest News about UI5 and it’s Ecosystem
UI5con 2024 - Keynote: Latest News about UI5 and it’s Ecosystem
 

Fundamentals of Agile Methodologies - Part II

  • 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.
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. (c) Dr. Gopinath Ramakrishnan, 2015
  • 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
  • 17. DoD & DoR Changes with Experience
  • 18. Don't let anything that's not READY into your Sprint, and Don’t let nothing escape that's not DONE
  • 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
  • 26. Sprint Backlog (contd..) Source : http://www.goodagile.com/scrumprimer/scrumprimer.pdf Source : http://www.mountaingoatsoftware.com
  • 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
  • 28. 6: Sprint Execution & Monitoring Daily Scrum (Daily Standup Meeting) Backlog Refinement Task Board Burndown Charts Impediment List
  • 29. Daily Scrum (Daily Standup Meeting)
  • 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
  • 35. Product Backlog Refinement (Backlog Grooming) - Purpose • Getting the Stories Ready for Sprints (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
  • 47. A sprint burndown chart Hours
  • 48. Burndown Chart – Typical Trends 48 https://help.rallydev.com/reading-burndown-chart
  • 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
  • 55. 7: Sprint Review Sprint Review Objective Potentially Shippable Increment Sprint Review Agenda Demo Workflow
  • 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
  • 62. 8: Sprint Retrospective Retrospective Objectives Retrospective Structure – 5 Steps Healthy Retrospectives Retrospective Prime Directive
  • 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
  • 72. 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
  • 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
  • 99. Agile Architecture Process at Scale http://agilemodeling.com/essays/agileArchitecture.htm
  • 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
  • 104. Values - Agile Manifesto, Scrum & XP
  • 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/
  • 106. Scrum & XP Values Scrum • Commitment • Focus • Openness • Respect • Courage XP • Simplicity • Feedback • Communication • Respect • Courage (c) Gopinath Ramakrishnan, 2015
  • 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
  • 136. 12: Implementing Agile Implementation Challenges Critical Success Factors
  • 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
  • 140. Critical Success Factors for Agile Transition
  • 141. Critical Success Factors • Agile Mindset • Emphasis on Customer Value • Empirical Approach • Cross-functional Team • Self-organization • Collaboration • Automation • Coaching (c) Gopinath Ramakrishnan, 2015