Agile Concepts

Agile
Concepts
A New Software Development Paradigm
Pritam Dey

PRITAM DEY
AGILE CONCEPTS
A NEW SOFTWARE
DEVELOPMENT PARADIGM
bookboon eLibrary – Partner of Siemens Global Learning Campus

2
Agile Concepts: A New Software Development Paradigm
1st edition
© 2017 Pritam Dey & bookboon.com
ISBN 978-87-403-1850-0

3
AGILE CONCEPTS Contents
CONTENTS
Table of Figures 6
Acknowledgement: 7
1 Introduction to Agile 8
What is Agile? 8
Agile Manifesto 8
Agile Values 9
AGILE Principles 12
History of Agile 16
2 Agile Thinking 20
Waterfall Approach 22
Waterfall vs. Agile 25
3 Benefits of Agile 26
5 Generic Agile Process 28
Leadership skills
Learn how to think strategically and become a better leader
Click here

4
AGILE CONCEPTS Contents
6 Common Agile Roles 30
7 Common Agile Techniques 33

Stories and backlog refinement 33
Agile Planning 38
Agile Testing 40
TFD (Test First Development) 41
TDD (Test Driven Development) 41
ATDD (Acceptance Test Driven Development) 42
BDD (Behaviour Driven Development) 43
Specification by Example 43
8 Common Agile Practices 45

Short feedback loops 45
Face-to-face communication 45
Daily stand-ups 45
Show and tells 46
Retrospectives 47
Emergent documentation 48
Visual boards 48
Sustainable pace 50
Focus on quality 51
Refactoring 51
Continuous Integration 51
Automated Builds 52
Code Review and Peer Review 52
9 Major Agile Frameworks 54

Extreme Programming (XP) 57
Scrum 61
Dynamic Systems Development Method (DSDM) 63
Crystal Methodology 65
Feature Driven Development (FDD) 66
Lean Software Development 67
Adaptive Software Development 69
Agile Project Management 70
Kanban 70
Scaled Agile Framework (SAFe) 71
10 Glossary 74
11 References 86

5
AGILE CONCEPTS Table of Figures
TABLE OF FIGURES
Figure 1: Waterfall Model 23
Figure 2: Generic Agile Process 28
Figure 3: Agile Stories Breakdown 36
Figure 4: Agile Planning – 1 38
Figure 5: Agile Planning – 2 39
Figure 6: Agile Testing Quadrants 40
Figure 7: Test Driven Development 42
Figure 8: Daily Standup 46
Figure 9: Sample Burndown Chart 49
Figure 10: Release Burnup 50
Figure 11: Waterfall Model 55
Figure 12: Predictive vs. Adaptive 55
Figure 13: Extreme Programming Project 59
Figure 14: XP Process 60
Figure 15: Scrum 62
Figure 16: Dynamic Systems Development Method (DSDM) 63
Figure 17: Adaptive Software Development 69
Figure 18: 3-Level SAFe 73
Figure 19: 4-Level SAFe 73

6
AGILE CONCEPTS Acknowledgement:
ACKNOWLEDGEMENT:
This eBook is a compilation of various Agile framework thoughts and concepts summarized
and put together in an easily readable and digestible format. My deep gratitude goes to the
Agile pioneers in the industry, framework-provider organizations, and colleagues whom I have
worked with in the Agile discipline. The intent of this eBook is to explain Agile concepts in
a nutshell and propagate the adoption of Agile. It is not my intent to introduce materials
as my own creation. I am, as always, indebted to the industry from which I learned so
much. As far as possible, I have tried to cite the source of my references. Any omission is
purely unintentional and accidental.

7
AGILE CONCEPTS Introduction to Agile
1 INTRODUCTION TO AGILE
WHAT IS AGILE?
Agile is the ability to create and respond to change to succeed in an uncertain and turbulent
environment.(Source: www.agilealliance.org)
Agile Software Development is an umbrella term for a set of methods and practices based
on the values and principles expressed in the Agile Manifesto. Solutions evolve through
collaboration between self-organizing, cross-functional teams utilizing the appropriate practices
for their context. (Source: www.agilealliance.org)
AGILE MANIFESTO
In early 2001, a group of seventeen independent-minded software practitioners – called
The Agile Alliance – met to define Agile and outline the development and delivery of Agile
frameworks. They were motivated to create an Agile framework that would allow quick design,
development and delivery of software. The industry until then (and still is) were struggling
with extremely slow software delivery and the associated processes and methodologies. The
initial workings of the Agile Alliance let to the first-ever creation of The Manifesto of the Agile
Alliance. Even though the manifesto says ‘The Manifesto for Agile Software Development’,
the Agile values and principles can easily be applied to many types of product development.
The Manifesto of the Agile Alliance:

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others 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.

8
The following 12 principles are based on the Agile Manifesto:
1. Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.
AGILE VALUES
The four Agile Manifesto statements or values are described briefly below:
• Individuals and interactions over processes and tools

People are the most important asset of any organization and key ingredient of any
successful endeavor. The most common trilogy familiar to the industry is People, Process,
and Technologies (or Tools). Of these three, the most important is the People. Processes
and tools may only take us that far and are not sufficient to save a project from failure.
What is needed is a team of strong players and diverse skills. People understand better
what value they can deliver to the customer; hence they are the best suited to leverage
the processes and tools to realize that value.
The key aspect of people is the ability to work collaboratively with others. A strong team
member may not be an expert in his/her field. But what matter is the ability to work well
with others, communicating and interacting with them in a transparent manner. Building
the right team is more important than building the environment with processes and tools.
Therefore, in Agile, individuals and interactions are valued more than processes and tools.

9
• Working software over comprehensive documentation

Every software product comes with supporting documentation (e.g. technical user
guide). Unfortunately, sometimes more emphasis is provided to writing comprehensive
documentation than on coding working software. Customers derive value from a product
that meets their needs rather than a well-driven document. It’s better to have a working
software product but a poor supporting documentation.
While a fit-for-purpose documentation is key (software without documentation is a

disaster), the focus should be on writing working code. If the purpose of documentation is
for better knowledge transfer among team members, what better ways to achieve this than
writing a code that is human-readable and help from the team. Agile, therefore, stresses
more on writing code that provides value through regular visible incremental delivery of
the working product. Agile also stresses highly on human-to-human interaction which
is considered the most efficient way to transfer knowledge of the product being built.
Documentation is important but it needs to be short and salient; it must be human-

readable that can efficiently describe the system, its highest-level structures, and rational
for the design decisions taken.
Therefore, in Agile, working software is given more focus than comprehensive

documentation.
• Customer collaboration over contract negotiation

An effective product is built when there is a close and regular collaboration between the
customer and supplier. Imagine building your long-cherished dream home. You do all the
groundwork to identify an experienced builder. You negotiate with him to create a contract
that specified your requirements, schedule, and cost. Both parties sign the contract; you
leave it up to him to complete the work, and go for a multi-month world tour hoping
that your dream home will be ready by the time you are back. Months pass and it’s time
to visit your new home. Horror of horrors. You are shocked to see that the home is not
only incomplete; the design is way-off than what you specified, the cost has escalated
beyond your budget, and the schedule has gone way beyond what has been agreed upon
in the contract. What is even more amusing being that the builder is blaming you for
everything; he would take none of the responsibility for the fiasco. At that moment, you
are not even sure when the home will be ready and handed over to you. Sounds familiar?
This is typically what happens with software development too. Too many software
development projects fail mainly for the reasons outlined above.

10
Successful projects involve customer feedback on a regular and frequent basis. Customer
collaborate closely with the development team, providing frequent feedback on their
work along the journey. Customer is aware what is being developed, the developers the
customer requirements. There is minimum surprise on customer acceptance test criteria
or requirement changes.
It is not that contracts are not negotiated and created. In Agile, the contracts are written
to govern the way customers and suppliers would collaborate for a mutually satisfactory
conclusion. Agile contract concentrates on enabling inspection and adaptation of the
product, prioritization and collaboration between all stakeholders.
Therefore, in Agile, customer collaboration is given more weightage than contract

negotiation.
• Responding to change over following a plan

A successful organization is one that can respond to change faster than its competitors.
Similarly, a successful software projects is one that can respond to change better.
Often we create a plan hoping that it will stand the test of time. But the ground reality
is that no plan is intelligent enough to consider the future. Things change every moment.
And therefore, to execute on a plan that is undergoing invisible changes means setting
up ourselves for failure.
A software project plan is also like above; it cannot be planned very far into the future.
Things are always likely to change. Conditions in the marketplace changes, business
strategy changes, software requirements change. The people and cost of things changes;
due to unforeseen events, the schedule may change. Therefore, it is almost impossible to
deliver an effective software product if change mechanism is not built into it.
A better planning strategy is one where the plan is created around certainty, tentativeness,
and best guess. We know for certain what is going to happen in the next two weeks; we
guess what may happen tentatively in the next 2–8 weeks; and we may take a guess what
might happen beyond 8 weeks. Project requirements and functionality also follow the
same visibility path. We certainly know what requirements are in the next 2–4 weeks;
we roughly know the requirements for the next three months; and we barely know the
requirements 12 months out.

11
Therefore, Agile believes that up-front project plans are not commitment plans; it is
understood that the plans are merely forecast best guesses based on experience and facts;
and change is inevitable as the project develops.
Incremental software development based on a short-term detailed plan is a better ingredient

for success. Hence in Agile, program/projects plans are defined at a high-level keeping in
mind that the plans are expected to change.
Agile recommends that a plan is built with the understanding that it is flexible and ready
to adapt to change in business or technical environment.
Therefore, in Agile, responding to change is a better plan than following an inflexible plan.
AGILE PRINCIPLES
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
Instead of big bang approach, Agile focuses on deliver incremental value to customer by
delivering software product in a frequent, consistent, regular, and incremental manner.
Agile refutes the myth that the more functionality is packaged in the product, the higher
the quality of the product will be. On the contrary, Agile believes that the quality of the
product is inversely proportional to the level of functionality. The less functional the initial
delivery, the higher the quality in the final product.
As a corollary, Agile also believes that the more frequent the deliveries, the higher the final
quality. This will eventually lead to a more satisfied and involved customer. It is likely to
make them more likely to accept the product being delivered. And if something is amiss,
they would eagerly report on changes they want addressed.
2. Welcome changing requirements, even late in development. Agile processes

harness change for the customer’s competitive advantage.
Agile team encourages and embraces changes if the changes are requested regularly and in
increments. The team views changes to requirements as healthy because they appreciate
the fact that the business team (product owner) has gained more knowledge about
conditions in the market that led to the changes. Note that Agile focuses on collaboration
between customer and development team. And addressing changes effectively and delivered
incremental value to customer are key outcome of such collaboration.

12
In Agile delivery, the business requirements are broken down into smaller features or
components that can be well understood, defined, designed, tested and delivered. The
team keeps the architecture of the software flexible so that when changes are addressed,
the impact to the product is minimal.
This approach significantly reduces the risk of the poor quality of the product being
delivered;
3. Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.
Agile frameworks focus on delivering working software, early (after first few weeks) and
regularly (every few weeks) that satisfies the customer’s needs.
A key metric that is used is ‘cost of delay.’ This means what is the cost to the business
of not completing a requested functionality or product feature. This allows customer to
identify the opportunity cost of requirements. The most valuable product features may
not make the best economic decision. With this metric, customers can understand the
cost of delaying the implementation of one feature over another.
4. Business people and developers must work together daily throughout the project.
Collaboration is a key Agile principle. Agile encourages face-to-face communication and
frequent interaction between the customer, developers, and stakeholders using a language
that is easy for all to understand. The intent is to eliminate all surprises and ambiguities.
Software project needs constant monitoring and guidance, and collaboration provides that.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
Agile considers the team of right people most important factors of successful software
delivery. The other factor such as process, environment, management, and ambience are
considered secondary and therefore these factors are built around the requirements of
the team.
Agile believes in empowering the team so that it stays motivated and productive. If the
team members can trust one another, Agile can be successful.

13
6. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
In Agile, the default mode of communication is face-to-face conversation. The usage of
emails and other non-human mode of communication is kept limited. Even if situations
where the teams are distributed geographically, virtual collaboration or co-location is
encouraged. Written communication is not able to convey everything; it is prone to
misunderstanding. A lot of communication happens through body language and visual
cues. Hence Agile stresses the importance of face-to-face communication. Agile team (the
typical size of the team is anywhere between 3 to 10 people) members meets together
every day for 10–15 minutes. This huddle is called daily standup which we will discuss
more in later sections.
7. Working software is the primary measure of progress.

The main objective of Agile is to deliver incremental value to customer frequently and
regularly. In Agile, project success is measured by the amount of software that is delivered
and met the customer’s needs. The progress is not measured by the lines of code written,
time spent, completed phases of the project, or the value of documentation produced.
Progress is truly measured by the number of functionalities that is delivered and working.
Communication skills
Discover how to be a better communicator
Click here

14
8. Agile processes promote sustainable development. The sponsors, developers,

and users should be able to maintain a constant pace indefinitely.
Agile believes in running a marathon than short sprints. The Agile team tries to sustain
the momentum of project delivery till the final working software product is delivered.
Agile team work at a sustainable pace so that things such a burnout, demotivation, people
leaving unexpectedly, unrealistic schedule, or human stresses are minimized. A healthy
sustainable pace minimizes the risk of ‘technical debt’ in a product. Technical debt is “a
concept in programming that reflects the extra development work that arises when code
that is easy to implement in the short run is used instead of applying the best overall
solution.” (Source: www.techopedia.com). Sustainable development ensures that technical
debt is best avoided, and quality working product is delivered regularly.
9. Continuous attention to technical excellence and good design enhances agility.

