A Little Book

For

Agile Teams

2.0

M.Maris Prabhakara

Introduction

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

The first value is “Individuals and Interactions over processes and tools”.

Here, the emphasis is on the need to pay attention to individuals and the

interactions between them. You only need process descriptions to get a group of

people started. However, you discover new solutions and flaws in old solutions

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, that documents

showing requirements, analysis, design, screen flows etc. aid the development

process. But, we realize that the working system shows what the team has

actually built. The working software is the only reliable measure of the 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 with amicability,

joint decision-making, openness and rapidity of communication. Although

contracts are useful, collaboration strengthens development. Good collaboration

is a winning element when contract is in jeopardy or even when there is no

contract.

The fourth value is about responding quickly to changing project

parameters and not sticking to a rigid plan. Having a plan and referring to 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 the people, business

as well as 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.

Agile Principles

Satisfy the

Customer

Welcome Ch

ange in Req

uirements

12 Principles

of

Agile

Deliver Wor

king Softwar

e Frequently

Measure of

Progress Wo

rking Softwa

re

From Self O

rganized Te

am

Practice Sim

plicity

Give Attenti

on to Techn

ical Excellen

ce Promote Sus

tainable De

velopment

Motivate In

dividual

Facilitate Fa

ce to Face

Conversation

Work

Together

Reflect to b

ecome

effective

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.

Agile Umbrella

Agile is a light weight iterative and incremental software development appro

ach executed with a self-organized ,highly collaborative and cross functional

teams that delivers quality software with time to market advantage and adapta

ble to changing needs of the stakeholder.

Agile methodology is people centric, collaborative, adoptive to change, feedbac

k 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

Scrum

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 Sc

rum

Events section of this document:

Sprint Planning

Daily Scrum

Sprint Review

Sprint Retrospective

Roles :-

Scrum Master,

Product owner and

Development Team

XP

Extreme Programming is a discipline of software development based on values of simplic

ity, 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 wh

ere 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

DSDM

It is the number one framework for rapid application development (RAD) in the UK. DSD

M 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 ti

me 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

The Rational Unified Process (RUP)

Adaptive Software Development (ASD)

The Rational Unified Process (RUP)

The Rational Unified Process (RUP) is a process product developed and marketed by IB

M 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 softwa

re 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 (A

MDD), 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 Managemen

t,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

Pragmatic Programming

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.

Kanban

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.

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)

SCALED AGILE

SAFe

DAD

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.

SCALED AGILE

LESS & PLOP

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 experien

ce, community, and the insights of its founders and inventors.

The ScrumPLoP mission is to build a body of pattern literature around those communitie

s, describing those insights, so we can easily share them with the Scrum and Agile com

munities.

Paradigm Shift

ONION PLANNING

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