This document provides an overview of several agile frameworks and methodologies including Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), Feature Driven Development (FDD), Crystal family of methodologies, Adaptive Software Development (ASD), Pragmatic Programming, Kanban, Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), Large-Scale Scrum (LESS), and Pattern Languages of Programs (PLoP). It describes the key concepts, principles, roles, and practices of each agile methodology at a high level.

1. A Little Book
For
Agile Teams
2.0
M.Maris Prabhakara

2. Introduction

3. Values
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

4. The first value is “Individuals and Interactions over processes tools”. Here, the emphasis is on the need to pay attention individuals and interactions between them. You only need process descriptions to get a group of people started. However, you discover new solutions and flaws in old through discussions between people. Quality of interactions matter. When push comes to shove, Agilists prefer undocumented process with good interactions rather than documented processes with hostile interactions.
The second value “Working software over comprehensive documentation” stresses that the running code is ruthlessly honest. We know, documents showing requirements, analysis, design, screen flows etc. aid the development process. But, we realize that the working system shows what team has actually built. The working software is the only reliable measure of team’s speed, and shortcomings. It gives a glimpse of the final product. Documents should be “just enough” and barely sufficient”.
The third value “Customer Collaboration” over contract negotiation replaces “us” and them” with just us”. Collaboration deals amicability, joint decision-making, openness and rapidity of communication. Although contracts are useful, collaboration strengthens development. Good is a winning element when contract is in jeopardy or even when there no contract.
The fourth value is about responding quickly to changing project parameters and not sticking to a rigid plan. Having plan and referring it is useful until it gets too far from the current situation. Planning for longer periods is going to be tricky, because all the parameters like people, business as well the requirements are dynamic. Therefore, Agile stresses on having just enough planning at all levels and being flexible to change. It is better to be approximately right than accurately wrong.

5. Agile Principles
Satisfy the Customer
Welcome Change in Requirements
12 Principles of
Agile
Deliver Working Software Frequently
Measure of Progress Working Software
From Self Organized Team
Practice Simplicity
Give Attention to Technical Excellence
Promote Sustainable Development
Motivate Individual
Facilitate Face to Face Conversation
Work
Together
Reflect to become
effective

6. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