Agile team focus on technical excellence and good design from the start. There is no
corner-cutting or quick fixes. If any major or minor problem is identified in the code
or product, the team addresses them right away. There are no procrastinating things to
tomorrow. The Agile team tries to write clean code, build the right products in the right
order. All Agile team members are committed to the highest quality code so that technical
debt is minimized. They believe that high quality code enhances agility and saves time in
the future by avoiding additional efforts in fixing any sub-standard work.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
Agile team do not believe in big-bang approach; they keep things simple. The team
members practice simplicity by focusing on existing requirements, and concentrating on
delivery value that is fit-for-purpose and meets customer needs. They don’t think too much
into the future because they know that changes are inevitable to happen. They focus on
delivering highest-quality work in the most effective way possible.
11. The best architectures, requirements, and designs emerge from self-organizing
teams.
An Agile team is a self-organizing team with the right delivery environment and
organization culture. The team members are mature individuals and they know best how
to share responsibilities and create a healthy working environment for high-quality work.
They work on all aspects of the projects together and chart the best way forward to achieve
the desired goal (i.e. working software product).

15
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.
An Agile team devotes sufficient time for retrospection. At regular intervals, they assess that
elements of their approach have worked, what elements of the environment has changed,
and what they must improve upon to remain agile. In other words, this approach is called
continuous improvement.
HISTORY OF AGILE
Year Development of Framework
Taiichi Ohno, Shigeo Shingo and Eiji Toyoda create the ‘Toyota Way’. Many
1948
Agile concepts relate to Lean thinking
Publication of ‘Software Reliability’ by Glenford Myers, which states as an

1976 “axiom” that “a developer should never test their own code” (Dark Ages
of Developer Testing).
Creation of the “make” tool for Unix systems – the principle of automating
1977
software builds is not a new idea.
Substantial discussion of incremental development in IBM’s Federal Systems

Division can be found in a volume edited by Harlan Mills, “Principles of
software engineering”, specifically an article by Dyer, which recommends
1980
organizing “each increment to maximize the separation of its function(s)
from function(s) in other increments”; however, the idea is still very much
that of a scheduled, phased approach rather than one responsive to change.
The notion of “visual control” originating in the Toyota Production System

1980
is an anticipation of “information radiators”.
An early empirical study by Barry Boehm of projects using prototyping, by

essence an iterative strategy, suggests that iterative approaches first started
1984
receiving serious attention around that time, most probably driven by factors
such as the rise of personal computers and graphical user interfaces.
The notion of “factoring”, an anticipation of refactoring, is described in

1984 Brodie’s “Thinking Forth”, where it is presented as “organizing code into
useful fragments” which “occurs during detailed design and implementation”.
While criticisms of the “waterfall” sequential approach have started much

earlier, formulations of alternative incremental approaches are becoming
more pointed; a good example is an early paper on “Knowledge-based
1984
communication processes in software engineering” advocating incremental
development for the specific reason that “complete and stable specifications
are not available”.

16
Perhaps the first explicitly named, incremental alternative to the “waterfall”

1985
approach is Tom Gilb’s Evolutionary Delivery Model, nicknamed “Evo”.
In a well-known paper, Barry Boehm presents “A Spiral model of software

development and enhancement”, an iterative model geared to identifying
1986
and reducing risks through any appropriate approaches (though the “typical”
example presented is based on prototyping).
The term “Scrum” appears in an article by Takeuchi and Nonaka “The New
Product Development Game”, often cited as an inspiration for Scrum, the
1986
framework; however, it only appears once (in the title of a section: “Moving
the scrum downfield”) and does not at this point refer to any sort of meeting.
The “time-box” is described as a cornerstone of Scott Schultz’s “Rapid

1988 Iterative Production Prototyping” approach in use at a Du Pont spin-off,
Information Engineering Associates.
Ward Cunningham describes the CRC technique in a joint article with Kent
1989 Beck; the specific format used for the cards derives from an application
designed by Cunningham to store design documentation as a Hypercard stack.
Bill Opdyke coins the term “refactoring” in an ACM SIGPLAN paper with
1990 Ralph Johnson, “Refactoring: An aid in designing application frameworks
and evolving object-oriented systems”
Rebecca Wirfs-Brock describes the conceptual aspects of CRC, which she

1990 invented while she and Cunningham were working at Tektronix, in her book
“Designing object-oriented software”.
Testing discipline dominated by “black box” techniques, in the form of

1990
“capture and replay” testing tools
Owing to the rise in popularity of RAD tools and IDEs, “make” type tools
1990’s
acquire a mixed reputation
RAD, possibly the first approach in which time-boxing and “iterations” in the
looser sense of “one repetition of the entire software development process”
1991 are closely combined, is described by James Martin in his “Rapid Application
Development”. This book also describes the details of the timebox in one
of its chapters.
A comprehensive description of “refactoring” is presented in Opdyke’s

1992
thesis, “Refactoring object-oriented frameworks”
1993 Jeff Sutherland invents Scrum as a process at Easel Corporation.

17
The earliest writings on Scrum introduce the notion of the “sprint” as

1995
iteration, although its duration is variable.
1996 Steve McConnell describes the “Daily Build and Smoke Test” technique
1998–2002 “Test First” is elaborated into “Test Driven”, in particular on the C2.com Wiki.
Continuous integration and the “daily stand-up” are listed among the core
1998
practices of Extreme Programming.
The practice of “refactoring”, incorporated a few years earlier into Extreme

1999
Programming, is popularized by Martin Fowler’s book of the same name.
The term “Big Visible Chart” is coined by Kent Beck in “Extreme Programming
1999
Explained”
The “three questions” of Scrum’s daily meeting format are largely adopted
2000
by Extreme Programming teams.
2000 The burndown chart is first described by Ken Schwaber
2000 The term “velocity” is a relatively late addition to Extreme Programming
Following concepts introduced:
• Structural parallels between Agile and the ideas known as Lean

or the “Toyota Production System”
• Two distinct flavors of estimation in use among Agile teams,
relative and absolute estimation.
2001
• Some techniques of exploratory technique
• Quick design session
• role-feature-reason
• Project Retrospectives
• reflection workshop
• information radiator
2002 The Scrum community picks up the practice of measuring “velocity”
Early Scrum training materials hint at the future importance of the “Definition
2003
of Done”, initially only in the form of a slide title: “The story of Done”
2003 Publication of “Test Driven Development: By Example” by Kent Beck
2003 The term “domain driven design” is coined by Eric Evans

18
The daily meeting is generalized as a core Agile practice, and with widespread
2004–2006 use of task boards gains one final key guideline, “hold the daily meeting
near the task board”
2005 The Planning Poker technique is popularized in the Scrum community
A comprehensive description of integrating mock objects, TDD and OO

2010 design is provided in Freeman and Pryce’s “Growing Object-Oriented
Software Guided by Tests”
The practice of “backlog grooming” is promoted to an “official” element of

2011
Scrum with its inclusion in the Scrum Guide
Source: www.agilealliance.org

19
AGILE CONCEPTS Agile Thinking
2 AGILE THINKING
Before we get into the details of Agile, it is extremely important to get into the mindset
of an Agile practitioner and understand the thinking behind Agile. Every endeavor in life
involves the mechanics of doing it, and the mood (or thought process) associated with it.
Similarly, in Agile journey it is paramount to understand what Agile thinking is, and what
should be the mindset of an Agile specialist.
The first and foremost thing about Agile Thinking is that Agile is not only about doing
something. It is not a packaged solution that we buy to solve something. Indeed, it is
about ‘being’ Agile in all aspects of software development & delivery. It’s not only about
understanding ‘how’ we are doing Agile; it is more about ‘why’ we are doing Agile. The ‘how’
aspect of Agile is accomplished by the numerous tools & processes, practices, principles,
and values that Agile framework provides.
The following are some of the aspects of Agile thinking:
• Agile practitioners consider that the knowledge world is dynamic and variable. Things
are hardly ever constant. Change is going to happen no matter what. Hence an
Agile practitioner expects unexpected changes to happen and is prepared to handle
them. He is comfortable working in an environment of uncertainty and volatility.
• It is rare that IT environments will be simple and predictable. Since IT is closely
associated with business by being its close enabler, any change in business environment
is going to impact IT as well. IT environments typically tend to be complex; there
is uncertainty in terms of technology variation and requirements.
• IT is not like a civil engineering field where there is a fixed defined outcome and
a defined process. For instance, building a bridge does not see much variation.
Once the construction is started as per the requirements and design, there is very
little variability in design or construction techniques. Before the construction is
started, the requirements, analysis, design, construction, and delivery is planned
and finalized. This is an example of Waterfall model that we will discuss later. On
contrary, IT projects hardly follows this rigid path.

20
• The best mindset to have during Agile is to apply an empirical approach. Learn and
apply learning as you go along. You build small increments, get is reviewed and
tested by the product owners, get feedback, apply feedback, and release the product
to the end user. Once this first cycle is complete, start with the next iteration and
build on what you have already delivered. It is important to experiment, observe
and understand the results, and then adapt processes to achieve the best results.
Therefore, empirical mindset is an important agile thinking concept.
• The empirical approach, which is learning through experience, consists of three
main pillars – Transparency, Inspection, and Adaption. Transparency means that
the process of developing the product must be easily visible to everyone involved
in the project. Inspection requires that the product being created is inspected at
regular intervals so that any unexpected variance can be detected and corrected.
Adaption requires that the process is adjusted to minimize the unexpected and
unacceptable variances.
• Agile thinking derives a lot of its concepts from Toyota Production System (TPS).
Per Wikipedia, Toyota Motor Corporation has published an ‘official’ description of
TPS for the first time in 1992; this booklet was revised in 1998. In the foreword, it
is said: “The TPS is a framework for conserving resources by eliminating waste. People
who participate in the system learn to identify expenditures of material, effort and time
that do not generate value for customers and furthermore we have, avoid a ‘how-to’
approach. The booklet is not a manual. Rather it is an overview of the concepts, that
underlie our production system. It is a reminder that lasting gains in productivity and
quality are possible whenever and wherever management and employees are united in
a commitment to positive change”. TPS is grounded on two main conceptual pillars:
○○ Just-in-time: “Making only what is needed, only when it is needed, and only
in the amount that is needed”
○○ Jidoka: – (Auto-nomation) meaning “Automation with a human touch”
• Agile too adheres to TPS concepts of just-in-time by releasing software products in
small increments based on defined needs/requirements; Agile places more emphasis
on human-to-human communication and less on documentation.
• Agile thinking follows a product development lifecycle. The lifecycle of a product
spans from commissioning and decommissioning. The journey between these
two ends is accomplished through small delivery phases based on specific set
of requirements (or backlog of stories as called in product development world).
Typically, the features or functionalities are created as story cards that are added as
product backlog. The backlog exists throughout the product development lifecycle.
The stories are prioritized by the product owners based on how coarse-grained or
fine-grained the stories are, and taking into consideration the aspects of time, cost,
and quality.

21
• Agile follows the ‘time-boxing’ concept. According to Peter Measey and Radtac’s
book – Agile Foundations, “Time-boxing divides the delivery of increments of the
product into short, manageable time periods (called sprints or iterations) of days
or weeks, and varies, based on priority, the functionality to be delivered within
these time-boxes.”
• Finally, a key aspect of Agile thinking is it gives more importance to Time, Cost,
and Quality of software product delivery rather than the features/functionalities.
Agile considers Time, Cost and Quality to be fixed elements whereas features/
functionalities as dynamic elements. This variable aspect of features is demonstrated
by the Agile process where the features are released in increments. On the other
hand, the traditional Waterfall model believes in features being fixed element, and
time, cost and quality to be variable elements. This restructuring of time, cost,
quality and features works better in Agile projects because business expect software
delivery to be on time, within the cost boundaries, and of right quality. They are
not too concerned whether all features are implemented or not if there is a backlog
of their requirements, and they have the transparency that the development team
will release them in subsequent iterations.
In summary, Agile is a journey, not a destination. The best results can be derived out of
Agile practice when the team and the organization get into the right Agile mindset.
WATERFALL APPROACH
Before we get further into the Agile approach, it is important to understand what led to
Agile. In the early days of the IT industry, software development followed a sequential
development process. In 1970, Dr. Winston W. Royce wrote an article titled Managing the
development of large software systems that described the first formal description of the waterfall
model. Note that Royce did not use the term Waterfall in his article. Rather he presented
his model as an example of a flawed, non-working model.
In 1985, the United States Department of Defense captured this approach in DOD-STD-
2167A, their standards for working with software development contractors, which stated that
“the contractor shall implement a software development cycle that includes the following
six phases: Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and
Testing”. (source: Wikipedia – Waterfall model).
As stated above, the Waterfall model contains the following sequential phases:
1. Requirements: capturing product/software requirements

2. Analysis: preparing models, schemas, and business rules

22
3. Design: preparing software architecture

4. Coding: development/programming and unit testing of software
5. Testing: conducting systematic testing of the overall solution to capture bugs
and defects
6. Operations: includes installation, migration, support and maintenance of completed
software
Waterfall Model
Requirements
Specifications
Test Plan
Design
Coding
Testing RELEASE
Figure 1: Waterfall Model
These phases above are considered sequential because it is expected that one should complete
a phase before moving on to the next.
The Waterfall model originated in the manufacturing and construction industries that are highly-
structured physical environments. Due to lack of formal software development methodologies
at the time, the hardware-oriented Waterfall model was adapted for software development.
The key arguments supporting Waterfall approach are:
• If more effort is spent early in the initial phases analyzing and designing to
understand the requirements better, better would be the quality of the solution/
product being implemented.
• Higher quality means fewer errors at later stages thereby reducing costs.
• From a scheduling standpoint, Waterfall adopters usually spend 30–40% of the
time in the first two phases (Requirements and Analysis), 30–40% of the time to
coding, and rest to testing and operations.
• The key mode of communication is via documentation. The idea is if any team
member leaves the project, no knowledge is lost and the next team member can
get up to speed through the documentation.

