A littlebook about agile
-
Upload
marisagility -
Category
Technology
-
view
34 -
download
0
description
Transcript of A littlebook about agile
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