7. Agile Umbrella
Agile is a light weight iterative and incremental software development approach executed with a self-organized ,highly collaborative and cross functional teams that delivers quality software with time to market advantage and adaptable to changing needs of the stakeholder.
Agile methodology is people centric, collaborative, adoptive to change, feedback based, short cycled delivery approach driven by values and principles that are formally listed in agile manifesto (http://www.agilemanifesto.org).
Agile is an umbrella term used for different methodologies like
1. Scrum,
2. Extreme Programming(XP),
3. DSDM (Dynamic Systems Development Method),
4. FDD (Feature Driven Development)
5. Crystal family of methodologies
6. Agile Unified Process
7. Adaptive Software development
8. Pragmatic Programming

9. Scrum

10. Originally derives from a strategy in rugby and denotes getting an out-of-play ball back into the game with team-work. Scrum is an agile software development framework. Work is structured in cycles of work called sprints, iterations of work that are typically two to four weeks in duration. During each sprint, teams pull from a prioritized list of customer requirements, called user stories, so that the features that are developed first are of the highest value to the customer. At the end of each sprint, a potentially shippable product is delivered.
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum is:
 Lightweight
 Simple to understand
 Difficult to master
Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum
Events section of this document:
 Sprint Planning
 Daily Scrum
 Sprint Review
 Sprint Retrospective
Roles :-
 Scrum Master,
 Product owner and
 Development Team

11. XP

12. Extreme Programming is a discipline of software development based on values of simplicity, communication, feedback, and courage. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.
 The XP customer role is responsible for writing stories and acceptance tests for each story, and sits with the development team.
 On an XP project the distinction between programmer and tester is blurred. Programmers write unit tests of their own code; testers program automated acceptance tests.
 XP projects include a coach and possibly a separate project manager who are responsible for guiding the team and removing obstacles from its way.
Extreme Programming involves the following practices:
 small releases
 the planning game
 refactoring
 testing
 pair programming
 sustainable pace
 collective code ownership
 coding standard
 simple design
 metaphor
 continuous integration
 on-site customer
And has these values:
 communication
 simplicity
 feedback
 courage
Roles & Responsibilities
 Programmer:
 Customer:
 Tester:
 Tracker
 Coach:
 Consultant:
 Manager

13. DSDM

14. It is the number one framework for rapid application development (RAD) in the UK. DSDM works on the premise that instead of fixing the amount of functionality in a product, and then adjusting the time and resources to attain that functionality, it is preferred to fix the time and resources and then adjust the functionality accordingly.
Process Model: It consists of 5 phases
 Feasibility Study:
 Foundations:
 Exploration:
 Engineering:
 Deployment:
Roles & Responsibilities
The key roles in Atern can be considered under three category headings:
 Project Level roles – the managers, coordinators and directors of the project work. They are not normally involved in the day-to-day development of the solution, although they should always have sufficient visibility of it to understand progress and provide strategic direction from a business, technical or project governance perspective as required.
 Solution Development Team roles – the shapers, builders of the solution. They are collectively responsible for the day-to-day development of the solution and for assuring its fitness for business purpose.
 Other roles – encapsulating other stakeholders, perspectives and specialisms not specifically described above. These roles are likely to provide assistance and guidance to the project team as required throughout the lifecycle.
Principles of DSDM
 Principle 1: Focus on the business need
 Principle 2: Deliver on time
 Principle 3: Collaborate
 Principle 4: Never compromise quality
 Principle 5: Develop Iteratively
 Principle 6: Build incrementally from firm foundations
 Principle 7: Communicate continuously and clearly.
 Principle 8: Demonstrate control

15. The Rational Unified Process (RUP)
Adaptive Software Development (ASD)

16. The Rational Unified Process (RUP)
The Rational Unified Process (RUP) is a process product developed and marketed by IBM Rational Software. The RUP provides the details required for executing projects using the UP, including guidelines, templates, and tool assistance.
Agile Unified Process is a simplified version of the Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The agile UP is much simple both in its approach and in its description. The approach applies agile techniques include test driven development (TDD), Agile Model Driven Development (AMDD), agile change management, and database refactoring to improve your productivity.
Process: There are four phases split into iterations, each with the purpose of producing a demonstrable piece of software.
 Inception:
 Elaboration:
 Construction
 Transition:
The disciplines are: Model,Implementation.,Test ,Deployment.,Configuration Management,Project Management
Adaptive Software Development (ASD)
Adaptive Software Development (ASD) focuses on problems in developing large, complex systems. ASD is component-oriented (rather than task-oriented). In the “collaborate” phase of the “adaptive development cycles” several components could be developed in parallel. Planning the cycles is a part of the iteration, where the definitions of the components are continuously refined. In the above diagram, “quality reviews” indicate demonstrating the developed functionality (and not just review/testing) in the presence of customers/experts. The final QA and Release stage should capture the lessons learned.
Roles and Responsibilities:No team structures are described in detail. But the roles include executive sponsor, facilitator (to plan and lead “Joint Application Development - JAD” sessions), scribe (to make minutes of JAD sessions), project manager, customer and developers.
Practices:ASD proposes very few practices for day to day software development work. It does not prescribe many practices – basically they are described as what “could” be done rather than what “should” be done.
The practices mentioned in ASD are:
 Iterative Development
 Feature Component Based Planning
 Customer Focus Group Reviews

17. Pragmatic Programming

18. Pragmatic Programming does not contain any processes, phases, roles, work products or practices. It is a collection of programming best practices (about 70 tips focusing of day- to-day problems) covering the most practical and undisputed way of programming.
Philosophy:
 Take responsibility of what you do. Think solutions instead of excuses.
 Don’t put up with bad design or coding. Fix inconsistencies as you see them, or plan them to be fixed soon.
 Take an active role in introducing change where you feel it is necessary.
 Make software that satisfies your customer, but know when to stop.
 Constantly broaden your knowledge.
 Improve your communication skills.

19. Kanban

20. Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and team members pull work from a queue. Kanban can be divided into two parts:  Kanban – A visual process management system that tells what to produce, when to produce it, and how much to produce.  The Kanban method – An approach to incremental, evolutionary process improvement for organizations. The name 'Kanban' originates from Japanese, and translates roughly as "signal card". The Kanban method as formulated by David J. Anderson is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. The Kanban method is rooted in four basic principles: Start with what you do now  The Kanban method does not prescribe a specific set of roles or process steps. The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system. Agree to pursue incremental, evolutionary change  The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. Sweeping changes may seem more effective but have a higher failure rate due to resistance and fear in the organization. The Kanban method encourages continuous small incremental and evolutionary changes to your current system. Respect the current process, roles, responsibilities & titles  It is likely that the organization currently has some elements that work acceptably and are worth preserving. We must also seek to drive out fear in order to facilitate future change. By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban initiative. Perhaps presenting Kanban against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.

21. Leadership at all levels  Acts of leadership at all levels in the organization from individual contributors to senior management should be encouraged. Anderson identified five core properties that had been observed in each successful implementation of the Kanban method. They were later relabeled as practices and extended with the addition of a sixth. 1. Visualise 2. Limit WIP 3. Manage flow 4. Make policies explicit 5. Implement feedback loops 6. Improve collaboratively, evolve experimentally (using models and the scientific method)

22. SCALED AGILE
SAFe
DAD

23. SAFe
Scaled Agile Framework (SAFe) is one of the most implemented scaled agile frameworks of the time. Let’s have a quick insight into SAFe:
1. The Scaled Agile Framework®, or SAFe, provides a recipe for adopting Agile at enterprise scal 2. SAFe tackles the tough issues – architecture, integration, funding, governance and roles at scale. It is field-tested and enterprise-friendly. 3. SAFe is the brainchild of Dean Leffingwell. As Ken Schwaber and Jeff Sutherland are to Scrum, Dean Leffingwell is to SAFe. 4. SAFe is based on Lean and Agile principles. 5. There are three levels in SAFe: * Team * Program * Portfolio
Core values are Code Quality , Alignment ,Transparency and Program execution
DAD
“The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.” There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD is a non-proprietary, freely available framework. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users. It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you.

24. SCALED AGILE
LESS & PLOP

25. LESS Large-scale Scrum is regular Scrum applied to large-scale development. One tipping point in large-scale Scrum is when it is necessary to add more support to the Product Owner. One Product Owner can directly interact with up to 10 teams (at least, the way we help set things up). Of course, there are cases where 10 is too high. Beyond that there is a need for a set of Area Product Owners as well. The following two framework examples for large-scale Scrum reflect this basic variation point in the organizational structure. Organizational Structure for Large-Scale Scrum for up "ten" teams with one Product Owner Organizational Structure for Large-Scale Scrum for "many" teams with one Product Owner and several Area Product Owners SCRUM PLOP PLoP stands for Pattern Languages of Programs. Alistair Cockburn describes software development as a cooperative game. Scrum provides one set of rules for one such way of playing the game. The Scrum Guide is the official rule book. However, the Scrum Guide doesn't tell you the rationale behind Scrum as a whole, or behind many of its successful practices. Those rationales come out of experience, community, and the insights of its founders and inventors.
The ScrumPLoP mission is to build a body of pattern literature around those communities, describing those insights, so we can easily share them with the Scrum and Agile communities.

26. Paradigm Shift
ONION PLANNING

27. What is INVEST?
Independent
User Stories should be as independent as possible
Negotiable
They are reminders of features for the team to discuss and collaborate to clarify the details at the time of development
Valuable
User Stories should be valuable to the user (or owner) of the solution
Estimatable
User Stories need to be possible to estimate
Appropriately Sized
User Stories should be small. Not too small. But not too big
Testable
User Stories need to be worded in a way that is testable