23
• Waterfall is suited to environments where requirements and scope are fixed,

technology variance is less, and the expected change is minimal.
• Waterfall supports predictability through detailed delivery phases that are usually
signed off as milestones.
The Waterfall model has its own set of drawbacks too, as noted below:
• It is assumed that customers know exactly what their requirements are. Unfortunately,
this is hardly the case. Requirements get changed; this leads to redesign, redevelopment,
retesting. All these leads to increased costs.
• If requirements change but the delivery schedule is not adjusted, the quality is
impacted because all work and re-work needs to be completed within the timeframe.
For example, testing time may get shortened, design and architectures may be short-
changed, corners may be cut – all to meet the final delivery date.
• Architects are hardly aware what the future difficulties while implementing the final
software would be or how the technology landscape would turn out. In such a
case, it would be counterproductive to persist with a design that may not account
for newly discovered constraints, requirements, or challenges.
• Waterfall does not work very well in dynamic IT environment where variability is
high and cost of change is not prohibitive.
Time management
Find out how to manage your time better
Click here

24
• Waterfall fails to consider the inherent uncertainty and variability in knowledge-

based industry such as software industry.
• In summary, Waterfall model curtains agility by resisting change.
Therefore, advocates of Agile software development argue that the waterfall model is ineffective
when it comes to software development due to high variability involved.
WATERFALL VS. AGILE

The key differences between Agile and Waterfall are:
Agile Waterfall
Approach? Change-driven Plan-driven
Are requirements Short-term requirements Yes. Complete requirements are the

clear? are defined phase in Waterfall.
Not always. Business defines the

Yes. Agile works on requirements and hands over to
Is the business close collaboration the development team who are
purpose clear? between business and further down in the lifecycle. Hence
development team requirements may not be exactly
clear to them
Is the plan clear? Not necessarily Yes, it’s all planned
Planning is done in different

Planning span? cycles and tailored to the Planning is done for the full life-cycle
task at hand
Very close. Face-to-

Little face-to-face communication.
Collaboration level? face communication is
Reliance more on meetings
valued more
High ownership and

Team responsibility? Individuals own their respective pieces
responsibility is shared
Not much encouraged, but accepted

Yes, and Agile
Is change expected? through change requests filed by the
accommodates it
business or product owner
Overall approach Iterate and increment Big-bang approach; do all at once

25
AGILE CONCEPTS Benefits of Agile
3 BENEFITS OF AGILE
The key benefits of Agile approach are:
• Rapid delivery of software product: Agile helps in delivering early value to a project
by regularly, and frequently, releasing software code in small units of features that
satisfies the product owner needs.
• Iterative approach: Releasing software code in small units of functionality gives
the benefit of an iterative approach.
• Fail fast: Releasing software code in small units of functionality helps in receiving
quick feedback from the customer. So, if things do not work, they can be fixed
far. This means failing fast and correcting the course.
• High responsiveness to change: Since detail planning of the project is done in
small phases or increments, the project is not impacted much due to change to
business requirements.
• Better management of risk: Risk is managed better by focusing on implementation
of small units of functionality and by keeping the attention on the immediate and
next release.
• Higher business value: Since functionalities are defined by the business and software
is released in small chunks of functionality, the customer or product owner can
release quick and high value faster.
• Higher quality: Because of small iteration, the development effort and time is
planned better. Development work does not get accumulated at the end; there is
no borrowing of time from other areas such as testing. This prevents in any short-
cuts leading to higher quality of the final product.
• Transparency: The whole Agile process is completely transparent. The product owner
sees the functionalities being implemented gradually in phases; the developers can
get quick feedback from the product owner and takes satisfaction from the fact
that the accepted functionality is valuable to the business.

26
AGILE CONCEPTS Benefits of Agile
• Collective ownership: Agile emphasizes collection ownership of work. The team

determines the pace of the project and adjusts the pace that is sustainable for the
full course. Therefore, Agile team is highly effective since the team members can
take ownership, demonstrate great team work spirit by collaborating with others,
and work in consensus mode.
• Better stress management: Since Agile is built around sustainable pace and collective
ownership spirit, the team can manage its time and stress better in the long run.
Because development effort is tied to small units of functionalities, the project
schedule and cost is planned in a realistic manner. This avoid any last minute or last
mile over-effort. Team knows what is going to be released in the current release and
next release. Therefore, they can manage their personal time better. This prevents
any burnout and needless stress.

27
AGILE CONCEPTS Generic Agile Process
5 GENERIC AGILE PROCESS
Figure 2: Generic Agile Process
1. The Product Owner (usually the Customer) provides a list of desired features of
the product that are compiled into a Product Backlog. Based on the input from
the team, the items in the Product Backlog are prioritized and reprioritized at the
start of every sprint. These features form the high-level requirements of the project.
Most items are expressed in the form of a “user story.”
2. The team, collaboratively, selects user stories from the product backlog they can
commit to delivering. A high-level design is developed, and a sprint backlog is
created. The tasks are identified, estimated and self-assigned.
3. The team performs planning at different levels (release and/or iteration/sprint).
4. The delivery team gets equipped with Agile technical practices to be able to deliver
the project successfully.
5. Stand-ups are performed daily (usually at the start of the day) for about 15 mins.
6. Visual boards are used to monitor the status of the iteration/sprint.
7. RAID log is created where risks, issues, assumptions and dependencies are added
to and monitored.

28
AGILE CONCEPTS Generic Agile Process
8. ‘Show and tell’ meetings are held at the end of a sprint, iteration or release for
the team to demonstrate to the stakeholders all user stories completed during
the iteration/sprint; feedback is sought from the stakeholders about the product
being delivered.
9. Sprint retrospective is conducted to discuss what went wrong, what didn’t go well
and what needs to be done differently next time.
10. The Agile Lead facilitates and enables the Agile process and coaches the team.

29
AGILE CONCEPTS Common Agile Roles
6 COMMON AGILE ROLES

Agile is incomplete without the contribution of the people involved in it. People are the
fuel that keeps the engine of Agile running. Agile comes with its own sets of key roles
that are critical to Agile delivery. At a high level, the key roles in an Agile delivery are:
The Customer, the Agile Lead, the Agile Team, and the Stakeholders. While some of
these roles expect specific skill sets, the Agile approach hopes that team members can play
other roles beyond their skillsets. In other words, the team members may be ‘specialized
generalists.’ Beside these four roles, there may be other contributors to the Agile delivery.
Let us discuss each of these Agile roles in detail.
• The Customer: In Agile delivery, customer refers to the person who owns the product
being built, who makes decisions about what product will be built, and what work
will be done in what order to build the product. The customer understands the
vision and business rationale behind why the product is being built.
The customer also defines what stories are to be delivered, decides the order of the stories
on the backlog, and signs off stores when they are done at the end of each iteration/sprint
or release.
A commonly used mnemonic for remembering the key criteria of a good customer is
DARKA, which stands for:
(D)esire: The customer should have a keen desire to see the product being built as per
the vision. He should be excited about the product.
(A)uthority: The customer should have the authority to make decisions about the product
and its delivery, and enforce them. The Agile team must have a clear understanding what
level of authority the customer has, and who to approach if decisions beyond the authority
of the customer is needed.
(R)esponsibility: The customer is responsible for defining what the team will deliver and
in which order.
(K)knowledge: The customer must be knowledgeable about the product being delivered;
he should know where to find the information in a timely manner.

30
(A)availability: The customer must be available at critical juncture of the project to take
key decisions.
• The Agile Team: The Agile team is typically responsible for:

○○ Deciding how to do the work. This involves refining stories with the customer
and then dividing the into tasks.
○○ Defining the time frame of the work. This involves estimating the effort
needed to complete each task.
○○ Deciding who does the work, examining the progress of the work, and deciding
how to best organize themselves to deliver the product.
○○ Delivering the product.
Specialized generalists: A specialized generalist, in an Agile team, is someone who has

a specialist skill (like programming) and is also aware of what other team members are
doing in the project. Having specialized skills in the team fosters better communication,
collaboration and teamwork. Typical specialist skills found in an Agile team are:
○○ Business knowledge
○○ Architectural skills
○○ Analytical skills
○○ Design skills
○○ Coding skills
○○ Testing skills
Self-organizing teams: Agile teams are self-organizing teams, because they have the authority
to decide how work gets done, who does it and how long it should take. Self-organizing
teams can take initiative, focus on team contributions, concentrate on solutions, cooperate
with each other, innovate for better ways of working, finding ways to deliver better solution,
manage constraints, and take measures to manage any contingencies and emergencies.
Self-organizing teams lead to faster decision making, higher motivation, increased brain
power, and increased levels of initiative and continuous improvement.
Feature teams: An Agile feature team are usually structured as feature teams as it enables
delivery of features from the backlog. The Agile feature team concentrates on delivering
value-add features to the customer.
Component teams: Component teams come into play when it is not possible for feature
teams to delivery features to the customer as the delivery cycle may require one or more
components to be delivered first. Components teams are responsible for producing components
that can be combined with other components from other teams and integrated together
into a feature.

31
Core and support teams: An Agile team may be broken up into core and support teams.
This can be typically seen in large and complex projects. The core team is focused on
delivering across the value chain; support teams provide support to core teams to do
things right first time. Example of areas where support team enable the core team are
architectural support, user interface support, or research support.
• The Agile Lead: The Agile lead is mainly responsible for enabling the team to self-
organize and continually improve. The Agile lead understands the overall delivery
cycle, understand the team, their skills, and their mode of working. The Agile lead
does not command and control the team; he or she rather facilitates and enable the
team to self-organize. An Agile lead removes impediments that block a task from
being executed or a feature being delivered.
Workshop facilitator: The Agile Lead sometimes puts on the hat of an Agile facilitator
to facilitate the delivery of Agile framework and activities through workshops. This needs
coordination, planning, and structuring of the workshops. Since a facilitator needs to be
independent from the people attending the workshops, it is advisable that the facilitator
be from a different team.
Process facilitator: The Agile Lead also helps in the organization, program, project and
team to define the Agile process and operating model. The Agile Lead ensures that Agile
processes are being followed, the Agile activities are respected, and the sizing of the stores
are correct. The Agile Lead also works closely with the team to identify any scope for
Agile process improvement.
Coach or trainer: The Agile Lead also plays the role of coach or trainer to propagate
the knowledge of Agile principles, processes and practices to the team. If there is a new
practice or process that needs to be implemented, the Agile Lead acts as enables to helping
the team implement them.
• The Stakeholders: Stakeholders are people who have interests in the project, may
be involved actively in the project, may exert influence over the project, and their
interests may positively or negatively impact the performance or completion of
the project. Therefore, identifying and effectively managing stakeholders is key
to successful Agile delivery. The key role of the stakeholder is to ensure that the
interests of the group they are part of are represented. For example, if the customer
is the stakeholder, he/she would be interested to ensure that the project team is
delivering the product per the requirements set by the customer.

32
AGILE CONCEPTS Common Agile Techniques
7 COMMON AGILE TECHNIQUES

STORIES AND BACKLOG REFINEMENT
A user story is a very high-level definition of a requirement, containing just enough information
so that the developers can produce a reasonable estimate of the effort to implement it.
It captures description of a software feature from an end-user perspective. The user story
describes the type of user, their wants, and why they want it.
The key features of a story card are:
Summary
As a <WHO>: Who wants the feature
I Want <WHAT>: What feature they want
So That <WHY>: Why they want the feature
Scenario
GIVEN <STARTING CONDITION>
WHEN <ACTION OCCURS>
THEN <EXPECTED RESULT>
Good Quality Stories
INDEPENDENT
NEGOTIABLE
VARIABLE (TO THE USER)
ESTIMABLE
SMALL
TESTABLE

33
The above is also called 3Cs – Card, Conversation, Confirmation
An example of a user story card is:
FRONT OF CARD
As a – Customer
I want – the ability to update my personal details (password, email, address, etc.) on
the website
So that – my information is up to date and I receive timely communication.
For internal use only

34
BACK OF CARD
Acceptance Criteria:
• Can I update my account at any time – 24x7?

• Can I access and update my account through any mode – website, mobile, etc.?
• Would I receive a confirmation of change through email or text message?
• Would my updates come into effect immediately?
Well-formed stories will meet the criteria of Bill Wake’s INVEST acronym:
Stories should be deliverable independently of each other, and

Independent:
in any sequence
Stories should be flexible and negotiable so that it can be

Negotiable:
adjusted over time
Valuable: The value of the story must be understood by the customer
Stories must be understood by the team so that create estimates

Estimable:
for planning
‘Small is beautiful’ should be the motto. Large stories are hard

Small: to estimate and plan. It is a good practice to refine stories to 1
to 5 days’ effort size
Stories must include testable acceptance criteria to achieve

Testable:
‘done’ status.
Agile Planning Pyramid: Now that we have an idea of what a story card should contain,
the question is how to define the story cards. Are there any best practices available? The
answer is Yes. Below are some of the best practices:
• Stories should be kept independent of each other

• Stories can be defined coarse-grained or fine-grained depending on the nature of
the projects. If delivering a large complex project, it is alright to break down stories
into sub-stories. To do this, a planning pyramid is used.

35
Agile: Stories breakdown as they move up the backlog
Ready for iteration planning
Inc easin
Inc
rea
r
sin prio
gd
g
Mid-range (4-10 iterations out)
eta ity
il
r
Long-range (10+ iterations out)
Figure 3: Agile Stories Breakdown
• As the delivery progresses, stories are broken down from coarse-grained into
fine-grained stories. Basically, more details are brought in as the priority of the
story increases.
• From a timeline perspective, stories are defined fine-grained closer to the immediate
iteration sprint. If the iterations are far out, it is better to leave the stories coarse-
grained. This is because it is highly likely that the product will change during the
development cycle. Hence it may be counter-productive to define too fine-grained
stories if they are not going to be taken up in the immediate upcoming release.
Agile Estimation: Once the story cards are defined, the next activity is to estimate them.
Estimation is the process of agreeing on a size measurement for the stories, as well as the
tasks required to implement those stories, in a product backlog. Estimation is usually a
forecast of how many stories can be delivered in a release iteration/sprint. Estimation is
mostly done as a team so that every team member is committed to the work being planned.
The default unit type used to estimate the stories is Points. A sample example of point value
set is: 2, 3, 5, 8, 13, 20, 40 or 100 points. This is a Fibonacci sequence.

36
Prior to iteration planning, point estimates are entered the Planned Velocity field of iteration.
This value indicates the total number of story points that team believes it can complete in
an iteration. Different teams will have different velocity. Another way to calculate velocity
is to average total number of accepted points from past iterations. Over a period, the team
will have a pretty good idea of its velocity.
If the story estimate calculated by the team is greater than the total velocity for an upcoming
iteration, it is likely that the team will not be able to meet the target. Therefore, it is
advisable to break down large stories into smaller child stories.
How to Estimate the Stories: A popular technique to estimate the story points is through a
‘Planning Poker’ workshop. Here the team decides on a relative effort (story points) required
to deliver stories to ‘done’ status. Planning poker typically uses a relative sizing based on
fine and coarse grained differences between numbers. The relative difference between stories
that are near to delivery will be fine-grained, whereas the relative difference between stories
that are further away from delivery will be coarse-grained.
Typical story-points in planning poker are:
• The story is at ‘done’ status = 0

• Fine-grained sizings = ½ (xxs), 1 (xs), 2 (s), 3 (sm), 5 (m), 8 (ml), 13 (l)
• Coarse-grained sizings = 20 (xl), 40 (xxl), 100 (xxxl)
A typical planning poker process goes like this:
1. Create or purchase a set of planning cards for each team member. Have a card for
each value in your point system: 2, 3, 5, 8, 13, 20, 40, 100 (or similar)
2. Bring up the proposed story on a monitor or board. Explain what value the story
will provide, and the initial requirements.
3. Give team members a minute or two to select a card, face down.
4. On the count of three, all team members raise their hand, displaying the card.
5. Find the lowest and highest card values.
6. Have the lowest and highest card holders each take two minutes to explain why
they think a story is a certain size.
7. Provide a few moments for others to weigh in, should the discussion uncover any
problems or requirements.
8. Re-vote until a consensus value is reached.
9. Record the estimate value.
Source: https://help.rallydev.com/sizing-and-estimates

37
AGILE PLANNING
Planning in Agile is done to enable change. In simple terms, agile planning is measuring
the speed a team can turn user stories into working, production-ready software and then
using this information to determine when they’ll be done.
The planning process usually starts with a master story list that contains a list of features
that customer wants to see in the end-product. The speed at which the user stories are
turned into working software is called the team velocity. Velocity sets expectations about
delivery dates in the future. Then using agile iteration, planning is done for one to two
week sprints of work.
Number of iterations is determined by the following formula:
# iterations = total effort (in points)/estimated team velocity
Example:
# iterations = 200 pts/10 pts per iteration = 20 iterations
Effort
Master story list
1 pt Add user
Te
2 pt Print itinerary Iteration 1 a m
Ve
5 pt Cancel trip locit
y
3 pt Book permit
User stories 1 pt Update permit Iteration 2
& Estimates
... ...
5 pt Create device
3 pt Add swap trade Iteration (n)
——
160pts Time
Figure 4: Agile Planning – 1
Once the velocity and number of iterations are determined, we can identify whether (a) we
are going faster than expected or (b) we are going slower than originally anticipated.

38
Effort
remaining
Slower than
expected
Faster than
expected
Time
Figure 5: Agile Planning – 2
Top-down planning:
Top-down planning is used to create estimated for longer time frames. Top-down plans are
quick and not accurate always (they are not intended to be); they are especially suited to
environments that are variable and somewhat risky to plan in detail.
Top-down planning can be performed with either ‘story points’ or ‘ideal days’. Previous
experience or past data are also used in the planning process.
Bottom-down planning:
Bottom-down planning is used when a more detailed estimate is required. In this process,
teams have a good idea which stories are likely to be delivered in the iteration/sprint. Based
on this, the team determines the capacity of delivery (represented in ‘total available hours
within an iteration/sprint’), plans the tasks required to get the storied to ‘done’ status, and
estimates the hours needed to deliver the planned tasks. This is normally expressed as ‘total
required hours’ in the iteration/sprint. The ‘total required hours’ are then compared against
the ‘total available hours’. If the figures differ, the team may remove, replace, add or split
some stories till the required hours match.
Iteration/sprint planning:
Iteration/spring planning is usually performed in two parts – ‘Planning part 1’ and ‘Planning
part 2’.

39
Iteration/sprint planning part 1: This is an example of top-down planning, and is

performed in the same way as release planning – i.e. the team plans the number of stories
to be delivered within an iteration/spring based on story-point size and velocity.
Iteration/sprint planning part 2: This is an example of bottom-up planning. If the forecast

number of stories that can be delivered from top-down and bottom-up estimates match, this
is likely to be an achievable estimate. If the figures do not match, the team ascertains the
reasons for the difference and does the required calibration to arrive at a robust estimate.
AGILE TESTING
Agile testing generally means the practices of testing software for defects or performance
issues within the context of an agile workflow. Conforming with Agile practices, the testing
cycle must be Agile too. Leaving the testing at the end of a release is harmful because
significant defects found at that point my derail the quality and delivery of the product. Just
like multiple iterations/sprint in Agile delivery cycle, the testing cycle must be frequent too.
The figure below shows a simple-to-understand Agile testing model; it provides guidance
on the types of testing typically used in Agile delivery, the objective of testing, and how it
should be delivered.
AGILE TESTING QUADRANTS
Automated Business Facing

Manual
& Manual
Examples Exploratory
Prototypes Scenarios
Guiding Development
Functional Useability
Critique Product
Simulations UAT
Story Alpha/Beta
Performance & Load

Component
Scalability (etc.)
Unit
Security
Automated Tools
Technology Facing
Figure 6: Agile Testing Quadrants
Many testing-based development practices are used in Agile deliveries. A brief description
of them is provided below:

40
TFD (TEST FIRST DEVELOPMENT)

As the name suggests, TFD practice means test cases are written before any development to
meet story acceptance criteria happens. Creating the tests first, before the code, makes it much
easier and faster to create the code. Creating a unit test helps a developer to consider what
needs to be done. Requirements are fine-tuned by tests. TFD eliminates any misunderstand
of a specification written in the form of executable code. TFD also benefits system design;
by creating test fist the design will be influenced by the desire to test everything of value
to the customer.
Once the tests have been written, a test-build-cycle is implemented until all bugs associated
with the build have been fixed and the customer is ready to sign off the story.
TFD validates that the delivery/product meets the story acceptance criteria agreed by the
customer.
TDD (TEST DRIVEN DEVELOPMENT)

Test-driven development (TDD) is a software development process that relies on the
repetition of a very short development cycle: requirements are turned into very specific test
cases, then the software is improved to pass the new tests, only.
TDD is normally implemented at the unit or component testing level. It includes the Agile
practice of ‘refactoring’. What this means is that tests and production code are written to steer
the design as we go. Basically, we refactor to simplify and clarify. The presumption behind
TDD is that it is difficult to tell what design will work best until the code is written. As
we learn about what works and what does not, we are in the best possible position to apply
those insights, while they are still fresh in our mind. And all this activity is protected by
the suites of automated unit tests. In TDD, the team focuses on conditions in the test that
could cause the code to fail. Once there are no more failure conditions, the development
is considered complete. The focus in TDD is on design and ensuring that products are
designed in a fit-for-purpose way.

41
A flowchart of Test Driven Development is shown below:
Change code
functionality
No
STORY Write test Run test Did test pass?
Yes
Yes Better design

Refactor code
possible?
No
End
Figure 7: Test Driven Development
ATDD (ACCEPTANCE TEST DRIVEN DEVELOPMENT)

Analogous to ATDD, Acceptance Test Driven Development (ATDD) is closer to user
acceptance testing (UAT). Acceptance Test Driven Development (ATDD) is a practice
in which the whole team collaboratively discusses acceptance criteria, with examples, and
then distills them into a set of concrete acceptance tests before development begins. The
collaborative discussions that occur to generate the acceptance test is often referred to as the
three amigos, representing the three perspectives of customer (what problem are we trying
to solve?), development (how might we solve this problem?), and testing (what about…).
These acceptance tests represent the user’s point of view and act as a form of requirements
to describe how the system will function, as well as serve as a way of verifying that the
system functions as intended.

42
BDD (BEHAVIOUR DRIVEN DEVELOPMENT)

Behaviour Driven Development (BDD) is a synthesis and refinement of practices stemming
from Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD).
BDD focuses on scenario testing to ensure that the system behaves in the way the user
expects it to behave. BDD augments TDD and ATDD with the following tactics:
• Apply the “Five Why’s” principle to each proposed user story, so that its purpose
is clearly related to business outcomes
• Thinking “from the outside in”, in other words implement only those behaviors
which contribute most directly to these business outcomes, to minimize waste
• Describe behaviors in a single notation which is directly accessible to domain
experts, testers and developers, to improve communication
• Apply these techniques all the way down to the lowest levels of abstraction of
the software, paying attention to the distribution of behavior, so that evolution
remains cheap
SPECIFICATION BY EXAMPLE
Specification by example ensures that what it being created matches the customer’s requirements
and that testing is focused on the parts of the system that create the greatest business value.
Gojko Adzic coined the term Specification by Example and it is the title of his book (Adzic,
2011). He chose this name over names, such as Behaviour Driven Development (BDD), as
the phrase put the focus on the nature of the requirements, “examples”, rather than other
things such as the development process or the user interface. He defines specification by
example as “…a set of process patterns that facilitate change in software products to ensure
that the right product is delivered efficiently. When I say the right product, I mean software
that delivers the required business effect or fulfills a business goal set by the customers or
business users and it is flexible enough to be able to receive future improvements with a
relatively flat cost of change.”

43
The key elements of specification by example are:
• Deriving system scope from clearly articulated business goals

• Specifying acceptance criteria for stories collaboratively between team, customer
and stakeholder
• Agreeing on requirements using examples
• Refining specification throughout the lifetime of the product
• Automating validation without changing specifications
• Validating frequently that the product being built meets the specifications
• Evolving a documentation system that consists of simple-to-understand requirements
and tests that prove them
Leadership skills
Click here

44
AGILE CONCEPTS Common Agile Practices
8 COMMON AGILE PRACTICES

SHORT FEEDBACK LOOPS
Feedback loops are critical to the success of an Agile delivery. A feedback loop is a process
where the results of running a process can influence how the process itself works in the
future. Some of the kinds of feedback loop that exist in Agile development processes are:
• Face-to-face conversations
• Daily stand-ups
• Show and tells
• Pair programming
• Unit testing
• Pair negotiation
• Release
FACE-TO-FACE COMMUNICATION
Face-to-face communication enables fast feedback loops, improves relationships, creates
mutual trust, and defines centers of influence within an organization. In collaborative work,
such as Agile, face-to-face interaction is a more favorable and productive choice. Therefore,
Agile teams are physically co-located because it enables face-to-face communication better.
DAILY STAND-UPS
Daily stand-ups, as the name suggests, are daily meetings where the whole team meets every
day for a quick status update. It allows the team to inspect the progress that has been made,
plan the day’s work, and resolve any bottlenecks in the work.
The daily stand-up meets are limited to a maximum of 15 minutes. The meeting is, in most
cases, is done first working hour in the morning. This helps to set the agenda for the rest
of the day. Usually these meetings follow a simple format, with each member answering
each of the following three questions:
• What did I do yesterday that helped the development team meet the sprint/
iteration goal?
• What will I do today to help the development team meet the sprint/iteration goal?
• Do I see any impediment that prevents me or the development team from meeting
the sprint/iteration goal?

45
The meeting is usually centered around the visual board on which the tasks and/or stories
are laid out. The team would start from the rightmost point on the board and talk about
the tasks that are nearest completion. Then they work their way across the board. This helps
in focusing on the tasks that are nearing completion.
Figure 8: Daily Standup
SHOW AND TELLS

‘Show and tells’ are meetings that are held at the end of a sprint/iteration/release. The
purpose of these meetings is for the team to invite stakeholders to these meetings and
demonstrate all stories completed during an iteration/sprint. The team seeks immediate
feedback from the stakeholders. It also provides the opportunity to the team to show the
most important work they’ve done, talk about what they’ve learned, explain their plans for
the next few weeks and answer questions. It also gives other teams the chance to see how
their work relates to others.
Show and tells could also be a live demonstration of a new working product or feature; the
stakeholders get a chance to see, touch and feel the real working product.
Show and tells meetings provide a good opportunity to highlight risks, issues, roadblocks
and assumptions to the stakeholders so that they can provide feedback or insights that may
assist with the resolution of these.

46
Show and tells should be an open and transparent discussion. It offers the attendees the
chance to understand and see for themselves the progress that has been made on the product.
The meetings also offer the team a chance to bring closure to their work for the duration
of the sprint. It gives the team an opportunity to celebrate their success on meeting their
goals and it is an opportunity for any senior management present to recognize and affirm
the efforts of the team.
Show and Tell meetings are NOT:
• A PowerPoint presentation
• Document review meeting
• Fault-finding and finger-point meeting
RETROSPECTIVES
An Agile retrospective is a meeting that’s held at the end of an iteration in Agile software
development (ASD). During the retrospective, the team reflects on what happened in the
iteration and identifies actions for improvement going forward. The purpose of retrospectives
is to continually improve the product as it is being delivered and how to continuously
improve how the products are delivered. During retrospectives, each team member will
answer the following questions:
• What worked well for us? (What should we continue doing?)

• What did not work well for us? (What should we stop doing?
• What actions can we take to improve our process going forward? (What should
we start doing?)
The key steps in retrospective process are:
• Setting the stage so that everyone can speak

• Gathering data
• Generating insights
• Deciding what to do
• Closing the retrospective

47
EMERGENT DOCUMENTATION
The Manifesto for Agile Software Development values “working software over comprehensive
documentation”. Documentation should be minimized and can only be produced when
it adds value, and should be fit for purpose. They key is to find right balance between
documentation and discussion. Three criteria could be applied to decide how much
documentation should be written:
• Essential: Document what is extremely essential

• Valuable: Document only if it provides value
• Timely: Document only when it is needed
Why is it called emergent documentation? This is because it follows the motto ‘we
document as we discover’. Too much documentation ahead is a waste of time. The team
should document only what they DID, as opposed to what they think they will do next.
Documentation should be part of the overall process, not a separate activity. It should be
a collaborative effort.
VISUAL BOARDS
Visual boards in Agile take on various forms. The key ones are explained below.
• Information Radiator
Information radiator, also known as Big Visible Chart (BVC), is a large graphical
representation of project information kept plainly in sight within an agile development
team’s shared workspace. It should be radiating information to everyone who sees it. It
is a great way to convey information about the current state of a delivery. Information
radiator could be handwritten, drawn, printed or electronic displays. It could be deployed
physical like mounting on a wall.
Information radiators are key source of information for daily stand-up meetings, show
and tells, and retrospectives. For daily stand-up meetings, team members can talk about
daily progress of stories and tasks represented on the board. For show and tell, information
radiators provide information on completed tasks and stories. And for retrospectives, the
board can show information on what needs attention. At a minimum, the information
radiator should show the current state of tasks/stories the team is working on and how
much progress they are making to get to ‘done’ status.

48
Common information radiators used in Agile environments are:
○○ The product vision

○○ The product backlog/release plan
○○ The iteration backlog
○○ Burn-down and burn-up charts
○○ The impediment list
• Burn-down and Burn-up charts

A burn-down chart is a chart that compares effort spent to date and the expected effort
remaining. It can be used to predict whether a team will succeed in delivering everything
within the iteration/sprint by extrapolating the ‘actual effort left’ line based on latest
forecasts. The burn-down chart is a good way to project what is happening vs. how much
progress is being made during each iteration/sprint.
Sample Burndown Chart
250 25
200 20
Remaining and completed tasks
Remaining effort (hours)
150 15
Completed tasks
Remaining effort
100 10 Ideal burndown
Remaining tasks
50 5
0 0
Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day Day
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
Figure 9: Sample Burndown Chart
A burn-up chart tracks the total work required vs. the actual work completed. When the
two lines intersect, the iteration/sprint is considered ‘done’.

49
Release Burnup Actual Burnup

Forecasted Burnup
350 Scope
300
Effort (pts.) 250

200
150
100
50
0
0 1 2 3 4 5 6 7 8 9
Sprint
Figure 10: Release Burnup
• RAID Log
A RAID log is a single repository of all key information about a delivery that is not
expressed on the backlog or in other documentation. RAID stands for
○○ Risks
○○ Assumptions
○○ Issues/Actions
○○ Dependencies
SUSTAINABLE PACE
Sustainable Pace is an essential part of both Extreme Programming and the Agile Manifesto.
It means that the team aims for a work pace that is sustainable in the long-run. This is
intended to improve productivity by eliminating burnout.
The foundation for sustainable pace had been established by XP guru Kent Beck in the
first edition of “Extreme Programming Explained” (1999), where he suggested working no
more than 40 hours a week, and never working overtime a second week in a row. One of
the principles behind the Agile Manifesto was dedicated to “Sustainable Pace”, which can
be regarded as the most widely accepted definition:
“Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.”
Sustainable Pace is not about taking it easy and going slow. It is about expending energy
wisely, and regaining strength by taking adequate rest.

50
FOCUS ON QUALITY
Agile practice focuses on two kinds of qualities – Functional and Technical.
• Functional Quality: Functional quality is about delivering the features and

functionality as per customer expectation. It means ensuring that project/product
works as it should and what users expect it to do.
• Technical Quality: Technical quality is about delivering the product or software
per the functional and non-functional requirements provided by the customer. The
product should be fit-for-purpose.
REFACTORING
Refactoring means changing the design of a system (internal structure) without changing
its external behavior. Refactoring does NOT mean rewriting code, fixing bugs or improving
observable aspects of software such as its interface. Refactoring is mainly focused on improving
the quality of the design of the system; it should be a continuous normal software development
practice to avoid the software incur too much technical debt. Refactoring improves objective
attributes of code that correlate with ease of maintenance; it makes code understandable and
maintainable, it encourages each developer to think about and understand design decisions,
in the context of collective ownership/collective code ownership, and it favors the emergence
of reusable design elements (such as design patterns) and code modules.
One way to implement refactoring is Test Driven Development (TDD).
CONTINUOUS INTEGRATION
Continuous Integration (CI) involves producing a clean build of the system several times
per day. Agile teams typically configure CI to include automated compilation, unit test
execution, and source control integration. Sometimes CI also includes automatically running
automated acceptance tests. Continuous integration allows agile software development teams
to check in code frequently to detect problems early.
Continuous integration enables team members to frequently and independently integrate

their work with the core product and therefore ensure that the overall product continues
to work in an integrated manner. The integration is usually done multiple times a day, or
at least one daily. Performing the integration and testing at the end of a release or project
may lead to unexpected scenarios; it may be too late to fix if a significant defect of problem
is discovered. This in turn leads to high technical debt.

51
While performing continuous integration, it is important that the team use the latest working
version of a product, which is usually maintained in a central source control system. The
team must checkout the latest version, make changes, and check-in their updated code. The
continuous integration system detects the new checked in code, rebuilds the changed software
environment, and runs unit and integration tests to see if everything works correctly. If the
test failed, the build fails and the developer who checked-in the code will be notified. The
developer then fixes the code to resolve the problem.
Therefore, the key activities associated with continuous integration are:
• Maintaining a central source code repository

• Automating the build and making the build self-testing
• Checking in the developed code daily
• Rebuilding the baseline code daily
• Mirroring the test environment as close to production (live) environment as possible
• Automating deployment wherever possible
AUTOMATED BUILDS
As mentioned in the section on Continuous Integration, automated build and testing is critical
to performing a successful continuous integration. Building the deployment and integration
testing manually is time-consuming and defeats the purpose of continuous integration.
Automated build is, therefore, a process of creating scripts that automatically perform key
developer tasks such as compiling code, running tests, performing code analysis, deploying
to environments, and creating system documentation.
It is important that Agile delivery teams can run automated build continuously. The
automated builds should be run on a regular basis, at least once daily.
CODE REVIEW AND PEER REVIEW

While automation has its obvious benefits, it cannot detect everything. Automated build
can manage to build and run the integration test successfully. But lot of things may happen
out of plain sight. One example is the quality of the code being written. For sustenance, it
is important that the code is well written, understandable, and maintainable. In Agile, the
code review process is done in two ways: peer review and peer programming.

52
In peer review, the developer submits the completed code to a peer for review before
committing the code. The reviewer could be of similar level of experience to the person
who wrote the code.
In pair programming, two programmers work together at one workstation. One types in
code while the other reviews each line of code as it is typed in. The person typing is called
the driver. The person reviewing the code is called the observer (or navigator). The two
programmers switch roles frequently.
In both these approaches, it is important that the review does not slow down the agile process.
Common sense should prevail in determining the amount and rigor of code review. The
review process should be in line with the complexity and rigor of the product being built.

53
AGILE CONCEPTS Major Agile Frameworks
9 MAJOR AGILE FRAMEWORKS

Before we get into the other Agile frameworks, it would be helpful to set into the context
the challenges of traditional (and non-Agile) software development methodologies. Traditional
software development methodologies such as Waterfall use rigid procedures and require
thorough planning up-front. The starting point for applying such methodologies is clear
and defined requirements. The figure below shows a traditional waterfall model.
Communication skills
Discover how to be a better communicator
Click here

54
Waterfall Model
Requirements
Specifications
Test Plan
Design
Coding
Testing RELEASE
Figure 11: Waterfall Model
While these traditional methodologies have obvious benefits (such as better planning of
team structure and distribution, predictable budgets, etc.), they have their own challenges
too. These methodologies lack flexibility, a clear disconnect from the customer expectation
(if the projects are too big), difficulty in addressing scope or requirements changes, and
inability to detect design flaws until the integration and testing phase.
The waterfall method was developed using engineering approach. It is understandable to plan
everything ahead when building bridges or buildings. Unfortunately, software development
does not work that way because conditions are different. Therefore, as a correction to the
shortcomings of traditional methodologies, Agile methodology was introduced. Agile replace
the rigid and predictive nature of traditional methodology with adaptive and agile methods.
Standard Waterfall model Extreme Programming
Spiral Waterfall model
Predictive Adaptive
Rigid Iterative Agile
methodologies methodologies methodologies
Figure 12: Predictive vs. Adaptive
These are specific criteria identified by the customer for each functional requirement. The
acceptance criteria are written in simple terms and from a perspective of the customer.

55
The key principles of Agile methodologies are:
• Early and frequent testing

• Incremental design
• Frequent (daily) deployment
• Higher customer satisfaction
• Continuous integration
• Short development cycles
• Cohesive team
• Better transparency among customer and development team
• Incremental planning
• Single code base
• Self-adaptive process
• Adaptive to change
Agile methodologies do not refer to one specific approach but are a group of individual
methodology that implement agile principles. Several agile methods that have been
developed are:
• Scrum
• Dynamic Systems Development Method (DSDM)
• Crystal Methods
• Feature Driven Development
• Lean Development
• Extreme Programming (XP)
• Adaptive Software Development
• Agile Project Management
• Kanban
• Scaled Agile Framework (SAFe)
Extreme Programming (XP) is one of the most well-known Agile methodologies.

56
EXTREME PROGRAMMING (XP)

Extreme programming (XP) is a software development methodology which is intended to
improve software quality and responsiveness to changing customer requirements. It stresses
customer satisfaction over anything else. It delivers the software as the customer needs it
by empowering the developers to respond to changing customer requirements. XP therefore
advocates frequent releases in short development cycles.
Key elements of XP are: pair programming, extensive code review, unit testing of all code,
avoiding programming of features until they are needed, a flat management structure, code
simplicity and clarity, expecting changes in the customer’s requirements as time passes and
the problem is better understood, and frequent communication with the customer and
among programmers.
XP improves software project in five essential ways – communication, simplicity, feedback,

respect, and courage. XP programmers constantly communicate with their customers and
team members. They keep the design simple and clean. They rely on frequent feedback from
customers and by testing their software from early in the lifecycle. The deliver the software
to the customers as early as possible and incorporate feedback frequently. This deepens
the respect they receive from customers; it also increases the respect for the contributions
each team member makes. XP allows programmers to courageously respond to changing
requirements and technology.
The differentiating aspect of XP is its simple rules. These rules, when combined, provide a
powerful tool to achieve extreme programming. A summary of the XP rules is listed below:

57
• User stories are written.

• Release planning creates the release schedule.
Planning • Make frequent small releases.
• The project is divided into iterations.
• Iteration planning starts each iteration.
• Give the team a dedicated open work space.

• Set a sustainable pace.
• A stand-up meeting starts each day.
Managing
• The Project Velocity is measured.
• Move people around.
• Fix XP when it breaks.
• Simplicity.
• Choose a system metaphor.
• Use CRC cards for design sessions.
Designing
• Create spike solutions to reduce risk.
• No functionality is added early.
• Refactor whenever and wherever possible.
• The customer is always available.

• Code must be written to agreed standards.
• Code the unit test first.
• All production code is pair programmed.
Coding
• Only one pair integrates code at a time.
• Integrate often.
• Set up a dedicated integration computer.
• Use collective ownership.
• All code must have unit tests.

• All code must pass all unit tests before it can be released.
Testing
• When a bug is found, tests are created.
• Acceptance tests are run often and the score is published.
The following flowchart shows how XP rules work together.

58
Extreme Programming Project
Figure 13: Extreme Programming Project
Extreme programming (XP) originated in 1990s; it was conceptualized by Kent Black who
tried to find a better way to do software development. He realized that software development,
unlike waterfall model, is a fluid process; requirements will change during the project.
Therefore, the software development method must be able to adapt to changing requirements.
The four basic activities that XP proposes for software development process are:
• Coding: In XP, coding starts very early in the project as it is considered the most
important product of the software development process.
• Testing: XP emphasized on the efficacy of testing to check whether the developed
code is working. Programmers use automated unit tests, and write tests as many as
possible to break the code being written. This improves the robustness of the code.
• Listening: Listening is considered an extremely important soft skill in XP. It is
expected of each developer to listen attentively so that they can understand customer
needs and develop products as close to the requirements as possible.
• Designing: XP emphasized on creating simple and fit-for-purpose design structure
that avoids too much dependency.
XP is associated with 28 rules and practices. Of these the key ones are:
• User Stories: User stories are viewed as smaller use cases. This makes it easier for
planning and cost estimation.
• Small releases: XP emphasizes on small, simple and frequent releases incorporating
one or more requirements in each release.
• Standards: Team adheres to standards on names, class names and methods are
followed.

59
• Collective ownership: All code is the property of the whole team and not of an
individual. Code is reviewed and updated by everyone.
• Simple design: The design and implementation are kept as simple as possible while
providing the required functionality.
• Refactoring: The product is continually adjusted and improved by all team members.
• Testing: Every small release must pass through successful tests. Tests are created
first and then coding is done to pass the pre-written tests.
• Pair programming: Programmers work in pairs; they work together at a single machine.
One person writes code and the other person reviews; the role is then reversed.
• Continuous integration: Software is built several times a day. This avoids last minute
software integration challenges.
• 40-hour workweek: Team work 40-hours per week to avoid burnout.
• On-site customer: The customer must be accessible to the team as frequent as
possible so that there is no gap in communication.
XP Process
Project
Stories Test Cases Tasks Completion
Requirements
Story Metrics
Iteration
Iteration
Customer Customer Acceptance
Planning
Input Testing Tests
Meeting
Iteration
Automated Unit Testing
Figure 14: XP Process
In conclusion, XP is best applied to projects that are exposed to changing technologies, where
small frequent releases are possible, where projects are small and can be easily managed.

60
SCRUM
Scrum is a popular Agile framework for completing complex projects. The term ‘scrum’ is
taken from the scrum formation used by Rugby teams that are high-performing and cross-
functional. Originally meant for software development projects, Scrum can be used for any
complex, innovative scope of work. What is unique to Scrum is its commitment to short
iterations of work. Scrum used fixed-length iterations called Sprints. Sprints are usually
no more than 30 days; the team try to build a potentially releasable product increment
every Sprint.
The Scrum process is relatively simple:
• Product Backlog:
○○ A product owner creates a prioritized wish list called a product backlog.
• Sprint Planning:
○○ During sprint planning, the team pulls a few pieces from the top of that wish
list, creates a sprint backlog, and decides how to implement those pieces.
○○ The team decides in how much time to complete the work. It is usually two
to four weeks – called a Sprint.
• Daily Stand-up:
○○ The team meets each day to assess its progress (daily Scrum). Also, called
daily stand-up, it is usually a quick 15-minute meeting.
○○ The Scrum Master tracks the overall progress and keeps the team focused on
its goal.
• Sprint Demo:
○○ A demo is given to the Product Owner and other stakeholders on what the
final shippable product will contain.
○○ At the end of the sprint, the work should be potentially shippable.
• Sprint Retrospective:
○○ The sprint ends with a sprint review and retrospective. The team discussed
what did and did not go well, and take actions to make the next sprint better.

61
Scrum
Figure 15: Scrum
Scrum has three main roles – Product Owner, Scrum Master, and Scrum Team.
• Product Owner: The product owner is responsible for the overall product vision.
He re-prioritizes the Product Backlog, and adjusts it per release plans. He sets the
priorities to the development team. He has a leadership role, and carries significant
authority. He considers stakeholder interests, and takes a call on what goes in the
Sprint cycle. To the Scrum Team, Product Owner availability is very important as
he has clarity on customer requirements, and can answer questions.
• Scrum Master: The Scrum Master acts as a facilitator for the Product Owner and
the team. He does not manage the team, but ensures that any impediments that
obstructs the team from achieving its sprint goals are removed. He works with the
Product Owner and the organization to make Scrum possible. He works with the
Product Owner on how to maximize Return on Investment of the development
effort. The Scrum Master helps the team remain creative and productive.
• Scrum Team: The Scrum development team is usually self-managing and cross-
functional. The team plans one Sprint at a time with the Product Owner, and has
autonomy and responsibility to meet the goals of the Sprint. The team is intensely
collaborative, and is in one room to be massively productive. The constitution
of the Scrum Team is officially 3–9 members; it includes members with business
analysis, programming, testing, designer, domain, and software engineering skills.

62
DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)

The Dynamic Systems Development Method (DSDM) is an agile project delivery framework,
primarily used as a software development method. It is a framework which embodies much
of the current knowledge about project management. DSDM is rooted in the software
development community, but the convergence of software development, process engineering
and hence business development projects has changed the DSDM framework to become
a general framework for complex problem solving tasks. The DSDM framework can be
implemented for agile and traditional development processes. DSDM brings together the
agility, flexibility, and project governance together.
Dynamic Systems Development Method (DSDM)
Figure 16: Dynamic Systems Development Method (DSDM)
DSDM is vendor-independent, covers the entire lifecycle of a project and provides best
practice guidance for on-time, in-budget delivery of projects, with proven scalability to
address projects of all sizes and for any business sector.
There are 9 principles underlying DSDM.
1. Active user involvement – Imperative.

2. Teams must be empowered to make decisions.
3. Focus on frequent delivery.
4. Criterion for accepted deliverable (Fitness for Business).
5. Iterative and incremental development – Mandatory.
6. All changes during development must be reversible.
7. Requirements are base lined at high level.
8. Testing is integrated throughout the life cycle.
9. Collaborative and co-operative approach.

63
Project Structure:
The DSDM project consists of 7 phased steps which are organized and embedded in a rich
set of roles and responsibilities and are supported by several core techniques.
• Roles and Responsibilities

• Team Organization and Size
• 7 Phases to Rule Them
1. Pre-Project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design & Build Iteration
6. Implementation
7. Post-Project
Time management
Find out how to manage your time better
Click here

64
DSDM advocates the use of several proven techniques, including:
• MoSCoW Prioritization: Since DSDM projects are concerned to be in time and

on budget, the focus is on the requirements that users need the most. Therefore,
DSDM uses MoSCoW rules to weight the importance of requirements. DSDM
fixes cost, quality and time at the outset and uses the MoSCoW prioritization of
scope into musts, shoulds, coulds and won’t haves to adjust the project deliverable
to meet the stated time constraint.
○○ Must have: MUST have this requirement to meet the business needs.
○○ Should have: SHOULD have this requirement if possible, but the project
success does not rely on this.
○○ Could have: COULD have this requirement if it does not affect the fitness
of business needs of the project.
○○ Want to have: WON’T represents a requirement that stakeholders have agreed
will not be implemented in each release, but may be considered for the future.
• Time boxing: Time boxing is an interval, usually no longer than 2, 4 or 6 weeks,

where a given set of tasks should be achieved. DSM drops functionality in favor
of delivering in time.
• Prototyping: In DSDM, prototyping focuses on two principles – Frequent Delivery
& Incremental Development. The following types of prototypes are conducted:
○○ Business Prototype: Assess business requirements will be met

○○ Usability Prototype: Evaluate user interface
○○ Performance Prototype: Checks performance requirements of the solution
○○ Capability Prototype: Evaluate possible options
CRYSTAL METHODOLOGY
Crystal Methodology is a lightweight, adaptable approach to software development. Developed
by Alistair Cockburn, Crystal Methodology focuses primarily on people and their interaction
during a software development project.
In Cockburn’s words, “Crystal is a family of human-powered, adaptive, ultra-light, ‘stretch-

to-fit’ software development methodologies.”
(Alistair Cockburn; http://alistair.cockburn.us/Crystal+methodologies)

65
• Crystal is “human-powered” – This means that people are the most important aspect
of Crystal, and all processes and tools are built around them. Crystal emphasized
that development teams are self-sufficient and self-organizing, so they can streamline
the processes as the work progresses and become more effective.
• Crystal is “adaptive” – Crystal processes and tools are adjusted to the requirements
and context of the project. They are adapted to suit the business and technical
requirements of the project.
• Crystal is “ultra-light” – Crystal tries to keep simple (or light) by minimizing
documentation, overhead management and reporting. It removes the unnecessary
clutter by focusing on business value and functional software. Open communication
and transparent information flow is, therefore, encouraged between the team members.
The Crystal family of methodologies consists of the following variants: Crystal Clear, Crystal
Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond
and Crystal Sapphire. The weight of the Crystal methodology is determined by the project
environment and team size. For example, a team of six developers will go for Crystal clear;
a team of 10–40 members and a lifespan of 1–2 years will go for Crystal Orange. For
extremely large and risky projects, Crystal Sapphire or Crystal Diamonds methods may be
more appropriate.
For the successful implementation of the Crystal approach, Crystal is precise that the
development approach should be iterative and incremental, user involvement should be
active, and commitments on delivery are met.
FEATURE DRIVEN DEVELOPMENT (FDD)

Feature-driven Development (FDD) is an iterative and incremental software development
Agile process. FDD is model-driven and short-iteration process. It begins with an overall
model shape unique to each project, then continues with a series of two-week “design by
feature, build by feature” iterations. The features must be value-based and useful to the end
users. FDD uses the following eight practices for the development process:
• Domain Object Modeling

• Developing by Feature
• Component/Class Ownership
• Feature Teams
• Inspections
• Configuration Management
• Regular Builds
• Visibility of progress and results

66
FDD consists of five basic activities namely the development of an overall model, the
building of a feature list, the planning by feature, the designing by feature, and the building
by feature.
LEAN SOFTWARE DEVELOPMENT

Lean Software Development is an iterative agile methodology originally developed by Mary
and Tom Poppendieck. Based on the Lean principles and practices of companies such as
Toyota, Lean Software Development focuses on delivering Value to the customer, and on
the efficiency of the Value Stream – the mechanisms that deliver that Value. The main
principles of Lean methodology include:
• Eliminating Waste
• Amplifying Learning
• Deciding as Late as Possible
• Delivering as Fast as Possible
• Empowering the Team
• Building Integrity In
• Seeing the Whole
The following table shows how the above Lean principles apply to Lean Software Development.
Avoid:
• unnecessary code or functionality

• starting more than can be completed
• delay in the software development process
Eliminating Waste • unclear or constantly changing requirements
• bureaucracy
• slow or ineffective communication
• partially done work
• defects and quality issues
• task switching

67
Encourage:
• Pair Programming
• Code reviews
• Documentation
Amplifying Learning
• Wiki – to let the knowledge base build up incrementally
• Thoroughly commented code
• Knowledge sharing sessions
• Training
• Use tools to manage requirements/user stories
Deciding as Late • Decide what features to include in each iteration and

as Possible analyze them just in time for them to be developed
• Do not over-engineer
• Build a simple solution first and enhance incrementally later
Delivering as Fast • Have the right team so that the team objectives are
as Possible achieved with minimum bureaucracy
• Have the right people so that they can trouble-shoot,
solve problems and make quick decisions
• Encourage people to have their say

• Show empathy for their point of view
Empowering the Team
• Give people the authority to make decisions about their
work
The following Agile practices improve the quality of the software

product:
• Pair programming
• Test Driven Development
Building Integrity In
• Constant Feedback – Inspect and Adapt
• Minimize time between stages
• Frequent Integration
• Automation
• Manage Trade-offs
• Drive agile adoption from the top

• Structure team by products or projects, instead of roles
or skills
Seeing the Whole
• Organize teams so that they are complete, multi-disciplined,
and co-located
• Optimize the whole value stream

68
ADAPTIVE SOFTWARE DEVELOPMENT

Adaptive software development (ASD) is a software development process that evolved from
Rapid Application Development (RAD) work by Jim Highsmith and Sam Bayer. It embodies
the principle that continuous adaption of the process to the work at hand is the normal. It
is called adaptive because it provides the ability to accommodate change and is adaptable
in turbulent environments with products evolving with minimal planning and learning.
ASD life cycle is cyclical and the key phases are –
• Speculate
• Collaborate
• Learn
Adaptive Software Development
Speculate
Learn Collaborate
Figure 17: Adaptive Software Development
In ASD, the term speculate is used in place of the term plan. This, however, does not
replace planning; but acknowledges the reality of uncertainty in complex problems. Speculate
encourages exploration and experimentation. Short iterative cycles are encouraged.
Collaboration is key in ASD because it enables to build complex applications in turbulent

environments. Collaboration requires the ability to work jointly to collect, analyze and apply
large volume of information to complex problem.
Learn part of the ASD enhances team knowledge constantly through practices such as
technical reviews, project retrospectives, and customer focus groups.
In summary, ASD follows the Speculate – Collaborate – Learn cycle.

69
AGILE PROJECT MANAGEMENT

Agile Project Management is a value-driven approach that allows Project Managers (PMs) to
deliver high-priority, high-quality work. It allows PMs to embrace change effectively without
going through the error-prone approach of project management. Agile project management
focuses on delivering the features with greatest business value first, while managing cost,
time and scope with efficiency.
Following the Agile approach, Agile project management reduces complex projects into small,
usable features that are delivered in two-to-four-week cycles. It achieves this by dividing
responsibilities among three key agile roles:
• The Product Owner handles setting project goals, tradeoff of schedule vs. scope,
adapting to changing project requirements and setting priorities for product features.
• The Scrum Master guides the team to prioritize their tasks and removes impediments
to handling their tasks.
• The Team Members directly handle their daily tasks, progress reporting, and quality
control of their product.
KANBAN
Kanban is a method for managing creation of products with an emphasis on continual delivery
while not overburdening the development team. Kanban is based on three basic principles:
• Visualize what you do today (workflow)

• Limit the amount of work in progress (WIP)
• Enhance flow
Kanban therefore emphasizes continuous delivery, continuous collaboration, and

continuous learning.
Kanban originated from the world of Lean Manufacturing as a way of doing “Just-in-Time”
production. It was developed by Toyota in the 1950s.
Like other Agile frameworks, Kanban focus on iterative delivery where teams work in two-
to-four-week “sprints” to deliver a small batch of User Stories. The flow of work is visualized
on a Kanban board. You can visualize how the work is flowing during the sprint through
the very fast iterations of design, develop, and test that happen within each sprint. The
Kanban board also helps us to determine the capacity for more work (depending on Work
in Progress status). If there is capacity, the team pulls the next item to work on. And when
the task is done, each item is marked Done.

70
Focusing on Agile process flow using Kanban can sometimes be even more efficient, resulting
in shorter lead times and higher productivity.
Note than Kanban is a process improvement approach, and not a process of its own. It
can be applied to Agile or Scrum; Kanban complements them rather than replace them.
The key differences between Kanban and Scrum are:
Source: www.versionone.com/what-is-kanban/
SCALED AGILE FRAMEWORK (SAFE)

The Scaled Agile Framework (SAFe®) is a freely revealed knowledge base of proven, integrated
patterns for enterprise-scale Lean-Agile development. It is scalable and modular, allowing
each organization to apply it in a way that provides better business outcomes and happier,
more engaged employees.
SAFe synchronizes alignment, collaboration, and delivery for large numbers of Agile teams.
It supports both software and systems development, from the modest scale of well under
100 practitioners to the largest software solutions and complex cyber-physical systems,
systems that require thousands of people to create and maintain. SAFe was developed in the
field, based on helping customers solve their most challenging scaling problems. It leverages
three primary bodies of knowledge: Agile development, Lean product development, and
systems thinking.

71
SAFe can be configured with the three or four organizational levels described above, plus
a Foundation layer, as described below:
• Team Level • Program Level • Value Stream Level
• Portfolio Level • Foundation Level
The SAFe Core Values are the guiding principles that dictate behavior and action. These
values can help people know what is right from wrong, where to put their focus, and how
to help companies to determine if they are on the right path to fulfill their business goals.
• Alignment • Built-in Quality
• Transparency • Program Execution
SAFe’s practices are grounded on nine fundamental principles that have evolved from Agile
principles and methods, Lean product development, systems thinking, and observation of
successful enterprises. There is a specific article for each principle on the SAFe website, and
the embodiment of the principles appears throughout the Framework.
• Take an economic view • Apply systems • Assume variability;

thinking preserve options
• Build incrementally • Base milestones on • Visualize and limit

with fast, integrated objective evaluation WIP, reduce batch
learning cycles of working systems sizes, and manage
queue lengths
• Apply cadence, • Unlock the intrinsic • Decentralize

synchronize with cross- motivation of decision-making
domain planning knowledge workers
SAFe’s interactive “Big Picture” (Figure 1) provides a visual overview of the Framework. It
has two views. The default “3-level view” is well suited for solutions that require a modest
number of Agile teams, as well as smaller systems, products and services that are largely
independent of each other. The “4-level view” supports those building large, integrated
solutions that typically require hundreds or more practitioners to build and maintain.

72
Figure 18: 3-Level SAFe
Figure 19: 4-Level SAFe

73
AGILE CONCEPTS Glossary
10 GLOSSARY
Acceptance Criteria: These are specific criteria identified by the customer for each functional
requirement. The acceptance criteria are written in simple terms and from a perspective of
the customer.
Acceptance Testing: Acceptance testing is a validation activity conducted to determine whether

a system satisfies its acceptance criteria. It is the last phase of the software testing process.
Agile: A conceptual framework for undertaking software projects. Agile methods are a family
of development processes, not a single approach to software development.
Acceptance Test Driven Development (ATDD): Analogous to test-driven development,

Acceptance Test Driven Development (ATDD) involves team members with different
perspectives (customer, development, testing) collaborating to write acceptance tests in
advance of implementing the corresponding functionality.
Automated Build: Refers to an automated process that converts files and other assets under
the developers’ responsibility into a software product in its final or consumable form.
For internal use only

74
Backlog: A backlog is a list of features or technical tasks which the team maintains and
which, at a given moment, are known to be necessary and sufficient to complete a project
or a release. The backlog is the primary point of entry for knowledge about requirements,
and the single authoritative source defining the work to be done.
Backlog Grooming: Backlog grooming is when the product owner and some, or all, of the
rest of the team review items on the backlog to ensure the backlog contains the appropriate
items, that they are prioritized, and that the items at the top of the backlog are ready
for delivery.
Behavior Driven Development: Behavior driven development (or BDD) is an agile software
development technique that encourages collaboration between developers, QA and non-
technical or business participants in a software project. BDD focuses on obtaining a clear
understanding of desired software behavior through discussion with stakeholders. It extends
TDD by writing test cases in a natural language that non-programmers can read.
Bottleneck: A bottleneck is a sort of congestion in a system that occurs when workload

arrives at a given point more quickly than that point can handle it.
Bugs: A software bug is a problem causing a program to crash or produce invalid output.
It is caused by insufficient or erroneous logic and can be an error, mistake, defect or fault.
Burndown Chart: A burndown chart is a visual tool for measuring and displaying progress.
Visually, a burndown chart is simply a line chart representing remaining work over time.
Burndown charts are used to measure the progress of an agile project at both an iteration
and project level.
Business Application Owner (AKA Product Owner): The product owner is responsible
for the project vision, business case realization, high level requirements, prioritization, and
final acceptance. The product owner or their delegate is expected to interact heavily with
the core team. Product Owners will sometimes delegate the day-to-day team interactions
to a business lead. In either case, the team needs to have someone who can quickly answer
requirements questions and make tradeoff decisions.
Business Lead: The Business Lead works with Solution Analysts to translate business processes
and solution requirements to solution delivery methodology work products that can be
used for development, they sign off on project business process and solution requirements
work products, and ensure consistency of requirements across process, requirements, and
user interface.

75
Business Value: Items that are of tangible and generally near term value to the business.
Examples of Business Value could be a new screen, report, or feature for an asset. It is
important to note that items not designated as Business Value still produce value for the
business. However, the value is either a long-term benefit or something not tangible to
the user.
Collective Ownership: Collective code ownership, as the name suggests, is the explicit
convention that “every” team member is not only allowed, but in fact has a positive duty,
to make changes to “any” code file as necessary: either to complete a development task, to
repair a defect, or even to improve the code’s overall structure.
Continuous Development: Continuous deployment can be thought of as an extension of

continuous integration, aiming at minimizing lead time, the time elapsed between development
writing one new line of code and this new code being used by live users, in production.
Continuous Integration: Continuous integration is done to minimize the duration and

effort required by each integration cycle, and to deliver a product version suitable for release
at any moment.
CRC Cards: CRC cards (for Class, Responsibilities, Collaborators) are an activity bridging
the worlds of role-playing games and object-oriented design.
Daily Standup/Daily Meeting: Daily Standup is a whole team meeting that happens at the
same time every day that usually lasts 15 minutes or less. The meeting is designed to allow
the entire team to synchronize with each other and to understand the flow and challenges
of the development process. Each team member should provide the following information:
what did I do yesterday, what am I planning to do today, and what impediments do I
currently have?
Defect: An undesired outcome that is discovered after the appropriate party has signed off
on some functionality as working. This is typically found outside of the current Iteration.
Dependency: A dependency arises when one task relies upon the completion another task.
For example, completion of feature X may depend upon feature Y working. In this case,
feature X is dependent upon feature Y.
Done: Also, referred to as “Done Done”, this term is used to describe all the various tasks
that need to happen before a story is considered potentially releasable.

76
Epic: A very large user story that is eventually broken down into smaller stories.
Estimation: The process of agreeing on a size measurement for the stories, as well as the
tasks required to implement those stories, in a product backlog.
Exploratory Testing: Exploratory testing is a style or approach to testing software which is

often contrasted to “scripted testing”. It recommends performing various test-related activities
(such as test design, test execution, and interpretation of results) in an interleaved manner,
throughout the project, rather than in a fixed sequence and at a phase.
Facilitation: A facilitator is a person who chooses or is given the explicit role of conducting
a meeting. This role usually entails that the facilitator will take little part in the discussions
on the meeting’s topic, but will focus primarily on creating the conditions for effective group
processes, in the pursuit of the objectives for which the meeting was convened.
Feature: Features are high level business needs. Features typically undergo more detailed
analysis and decompose into more fully defined user stories prior to implementation by
the team.
Feature Creep: Feature creep occurs when software becomes complicated and difficult to
use because of too many features.
Frequent Releases: A process where product is frequently released to end users for feedback.
Given-When-Then: The Given-When-Then formula is a template intended to guide the

writing of acceptance tests for a User Story: (Given) some context; (When) some action is
carried out; (Then) a set of observable consequences should obtain.
Heartbeat Retrospective: The team meets regularly, usually adhering to the rhythm of its
iterations, to explicitly reflect on the most significant events to have occurred since the
previous such meeting, and take decisions aiming at remediation or improvement.
Incremental Development: The means by which each successive version of the product is
built upon the previous version by adding user-visible functionality.
Information Radiators: Generic term used for any of several handwritten, drawn, printed or
electronic displays which a team places in a highly visible location, so that all team members
as well as passers-by can see the latest information at a glance: count of automated tests,
velocity, incident reports, continuous integration status, and so on.

77
Integration: Refers to any efforts still required, after individual programmers, or sub-groups
of programmers working on separate components, for a project team to deliver a product
suitable for release as a functional whole.
Invest: It is an acronym to assess the quality of a user story. It stands for Independent (of
all others), Negotiable (not a specific contract for features), Valuable (or vertical), Estimable
(to a good approximation), Small (so as to fit an iteration), and Testable.
Iteration: A short, 2–4 week, development and test cycle during which the team will develop
working, tested software for a selected few user stories and demo the working software to
stakeholders.
Iteration Backlog: The short-list of user stories that have been selected from the product
backlog for a specific iteration.
Kanban: Kanban, pronounced /’kan’ban/, is a method for developing products with an

emphasis on just-in-time delivery and the optimization of flow of work on the team. It
emphasizes that developers pull work from a queue, and the process, from definition of a
task to its delivery to the customer, is displayed for participants to see.
Lead Time: “Lead time” is a term borrowed from the manufacturing method known as Lean
or Toyota Production System, where it is defined as the time elapsed between a customer
placing an order and receiving the product ordered. Translated to the software domain, lead
time can be described more abstractly as the time elapsed between the identification of a
requirement and its fulfillment.
Lean: Lean software development is a translation of Lean manufacturing and Lean IT

principles and practices to the software development domain. Adapted from the Toyota
Production System and is a set of techniques and principles for delivering more values with
the same or less resources by eliminating waste across organizations and business processes.
Milestone Retrospective: An event spanning over several days that is invested to conduct
a detailed analysis of the project’s significant events.
Mock Objects: A technique commonly used in the context of crafting automated unit
tests. It consists of instantiating a test-specific version of a software component (typically a
class), which instead of the normal behaviors provides pre-computed results, and often also
checks that it’s invoked as expected by the objects being tested.

78
Niko-niko Calendar: The team installs a calendar one of the room’s walls. The format of
the calendar allows each team member to record, at the end of every workday, a graphic
evaluation of their mood during that day. This can be either a hand-drawn “emoticon”, or
a colored sticker, following a simple color code, for instance: blue for a bad day, red for
neutral, yellow for a good day. Over time, the niko-niko calendar reveals patterns of change
in the moods of the team, or of individual members.
Pair Programming: An agile software development technique in which two programmers

work together at one workstation. One types in code while the other reviews each line of
code as it is typed in. The person typing is called the driver. The person reviewing the code
is called the observer (or navigator). The two programmers switch roles frequently.
Personas: When the project calls for it – for instance when user experience is a major factor
in project outcomes – the team crafts detailed, synthetic biographies of fictitious users of
the future product: these are called “personas”.
Planning Poker: Also, called Scrum poker, is a consensus-based technique for estimating,
mostly used to estimate effort or relative size of tasks in software development.
Points: Unit used for estimating of efforts needed for development of user stories.
Product Backlog: Acts as a repository for requirements targeted for release at some point.
These are typically high level requirements with high level estimates provided by the product
stakeholders. The requirements are listed on the backlog in priority order and maintained
by the product owner.
Product Owner: The Product Owner represents the voice of the customer and is accountable
for ensuring that the Team delivers value to the business. The Product Owner writes customer-
centric items (typically user stories), prioritizes them, and adds them to the product backlog.
Scrum teams should have one Product Owner.
Project Chartering: A high-level summary of the project’s key success factors that can be
displayed on one wall of the team room as a flipchart-sized sheet of paper.
Quick Design Session: A session where two or more developers meet to discuss the design
choices that may have far-reaching consequences.
Release Activity: Any activity that is necessary to help implement some functionality into
production.

79
Refactoring: Refactoring consists of improving the internal structure of an existing program’s

source code, while preserving its external behavior. (Red: Green: Refactor). This is a TDD
technique which describes writing a failing test first (Red), writing just enough code to pass
that test (Green), and then modifying the code to a cleaner, more readable state (Refactor).
Relative Estimation: Relative estimation is one of the several distinct flavors of estimation
used in Agile teams, and consists of estimating tasks or user stories, not separately and in
absolute units of time, but by comparison or by grouping of items of equivalent difficulty.
Retrospective: A team meeting that happens at the end of every development iteration to
review lessons learned and to discuss how the team can be more efficient in the future.
It is based on the principles of applying the learning from the previous sprint to the
upcoming sprint.
Role-Feature-Session: The “role-feature-reason” template is one of the most commonly

recommended aids (often outgrown once past the novice stage) for teams and product
owners starting to write user stories
Rules of Simplicity: A set of criteria, in priority order, proposed by Kent Beck to judge
whether some source code is “simple enough” that the code is verified by automated tests,
and all such tests pass, the code contains no duplication, the code expresses separately each
distinct idea or responsibility, the code is composed of the minimum number of components
(classes, methods, lines) compatible with the first three criteria.
Scrum: A framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value. It is based on
the adaptive and iterative methodology of software development.
Scrumban: Scrumban is a mix between Scrum and Kanban, which supposedly contains the
best features of both methods.
Scrum of Scrums: A technique to scale Scrum up to large groups (over a dozen people),
consisting of dividing the groups into Agile teams of 5–10. Each daily scrum within a sub-
team ends by designating one member as “ambassador” to participate in a daily meeting
with ambassadors from other teams, called the Scrum of Scrums.

80
Scrum Master: Scrum Master is accountable for removing impediments to the ability of
the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader
but acts as a buffer between the team and any distracting influences. The Scrum Master
ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of
rules. A key part of the Scrum Master’s role is to protect the team and keep them focused
on the tasks at hand. The role has also been referred to as servant-leader to reinforce these
dual perspectives.
Show & Tell: A demonstration of working software that occurs at the end of each iteration.
The goal of the Show and Tell is to get valuable feedback from the product owner and
other stakeholders.
Sign Up for Tasks: Members of an Agile development team normally choose which tasks
to work on, rather than being assigned work by a manager.
Simple Design: A team adopting the “simple design” practice bases its software design
strategy on the following principles: design is an ongoing activity, which includes refactoring
and heuristics such as YAGNI (You Aren’t Gonna Need It); design quality is evaluated
based on the rules of code simplicity; all design elements such as “design patterns”, plugin-
based architectures, etc. are seen as having costs as well as benefits, and design costs must
be justified; design decisions should be deferred until the “last responsible moment”, so
as to collect as much information as possible on the benefits of the chosen option before
incurring its costs.
Sizing: The process of relating the effort of one item to another. It will either be the same
size, bigger or smaller. We do sizing instead of estimating, because estimation is time based
and difficult to do well, and sizing is effort based and easier to do well.
Spike: A short, time-boxed piece of research, usually technical, on a single story that is
intended to provide just enough information that the team can estimate the size of the story.
Sprint/Iteration: A fixed duration period of time where user stories are chosen to work
on. The term Sprint comes from the Scrum methodology and is analogous to the term
Iteration. A sprint is defined as a 2–4 week increment of software development activities
that delivers working software and the end of the increment. External influences are not
allowed to change the requirements of the stories being worked on.

81
Spring Backlog: At the beginning of each sprint, the team has sprint planning with an end
result being a backlog of work that the team anticipates completing at the end of the sprint.
These are the items that the team will deliver against throughout the duration of the sprint.
Sprint Planning: Is a pre-sprint planning meeting attended by the core agile team. During
the meeting the Product Owner describes the highest priority features to the team as
described on the product backlog. The team then agrees on the number of features they can
accomplish in the sprint and plans the tasks required to achieve delivery of those features.
The planning group works the features into User Stories and assigns Acceptance criteria to
each story.
Sprint Review: Each Sprint is followed by a Sprint review. During this review the software
developed in the previous Sprint is reviewed and if necessary new backlog items are added.
Story Card: A place holder for a user-story. Story cards are typically 3×5 or 5×7 cards or
stickies that are put on the wall so that they can be easily tracked.
Story Mapping: Story mapping consists of ordering user stories along two independent
dimensions. The “map” arranges user activities along the horizontal axis in rough order of
priority (or “the order in which you would describe activities to explain the behavior of the
system”). Down the vertical axis, it represents increasing sophistication of the implementation.
Story Point: Unit of estimation measuring complexity and size.
Story Splitting: Splitting consists of breaking up one user story into smaller ones, while
preserving the property that each user story separately has measurable business value.
Sustainable Pace: The team aims for a work pace that they would be able to sustain
indefinitely.
Task: A user story can be broken down in to one or more tasks. Tasks are estimated daily
in hours (or story points) remaining by the developer working on them.
Taskboard/Storyboard: A wall chart with cards and sticky notes that represents all the work
for in each sprint. The notes are moved across the board to show progress.

82
Team: The Team is responsible for delivering the product. A Team is typically made up of
5–9 people with cross-functional skills who do the actual work (analyze, design, develop,
test, technical communication, document, etc.). It is recommended that the Team be self-
organizing and self-led, but often work with some form of project or team management.
Team Room: A dedicated space set for the Agile team for the duration of the project, set
apart from other groups’ activities.
The Three C’s: “Card, Conversation, Confirmation”; this formula that captures the components
of a User Story.
Technical Card: A card that doesn’t provide business value in and of itself. This is typically
used to implement some technical functionality or reduce technical debt, that will help to
deliver future story cards.
Test Driven Development: Test-driven development (TDD) is a software development

process that relies on the repetition of a very short development cycle: first the developer
writes a failing automated test case that defines a desired improvement or new function, then
produces code to pass that test and finally refactors the new code to acceptable standards.
Three Amigos: Three amigos refer to the primary perspectives to examine an increment
of work before, during, and after development. Those perspectives are: Business – What
problem are we trying to solve? Development – How might we build a solution to solve
that problem? Testing – What about this, what could possibly happen?
Three Questions: The daily meeting is structured around some variant of the following
three questions: What have you completed since the last meeting? What do you plan to
complete by the next meeting? What is getting in your way?
Timeboxing: Timeboxing is a planning technique common in planning projects (typically

for software development), where the schedule is divided into several separate time periods
(timeboxes, normally two to six weeks long), with each part having its own deliverables,
deadline and budget.
Ubiquitous Language: A design approach described in Eric Evans’ “Domain Driven Design”
(2003), which consists notably of striving to use the vocabulary of a given business domain,
not only in discussions about the requirements for a software product, but in discussions
of design as well and all the way into “the product’s source code itself ”.

83
Unit Testing: A unit test, as Agile teams understand the term, is a short program fragment
written and maintained by the developers on the product team, which exercises some narrow
part of the product’s source code and checks the results. The outcome of a unit test is
binary: either “pass” if the program’s behavior is consistent with the recorded expectations,
or “fail” otherwise.
Usability Testing: Usability testing is a long-established, empirical and exploratory technique

to answer questions such as “how would an end user respond to our software under realistic
conditions?” It consists of observing a representative end user interacting with the product,
given a goal to reach but no specific instructions for using the product.
User Persona: Personas are a description of the typical users of a given software.
Leadership skills
Click here

84
User Story: A user story is a very high-level definition of a requirement, containing just
enough information so that the developers can produce a reasonable estimate of the effort to
implement it. A user story is one or more sentences in the everyday or business language of
the end user that captures what the user wants to achieve. A user story is also a placeholder
for conversation between the users and the team. The user stories should be written by or
for the customers for a software project and are their main instrument to influence the
development of the software. User stories could also be written by developers to express
non-functional requirements (security, performance, quality, etc.)
Velocity: It is a relative number which describes how much work the team can get done
over a period.
Vertical Slice: Showing off a feature in an application that works from start to finish but
may be limited in scope. For example, a rope bridge crossing a chasm is immediately useful
and allows people to cross. Having that in place can help to build a better bridge later.
WIP: Also, known as Work in Progress, it is any work that has been started but has yet
to be completed.
XP: A software development methodology which is intended to improve software quality and
responsiveness to changing customer requirements. As a type of agile software development,
it advocates frequent “releases” in short development cycles (timeboxing), which is intended
to improve productivity and introduce checkpoints where new customer requirements can
be adopted.

85
AGILE CONCEPTS References
11 REFERENCES
Bibliography:
1. Measey, Peter, and Radtac. Agile Foundations: Principles, Practices, and Frameworks.
Swindon, United Kingdom: BCS – The Chartered Institute for IT, 2015.
2. Martin, Robert C. Agile Software Development: Principles, Patterns, and Practices.
Upper Saddle River, New Jersey: Prentice Hall, 2003.
3. Leyton, Ryland. The Agile Business Analyst: Moving from Waterfall to Agile. San
Bernandino, CA: www.RylandLeyton.com, 2015.
4. Scaled Agile. SAFe 4.0 Introduction – A Scaled Agile, Inc. White Paper.
Scaledagileframework.com/scaled agile.com, 2016.
5. Heuther, Derek. An Introduction to Cost of Delay. www.leadingagile.com, 2015.
Other Online Sources:

• www.agilealliance.org
• https://www.techopedia.com/definition/27913/technical-debt
• https://en.wikipedia.org/wiki/Empirical_process_(process_control_model)
• https://en.wikipedia.org/wiki/Toyota_Production_System
• https://en.wikipedia.org/wiki/Waterfall_model
• http://www.telerik.com/teampulse/agile-vocabulary#778ce003-7c4e-48ce-a4b9-
219c9458d8b6
• https://www.agilealliance.org/agile101/agile-glossary/
• http://www.agilemodeling.com/artifacts/userStory.htm#sthash.H4Q3wyez.dpuf
• https://help.rallydev.com/writing-great-user-story
• https://help.rallydev.com/sizing-and-estimates
• http://www.agilenutshell.com/planning
• http://www.extremeprogramming.org/rules/
• https://www.agilealliance.org/glossary/bdd/
• http://www.umsl.edu/~sauterv/analysis/f06Papers/Hutagalung/
• https://www.scrumalliance.org/why-scrum
• http://scrummethodology.com/
• https://www.atlassian.com/agile/scrum
• https://en.wikipedia.org/wiki/Dynamic_systems_development_method
• http://dsdmofagilemethodology.wikidot.com/
• https://www.agilebusiness.org/what-is-dsdm
• http://www.scrumstudy.com/blog/what-is-crystal/
• http://www.allaboutagile.com/7-key-principles-of-lean-software-development-2/

86
AGILE CONCEPTS References
• http://www.extremeprogramming.org/
• https://www.tutorialspoint.com/adaptive_software_development/adaptive_software_
development_lifecycle.htm
• https://www.versionone.com/agile-project-management/
• https://www.versionone.com/what-is-kanban/
• https://leankit.com/learn/kanban/kanban-agile/
• http://www.scaledagileframework.com/
Source: blog.crisp.se

87

Agile Concepts

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Agile Concepts

Uploaded by

Copyright:

Available Formats

Agile

bookboon eLibrary – Partner of Siemens Global Learning Campus

bookboon eLibrary – Partner of Siemens Global Learning Campus

5 Generic Agile Process 28

bookboon eLibrary – Partner of Siemens Global Learning Campus

6 Common Agile Roles 30

7 Common Agile Techniques 33

8 Common Agile Practices 45

9 Major Agile Frameworks 54

bookboon eLibrary – Partner of Siemens Global Learning Campus

bookboon eLibrary – Partner of Siemens Global Learning Campus

bookboon eLibrary – Partner of Siemens Global Learning Campus

The Manifesto of the Agile Alliance:

• Individuals and interactions over processes and tools

bookboon eLibrary – Partner of Siemens Global Learning Campus

The following 12 principles are based on the Agile Manifesto:

• Individuals and interactions over processes and tools

bookboon eLibrary – Partner of Siemens Global Learning Campus

• Working software over comprehensive documentation

While a fit-for-purpose documentation is key (software without documentation is a

Documentation is important but it needs to be short and salient; it must be human-

Therefore, in Agile, working software is given more focus than comprehensive

• Customer collaboration over contract negotiation

bookboon eLibrary – Partner of Siemens Global Learning Campus

Therefore, in Agile, customer collaboration is given more weightage than contract

• Responding to change over following a plan

bookboon eLibrary – Partner of Siemens Global Learning Campus

Incremental software development based on a short-term detailed plan is a better ingredient

2. Welcome changing requirements, even late in development. Agile processes

bookboon eLibrary – Partner of Siemens Global Learning Campus

3. Deliver working software frequently, from a couple of weeks to a couple of

bookboon eLibrary – Partner of Siemens Global Learning Campus

7. Working software is the primary measure of progress.

bookboon eLibrary – Partner of Siemens Global Learning Campus

8. Agile processes promote sustainable development. The sponsors, developers,

9. Continuous attention to technical excellence and good design enhances agility.

bookboon eLibrary – Partner of Siemens Global Learning Campus

Year Development of Framework

Publication of ‘Software Reliability’ by Glenford Myers, which states as an

Substantial discussion of incremental development in IBM’s Federal Systems

The notion of “visual control” originating in the Toyota Production System

An early empirical study by Barry Boehm of projects using prototyping, by

The notion of “factoring”, an anticipation of refactoring, is described in

While criticisms of the “waterfall” sequential approach have started much

bookboon eLibrary – Partner of Siemens Global Learning Campus

Year Development of Framework

Perhaps the first explicitly named, incremental alternative to the “waterfall”

In a well-known paper, Barry Boehm presents “A Spiral model of software

The “time-box” is described as a cornerstone of Scott Schultz’s “Rapid

Rebecca Wirfs-Brock describes the conceptual aspects of CRC, which she

Testing discipline dominated by “black box” techniques, in the form of

A comprehensive description of “refactoring” is presented in Opdyke’s

1993 Jeff Sutherland invents Scrum as a process at Easel Corporation.

bookboon eLibrary – Partner of Siemens Global Learning Campus

Year Development of Framework

The earliest writings on Scrum introduce the notion of the “sprint” as

The practice of “refactoring”, incorporated a few years earlier into Extreme

2000 The burndown chart is first described by Ken Schwaber

2000 The term “velocity” is a relatively late addition to Extreme Programming

Following concepts introduced:

• Structural parallels between Agile and the ideas known as Lean

2002 The Scrum community picks up the practice of measuring “velocity”

2003 Publication of “Test Driven Development: By Example” by Kent Beck

2003 The term “domain driven design” is coined by Eric Evans