Raja Bavani is a staunch
Agile practitioner, an
evangelist and a
community champion.
He shares his experience
with Shadab Lari on 15
myths that people have
developed about Agile
Software Development
with insights to
overcoming those myths.
Agile Community | MindTree
About Raja Bavani Raja Bavani is Technical Director of MindTree’s Product Engineering Services (PES) group and plays the role of Product Engineering Evangelist, Agile Coach and Agile Community Champion. Raja has more than 20 years’ experience in the IT industry and has published papers at international conferences on topics related to code quality, distributed agile development, customer value management, and software estimation. His areas of interest include global delivery models, agile software development, requirements engineering, software architecture, software reuse, customer value management, knowledge management, and IT outsourcing. He is a member of IEEE and the IEEE Computer Society. Raja regularly interfaces with educational institutions, offers guest lectures, and writes for technical conferences. He can be reached at [email protected] or via his blog at www.mindtree.com/blogs/category/software-product-engineering.
AGILE COMMUNITY © MindTree 2011
i
yths help us uncover the truth as long as we ask questions & seek answers.
- Raja Bavani
Agile has been one of the hot topics in our industry over the past ten years. Raja, a
thought leader in this subject, has come across several myths & misrepresentations
about Agile in a wide variety of events ranging from hallway conversations to conference
panel discussions. He says, “Myths help us uncover the truth as long as we ask questions
& seek answers.” In this collection he shares insights on the myths & misrepresentations
that are very fundamental in nature. According to him just because they are fundamental
in nature they remain simple enough to communicate among peers. As they are simple
enough they are easy to digest & hence do not trigger any questions. As a result many of
us tend to live with them, assuming these myths to be the de facto rule of the game. The
myths & misinterpretations presented in this collection – 15 of them – are the ones he
has come across over a span of 10 odd years. As an Agile evangelist he has attempted to
craft & share his thoughts on each of them with an objective of providing adequate clarity
to the larger community of software professionals. He believes these thoughts will bust
Agile myths and manifest correct notions on Agile among our readers and states, “This is
a great way to learn.” Of course!
At the time of compiling this collection, I interviewed Raja to understand what lead to so
many myths and misinterpretations on Agile. During this interview, I took the liberty or
rather grabed the opportunity to ask him further about what the future of Agile is and how
he sees Agile methodologies unfolding. Also, I enquired him about the tips to adopt or
leverage Agile methodologies. The next page summarizes our conversation. Enjoy reading!
Shadab Lari MindTree KM Team
M
AGILE COMMUNITY © MindTree 2011
ii
Shadab: Tell us why Agile is still misunderstood despite
being in existence over the last 10 years?
Raja: There are two primary reasons. The first reason is
the evolution of Agile itself. This evolution involved a
cultural transformation in the industry from the
traditional way of creating and maintaining software to
the evolutionary way. During February 2001, 17
methodology experts convened at ‘The Lodge’ at
Snowbird Ski Resort in the Wasatch Mountains of Utah
and defined ‘Agile Manifesto’ and ‘Agile Principles’.
Gradually, the popularity of Agile grew across the globe.
As you could guess, the second reason is the way this
evolution happened. This evolution involved
practitioners across the globe. It did not mature with all
necessary details inside a university or research
laboratory and got presented to the community of
software engineering professionals.
When a transformation of this magnitude attempts to
influence a global industry like ours we do come across
some myths and misinterpretations.
Shadab: Ok. On a different note if we see the trend it
was Waterfall earlier & now Agile way of software
development, what will be next?
Raja: The popularity of Agile is on the rise. This trend will
continue over the next 5 years or so. The founders of
Agile Manifesto met on the 10th anniversary and came
up with statements on how things can be done better in
future. I have narrated this in my Konnect blog, ‘The
Future of Agile’.
In future, there will be new ideas and approaches.
However the fundamental principles will remain the
same. In my opinion, Agile Software Development has
provided us a good foundation. We need to apply both
project management and software engineering practices
well enough to deliver value to our customers. Next, we
need to build on these and explore ways to improve
further.
Shadab: How do you think people should adopt Agile
Methodology in their projects?
Raja: Agile Software Development in a distributed
environment does not mean step-by-step
implementation of any specific agile methodology such
as Scrum with high expectations on on-time high-quality
delivery. It means collaboration among distributed
teams to collate processes that follow agile principles
and to put together a methodology that works for them.
Projects that follow distributed agile suffer when a
methodology accepted by a sub team drives the rest of
the team. Successful distributed agile projects happen
because of collaborative teams that drive to define a
methodology for themselves. The definition of such a
methodology happens by means of open communication
and ongoing minor adjustments to make things work as
expected. More importantly, a methodology that works
for one distributed ecosystem may not work for another
distributed ecosystem. This is because, for any
methodology, while the basic tenets remain intact, the
implementation details vary across ecosystems.
Software projects are people intensive missions that
require lot of communication, coordination and
collaboration. Agile projects need team members who
are self-motivated and leaders by themselves. Agile
teams need to be self-organized. In order to become
self-organized, team members need to imbibe values
such as commitment, openness, focus, respect,
courage, simplicity, feedback and integrity.
I have attempted to provide a message or two in each of
these myths or misinterpretations. Besides, I strongly
believe that agile team members need to understand
the applicability and essence of what they do and how
they do what they do.
Agile Myths 1. Take The Waterfall Model and Add One Arrow 2
2. Agile means 'Start Coding With No Documentation' 4
3. Agile means 'Ad Hoc' or 'No Processes' 6
4. Agile means 'No Planning' 8
5. Agile Team Members Must be Super Stars 10
6. Agile is for Product Engineering Only 13
7. Changes Can Happen On a Daily Basis 14
8. Agile is for Development Projects Only 16
9. Agile Impacts Work-life Balance 17
10. Agile is Just Another Fad 18
11. TDD is Enough to Ensure Software Quality 19
12. A Chain of Unit Tests is a Complete Regression Suite 20
13. Agile Doesn’t Allow for Long-Term Planning 21
14. Agile Testing is All About Unit Testing, TDD, and Test Automation 22
15. In Agile Projects Process Compliance is a Big Issue 23
Image source: geekherocomic.com
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 2
AGILE MYTH 1
Take The Waterfall Model and Add One Arrow
Or he goes further to say, “Agile is nothing but a series of tiny waterfalls!” Ouch! What an over simplified version! A very good
analogy is to define RDBMS as a collection
of tables and views. Do you remember
early 90s? Or late 90s? Don't tell me that
it happens even today! The definition of
RDBMS is much more than this and it
includes data integrity, concurrency, SQL
support, logical independence, physical
independence and much more. Similarly,
defining Agile as a series of tiny waterfalls
is nothing but a misinterpretation or over simplification. Agile is much richer.
Waterfall model has been in practice
in our industry for more than 3
decades. We tend to map waterfall to
evolutionary methodologies such as
Agile. We tend to conclude that
making minor adjustments to
waterfall model can result in Agile.
Any thought leading to immediate
conclusions can mislead you.
CONSIDER THIS
You went around looking for a clarification on Agile
and you meet a buddy (someone who is very
talkative or pretends to know several things) across
the water cooler and you ask ‘What exactly is Agile?’.
And there he goes, “Take the waterfall model and
add one arrow!” Or he goes one step further and
draws a flow chart (see left) to elaborate this
misinterpretation. Sounds familiar?
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 3
There is a serious issue in visualizing Agile as a series of
tiny waterfalls. To understand this issue read “The
Pipelining Anti-Pattern” and understand what it is
about. Agile Software Development is based on ‘Agile
Manifesto’ and ‘Agile Principles’. You will find link to
these in my blog ‘The Future of Agile Manifesto’.
Agile Software Development is
about early and frequent delivery of
working software at regular
intervals in a sustainable pace.
It is about prioritizing features of
user stories that are critical on both
implementation perspective as well
as business perspective.
It is about increasing our ability to
respond to change at a project level
while maintaining scope integrity at
iteration level.
Agile is about delivering business value to customer and
requires a great deal of focus and discipline.
In order to accomplish these agile teams follow several
engineering best practices. Some of them are:
1) Adherence to Coding Standards & Usage of Code
Quality Tools (Eg. Code XRay)
2) Automated Unit Tests
3) Automated Build
4) Continuous Build/Integration
5) Test Automation
6) Test Driven Development (TDD)
7) Refactoring
Our Agile Community has a very good document
repository that includes white papers, articles and
presentations on Agile on our social intranet – Konnect –
platform. I encourage our community members to read
as many of them and also contribute good bookmarks
and articles to our community.
Next time, when someone sways you with definitions like
these, remember this myth buster series. Also, feel free
to use the following light-weight process to respond to
such discussions.
1) Smile and say, “Hmm.. Interesting!”, talk a little bit
about MindTree Agile Community and move on to
the next subject. No arguments please!
2) Read more and consult practitioners to validate
what you heard.
3) If it turns out to be a myth or misunderstanding
share it with the community.
One way of learning & getting insights is through myths
and misinterpretations too! Why not?
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 4
AGILE MYTH 2
Agile means Start Coding
With No Documentation
Image Source: dilbert.com
This is one of the most widespread
myths in our industry. Those who
believe in this myth think that Agile
teams are busy writing code all the
time and deliver working software to
customer. Also, they think that Agile
teams do not create documents and
ask, “Do Agile teams create designs
and write test cases? How do they
manage when the maintenance
team takes over?”
CONSIDER THIS
In Agile projects customers or
business users and software
engineers sit together.
Business users tell the
requirements & developers
write code. They do not do any
documentation. The dev team
delivers working software and
the code is well written with
adequate comments. The code
itself serves as a document at
a later stage.
This works to some extent
when software is developed by
a small team for limited use.
However it is important to know
that this approach does not
work for products or
applications offered to a wide
range of customers.
Agile Manifesto values working software over comprehensive documentation. This does not mean that Agile demotes documentation or encourages team members to start coding without any documentation. Agile promotes 'just enough' documentation so that project teams can make progress.
Agile discourages any document that is going to be read only by the creator and
reviewer. In my experience, I have seen project teams that create document for
anything and everything. I call them 'Document Driven Teams'. In one such
instance, I came across a document that had 7 pages out of which the relevant
content was only 2 pages
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 5
Agile Promotes Face-To-Face Communication and Collaboration.
CONSIDER THIS ONE TOO
In projects that follow
traditional approaches project
teams create UI design
document by pasting all
screen shots and providing
some description for each of
them. As the product or
application goes through
development phase, plenty of
UI changes happen. However
the UI design or screen
design document does not
get updated and hence
becomes obsolete. Agile
teams do not create such
documents. Instead they
check-in HTML wireframes in
the configuration
management system. If user
manual or UI design
document is one of the
deliverables, agile teams
create these when the
application or product is
stable enough.
“In one such instance, I came across a document that
had 7 pages out of which the relevant content was only 2
pages …”
… Everything else was the pre-filled document template with title, logo, table of
contents etc., If any software professional is feeling good about creating a
document like this by spending several hours & if that document is not going to
be read by anyone in future, then there is no value in creating such a document.
Agile Emphasizes on Understanding the True Value of Any Document Before Creating It.
On the other hand, it is not wise to execute projects with undocumented
requirements or designs. Executing software projects with no documentation can
lead to disastrous situations.
So, what do we do in Agile projects?
We create any document only when:
a) it is necessary
b) we are sure that it is going to be used by several team members in the
project
c) we can ensure that it will be kept up-to-date
d) we find that it is not a waste, and
e) we know that it is required for regulatory or compliance purposes
Thus documentation is not the primary means of communication among team
members. Documentation is done on need basis - for example, to specify user
stories or to preserve design decisions or to ensure knowledge retention.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 6
AGILE MYTH 3
Agile means Ad Hoc or No Processes
Image source: http://www.glommer.net/blogs/?p=189
There is also a widespread
misunderstanding in our industry that agile
means no process. Myth #2 relates to this
very well. Agile Manifesto values working
software over comprehensive
documentation. This does not mean that
Agile demotes process compliance or
documentation or encourages team
members to start coding without any
documentation.
Traffic deadlock is a common thing we witness all
around. We have skilled drivers with functional
automobiles. Road conditions have improved a lot.
However, when adherence to processes, procedures,
guidelines, and rules becomes the last priority and
moving fast and filling gaps on the street remains
the first priority, all one can experience is a
deadlock!
Working in Agile project does not mean ‘do-whatever-
feels-good’. Agile does not mean ‘hacking’ or not
following any processes.
If Agile teams do not identify processes that they need and establish certain policies and guidelines within the team, it is natural that they will experience
frequent deadlocks or sticky situations that result in delays.
In Agile projects, choose processes that can help you meet
project goals. For example, if you follow Scrum, which is
one among the popular Agile methodologies,
- you attend Scrum Planning meetings
- you follow estimation process
- you track efforts
- you monitor impediments or issues, and
- at the end you capture best practices, areas of
improvement by conducting retrospectives.
On engineering perspective you do follow processes
related to query tracking, reviews, testing etc. Obviously
as you would see working in an Agile project does not
mean that you can avoid or evade from process
compliance. So which means if you introduce heavy
weight processes you can’t move swiftly.
Thus you need right-weight processes.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 7
So the question is how difficult is it to practice right-weight processes and
ensure process compliance? Trust me, it is very easy. Work with your
Delivery Manager and Quality Catalyst and finalize your project plan and
tailor processes at the beginning of the project and finetune your processes
as you move on. Or feel free to reach out to the Agile Community
Champions.
Any process that is right for a project is not what the customer asks us to do
or what the customer prefers to do unless the customer is an expert in
process implementation and is well aware of how to select processes that
can add value to projects. When we follow customer’s orders blindly, we
become order takers. Anjan had written a good blog that touched upon
‘Becoming an Order Maker from Being an Order Taker’. It is a good read.
If we hide behind our customers’
preference of sharing code
review comments over email and
if we do not track all comments
in a central repository (say a
excel sheet or a web based tool),
we will miss the opportunity to
understand frequently occurring
code quality issues. This will
blind us from finding the right
spots or cases for defect
prevention. Consequently, one
day the customer can escalate
on a simple issue that has
recurred several times. Anytime,
we need to reengineer
processes and focus on
continuous improvements
instead of depending on
customers or doing exactly what
the customer wants us to do.
Sometimes we come across discussion points such as ‘My customer likes to receive status reports in email format. We do not use word or excel.’ In such cases we need to ask ourselves, ‘Are we leveraging organizational and industry best practices in status reporting? And will that add-value to the project?’
Executing software projects, including Agile projects with no
processes can lead to disastrous situations. Also in Agile
projects short iterations and frequent delivery of working code
makes you move fast. Thus:
It is our responsibility to engineer and tailor processes in such a way that they add value to how we do what we do in addition to making us efficient.
As you would see more discipline is required while executing Agile
projects.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 8
AGILE MYTH 4
Agile means No Planning
Agile Manifesto values ‘Responding to
Change’ over ‘Following a Plan’. This
does not mean that Agile manifesto is
against planning. In fact, it indicates
that responding to changes is more
important than following a plan.
When is the last time you executed a software project by following the original detailed plan? Can anyone succeed
in software projects by creating a detailed plan and following it sincerely? Yes. This is doable only if there is high
level of certainty with no technical challenges and frozen requirements. A vast majority of projects we execute do
not belong to this category. Quite often we accommodate our plans to suit the current context.
Traditional methodologies consider
upfront planning. Agile believes in just-enough planning because Agile
teams and stakeholders understand that change is inevitable.
Too much of planning destroys value unless there is
high degree of certainty in the project. No
stakeholder who has invested in a software project
will reward you or appreciate you for following the
original plan and failing to deliver valuable
software. So, we need the ability to embrace
change as we move forward and adjust our plans to
deliver value to business users or customers.
How do we do this in Agile?
We do this by performing detailed planning when we start an iteration or Sprint. Meanwhile, we maintain a high-level project plan. This helps us respond to changes as they progress.
Image Source: enagility.com
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 9
Image Source: thehindu.com
Responding to changes does not
mean saying no to planning and
being reactive as and when we
see some crisis. In real life, we
come across the perils of both
extremes of planning.
(A) No planning leads to
situations such as pothole driven
roads during monsoon, as you
can see in the picture to the
right.
(B) On the otherhand, too much
of upfront planning leads to
situations such as huge
investments in infrastructure that
becomes a dead investment.
Scrum is one of the popular Agile methodologies.
To know more about how Scrum teams go about planning, I encourage you to read Scrum Guide or Distributed Scrum Primer.
Image Source: chessinthesnow.blogspot.com
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 10
AGILE MYTH 5
Agile Team Members Must be Super Stars
Agile uncovers better ways of developing
software by doing it and helping others
do it. Through this work we have come
to value:
A) ‘Individuals and interactions’ over
processes and tools
B) Working software over
comprehensive documentation
C) Customer collaboration over
contract negotiation
D) Responding to change over following
a plan.
Also, 7 out of 12 Agile Principles talk about teams & team members.
These 7 principles are:
Principle-4: Business people and developers must work together daily
throughout the project.
Principle-5: Build projects around motivated individuals. Give them
the environment and support they need, and trust them to get the job
done.
Principle-6: The most efficient and effective method of conveying
information to and within a development team is face-to-face
conversation.
Principle-8: Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
Principle-9: Continuous attention to technical excellence and good
design enhances agility.
Principle-11: The best architectures, requirements, and designs
emerge from self-organizing teams.
Principle-12: At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior accordingly.
The first & the most important value outlined in Agile Manifesto is ‘Individuals and Interactions’ over ‘Process and Tools’.
None of these principles, as
you can see towards the
left, provides guidelines or
directives on considering
only super performers to
form agile teams.
Behind every successful
project we do see a team of
motivated individuals. This
is true for Agile as
well. Also, continuous
attention on technical
excellence and good design
is very important. The team
as a whole needs to have
this attention and make it
happen.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 11
Shu Ha Ri
Now the question is “Can we execute an Agile project by forming a team of
engineers with no working experience or less than a year of work experience?”
Well, it depends.
First let us understand what Alistair Cockburn, who is one
among the founders of ‘Agile Manifesto’ has written and
spoken on this subject. In his book ‘Agile Software
Development’, Alistair mentions that people learn skills in 3
stages. He draws parallels from ‘Aikido’ which is a form of
Japanese martial arts and ‘Shu Ha Ri’ that describes the
stages of learning right from fundamentals to mastery.
According to him the 3 stages of learning are, Shu - Learn a
technique, Ha – Collect techniques, and Ri – Invent / blend
techniques. Based on these 3 stages he categorizes team
members into the following three levels.
Level-1 (Shu) - Team members who can
learn and perform.
Level-2 (Ha) - Team members who have
learned techniques. They keep collecting
techniques that suit a context and apply
them. They have the capability to tailor a
method to fit a known situation.
Level-3 (Ri) - Team members who are able
to blend techniques. They have the
capability to write business logic for an
unprecedented new situation. They can
revise a method to suit a given context.
In his paper ‘Observations on Balancing
Discipline and Agility’, Barry Boehm has
classified Level-1 in to 3 levels (Level -1,
Level 1A and Level 1B) as shown to the
right.
According to this classification Agile teams
cannot progress with Level -1 or Level 1B
engineers. For example, an Agile team of
10 can have 5 from Level-3 or Level-2 and
5 from level-1A.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 12
Boehm mentions that for every 5 team members in at level 1A, agile teams need 2 engineers at level 2. Also, he
says that in large projects that involve new domain or new technology agile teams will require level 3 engineers.
With this discussion you can derive composition of an Agile team of 10 engineers.The understanding that we need all ‘Level-3’ engineers or ‘Level-2’
engineers in an agile team is a misinterpretation.
Obviously we need ‘quality’ and not just
‘quantity’ when we form teams. This is
because the quality of the team is very
important to produce high quality
software. However we do come across
high quality engineers at all levels,
irrespective of their experience. If Agile
Project Managers or Scrum Masters live
with this belief they can form successful
teams and reassure customers as well.
Agile teams are self-organizing teams. Agile team members need to have good communication skills and respect each
other in order to collaborate with business users. Also they need to believe in inspecting and adopting as they move
forward from iteration to iteration. It is necessary to demand technical excellence in Agile teams. Technical excellence is
not a one-time affair. It is a continuous journey. In this regard, Agile teams need to have the commitment to learn and the
courage to explore new technologies and domains.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 13
AGILE MYTH 6
Agile is for Product Engineering Only
SCRUM MASTER, SWEDEN
"Yes. I would say that it is a big misinterpretation. The company I'm working for are building and maintaining many IT systems and are using agile methods for this work. We are using practices from Scrum and XP and it works just fine. We have backlogs, work with Sprints, we are working and putting a lot of emphasis on architectural work etc. It works just fine."
IT PROFESSIONAL, US
"Scrum works well in many different environments and IT is no exception. However, IT situations are generally maintenance heavy & in that case a stripped down Agile methodology (such as Kanban) is probably better. However, for major system overhauls where management wants to have clarity into what's going on, Scrum is a great way to do that. Of course, if an IT project has one or two people in small settings, Scrum can be overkill no matter what."
PRODUCT OWNER, ISRAEL
“I believe the core principles of Scrum (or for that matter any agile process) can benefit an IT organization, especially as IT shops tend to have relatively outdated and inefficient development methodologies. However, in IT systems development, the actual users of the systems are members of the same organization, and so in principle should be more readily available for questioning and requirements validation. This should result in a higher degree of understanding of the requirements. Also, technical environments tend to be more stable and so the technological risk is also reduced. This means that the benefits of Scrum are not as great as in product development. It might not be worth the disruption to the organization's existing culture. Team leaders and systems analysts who have been doing the same job for ten years may not appreciate suddenly being made into Scrum masters and product owners. Therefore, it really depends on the specific organization and its culture."
These responses reassure that Agile is not specific to Product Development or Product Engineering. At MindTree, we do execute IT Services projects using Agile Methodologies such as Scrum.
"Is it a common misinterpretation that Agile Methodologies are suitable for Product Development only (but not for IT systems development)? What is your take on this?"
I had initiated this discussion in one of the internet forums and got very good responses. Let me share the excerpts from
three of these responses.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 14
AGILE MYTH 7
Changes Can Happen On a Daily Basis
Agile Manifesto values
‘Responding to Change’ over
‘Following a Plan’. This does not
mean that Agile manifesto
supports frequent or daily
changes. In fact, it indicates
that responding to changes is
more important than following a
plan. What does it mean?
When is the last time you executed a software project
with frozen requirements? A vast majority of projects we
execute do involve changes to requirements and
design. Quite often we accommodate our plans to suit
changing requirements and design. This does not mean
that we become highly flexible to absorb changes on a
daily basis.
Traditional methodologies consider upfront planning. Agile believes in just-enough planning because Agile teams
and stakeholders understand that change is inevitable.
In Agile projects, changes are monitored and controlled
at iteration level. After iteration planning, there must not be any change. If there is
any change, it has to be approved by project sponsors
at the highest level.
Too much of rigidity motivates us to complete all
originally signed-off requirements and consider
changes after project completion.
No stakeholder who has invested in a software
project will reward you or appreciate you for following
the original plan and failing to deliver valuable
software. So, we need the ability to embrace change
as we move forward and adjust our plans to deliver
value to business users or customers. How do we do
this in Agile? We do this by performing detailed
planning when we start an iteration or Sprint.
Meanwhile, we maintain a high-level project plan. This
helps us respond to changes as they progress.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 15
Also, such changes are possible only if there is a willingness to adjust the
scope in such a way that a user story of equal size (which is a popular measure
of change/impact in Agile) gets moved to a subsequent iteration.
So strictly speaking:
a) No changes are allowed after iteration planning. If
at all any change needs to be accommodated it
has to be approved not only by the Scrum Master
but also the Product Owner and Senior
Management.
b) If you introduce an approved change (of size x),
you need to move another feature or user story (of
size x) to a subsequent iteration.
Responding to change does not mean being reactive and highly flexible to
please the stakeholders. In real life, we come across the perils of
accommodating all change requests anytime during the project. This results in
effort overrun, quality degradation as well as team burn out. If this happens
for some reason, the best way is to discuss it during project retrospective and
find a solution.
Image Source: dilbert.com
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 16
AGILE MYTH 8
Agile is for Development Projects Only
Example
Continuous Integration, Coding
Standards, Code Quality/Static
Analysis, Unit Testing, Test
Automation, Project Manager
becoming a Coach or Mentor, etc,
were evangelized by Agile
practitioners. I think any project can
adopt all these practices. That will
improve results.
Maintenance or Sustenance projects can implement as many
Agile practices to improve the maturity of engineering
activities. Also, such projects can leverage some of the Agile
project management best practices (such as daily stand-up,
reviews and retrospectives) and reap benefits. Projects of other
categories (such as Testing or Production Support) can also
adopt Agile best practices.
We have applied Agile successfully in maintenance and testing
projects in our organization. We find that Agile adoption in is an
opportunity to improve both productivity and quality.
"You can use all agile some of the time and some agile all of the time."
Agile is not one specific way or one
significant way of doing things. There
can be different flavors of agile
projects where agile practices are
implemented with different intensities.
So, we need to understand that "You
can use all agile some of the time and
some agile all of the time."
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 17
AGILE MYTH 9
Agile impacts work-life balance
I heard this from a project
team couple of months
ago. Iteration after iteration
the team was struggling to
cope up with their
commitment to deliver. For
them ‘Agile’ meant not just
overtime but a lot of
overtime. One of the team
members commented that
the team was going through
never-ending fast pace
running.
When you are into never-
ending fast pace running it is
highly possible that you are
going to enervate and
collapse. If you don’t reflect
as a team, learn lessons and
implement continuous
improvement action plans,
you are not following ‘Agile’.
If you are going through work-life balance issues conduct a retrospective with your
team & try to answer the following questions.
Are all team members aligned to start productive work at a mutually agreed
upon start time every day?
Are there issues that prohibit the team from managing their time effectively?
Do team members participate in iteration planning and estimation meetings?
Is the team able to come up with better estimates as they progress from
iteration to iteration?
There are 12 Agile principles and the way we executed projects need to be aligned
with them. The eighth principle states:
The sponsors, developers and users should be able to maintain a constant pace indefinitely.
However, this does not imply consistent and extended overtime hours. I triggered
a discussion on ‘Agile and work-life balance’ in one of the external workshops. We
had participants from India as well as abroad. As a team we agreed that work-life
balance is not specific to ‘Agile’ and it happens because of:
1) Lack of effective planning & time management
2) Poor or inadequate estimation
3) Not having self-organized teams
4) Ineffective tools
5) Weak engineering practices
Do team members work as self-organized teams in order to improve efficiency?
Is the team wasting time because of slow or ineffective tools?
Are the engineering processes very weak so that the team spends lot of time in reactive quality management?
Is the customer supportive enough and listening to our feedback and concerns related to work-life balance?
Image Source: http://samingersoll.com
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 18
AGILE MYTH 10
Agile is Just Another Fad
Agile movement started 10 years ago. In a span
of less than 10 years, agile development has
become the preferred approach for many of the
leading technology companies. IT visionaries and
practitioners have embraced and promoted agile
development. Agile in distributed model has
started becoming an accepted way of software
development during the past 5 years.
A Forrester report titled ‘Offshore Outsourcing and Agile
Development’ published in September 2004 discusses about
the adoption of Agile in Offshore Outsourcing. Acceptance of
methodologies such as Scrum is a significant shift in the
industry over the recent years. It has been found that the
primary reasons of this shift are
a) the need to improve visibility and predictability in projects
b) ensure high quality and
c) enable customers competitive advantage with adequate
speed to market
In some cases agile practitioners create a lot
of buzz with terms such as ‘Daily Stand-up’
or ‘Planning Poker’ or ‘Retrospectives’. They
forget the essence of Agile.
They do not fine tune their approach to suit the context. This makes us feel that Agile is just another fad or fashion. If
you are in this situation, you need to collaborate with fellow practitioners through forums and communities to make sure
that your project implements agile in true spirit.
In the field of software engineering several things come and go. The foot prints or traces of some of them last long. An
interesting perspective on this is presented by Hugh Beyer in his blog “Agile is just a fad”. In this blog he says “Ten years
from now, I’m sure it will have been superseded by the Next Big Thing. But I’m equally sure that the core insights of
Agile development will have been built into the standard practice of the day. Those core insights will at least include
short iterations, each delivering a complete package; frequent validation of progress with customers and end-users;
and daily attention to process and to team interactions.” Also, do read Robert Galen’s blog “Kupe – Agile is NOT a Fad”.
Image Source: sweetshoppedesigns.com
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 19
AGILE MYTH 11
TDD is Enough to Ensure Software Quality
Test Driven Development
(TDD) is a technique used
by Agile teams. In IT
industry, there has been a
misunderstanding that TDD
is good enough to ensure
adequate software testing
in Agile projects.
When you ask, ‘How do Agile
teams do software testing?’
the answer you get is, ‘Agile
teams practice TDD.’ This is
a misleading answer that
sets an understanding that
TDD takes care of software
testing in Agile projects. This
is incorrect. Just doing TDD is
not enough. A variety of
testing techiques or practies
care required to assure
product quality.
TDD is a good technique. TDD helps Agile teams keep the source code clean. TDD addresses unit level defects.
TDD is not enough. A variety of testing techniques or practices are required to assure product quality.
Agile Manifesto or Agile Principles do not have any direct connotation to TDD. However, Agile teams need to
understand that importance of TDD. TDD improves agility. Hence, it is necessary for Agile teams to plan and
implement TDD. This can be done in small steps as shown in the picture above.
What is TDD? How Does it work?
Image Source: blogs.msdn.com
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 20
AGILE MYTH 12
A Chain of ‘Unit Tests’ is a Complete Regression Suite
Can you chain all Unit Tests in your project to
create Regression Tests or User Acceptance Tests?
First of all, it is not practical to cover every line of
source code in Unit Tests in all projects. Next, the
objective of regression testing is to ensure that any
change to the system does not result in
unexpected behavior. This is different from the
purpose of Unit Testing. In a unit test you focus
primarily on removing all expected defects in a
functional unit.
Thus creating regression test suite by reusing Unit
Tests is possible to some extent depending on the
technical architecture and life cycle activities of the
project. This is effectively explained in the 2
scenarious to the left.
Hence it is imperative to identify appropriate tools
and techniques for regression testing in addition to
leveraging Unit Tests.
TDD proponents emphasize that
every line of source code is
covered by a corresponding test
case. With this premise they
suggest that Unit Tests can be
leveraged or reused to create
Regression Tests, User
Acceptance Tests, etc.
Theoretically, it appears to be a
valid expectation. However it is
not realistic.
CONSIDER THE 2 SCENARIOS BELOW
If a project involves development of middleware
components or business logic only, it is possible to
reuse Unit Tests and build 80 to 90% of Regression
Tests. However, if a project involves development of
all layers (from UI to Data Access Layer
components) it may not be able to reuse Unit Tests
to build even 50% of all Regression Tests.
When you build a travel portal which involves not
only user interfaces but also integration with
external systems to provide and consume services,
you need to build a solid regression suite. Unit
Tests can help to some extent. You need to do a lot
more to make the regression suite effective.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 21
AGILE MYTH 13
Agile Doesn’t Allow Long-Term Planning
“Is it possible to use Agile for long-
term planning? How can a CIO or
CTO budget for the development of
an application or product in Agile
world?” Sounds familiar? Agile is
based on iterative & incremental
delivery. Hence there is a
misunderstanding in the industry
that agile does not allow for long-
term planning.
Release planning or defining a product roadmap can be done in ‘Agile’ way.
For long-term planning Agile teams create a product
backlog. This is done during ‘backlog grooming’
meetings.
During these meetings Agile teams not only create a product backlog but also
come up with estimates. This is a group exercise. The outcome of this
exercise is a collective decision. ‘What estimation technique do we use at
this stage?’ - Isn’t that your question? Let me provide you an answer.
Mike Cohn, the author of Agile Estimating and Planning has elaborated an
estimation technique based on Fibonacci sequence and this technique is
quite popular. This technique is implemented using a wide-band Delphi
estimation method called planning poker. This approach works well in
arriving at gross-level estimates at the time of backlog grooming meetings.
Agile teams can consider an average velocity (based on the average number
of story points delivered in an iteration or through a collective decision when
past data is not available) to derive quarterly schedule or forecast. In
practice, all team members participate in quarterly forecast (or release
forecast) meetings – of course, when the release cycle is one quarter.
Also, ‘Planning’ is not a one-time activity but a continuous one. Agile
organizations plan first and revisit their plans at regular intervals (every
month or every quarter) and are flexible enough to identify and implement
course corrections.
When the final release date is fixed,
agile teams can work backwards to
decide on the number of releases &
number of features or user stories per
release. Otherwise, teams can work
forward from iteration to iteration with
a decision on release cycles.
The outcome of this is approach is
nothing but an initial estimate on:
a) number of releases
b) number (as well as list) of user
stories identified for each release
c) total number of story points for all
releases. With this data, one can
arrive at high-level budgets.
So “Agile Doesn’t Allow for Long-term
Planning” is just a myth.
Image Source: mytechplan.com
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 22
AGILE MYTH 14
Agile Testing is All About Unit Testing, TDD, & Test Automation
Did you think that Unit
Testing, TDD and Test
Automation are sufficient to
perform application or
product testing in agile
projects?
If so then this write-up will
help you overcome this
myth.
Manual Testing is a critical aspect of agile project. This is because Unit Testing or Test Automation may not be feasible for certain scenarios or user
stories. Also, in general, Test Automation cannot replace Manual Testing.
CONSIDER THIS SCENARIO
It is critical to identify and fix bugs as early in
projects. The cost of defect fixing is multifold
when defects are found late in the cycle. This is
why it is important to focus on Unit Testing. Test
Driven Development is about writing test scripts
and executing them as you develop the program
units. Unit Testing, TDD and Test Automation
are very powerful and necessary. However, they
are not sufficient.
Understanding the scenario to the left, you will
realise that Unit Testing, TDD and Test Automation, if
implemented appropriately, do improve productivity
in agile projects.
Agile teams need to have a good understanding of
these concepts in order to reap the benefits.
Obviously, too much of Unit Testing, TDD or Test
Automation may not yield proportionate benefit
beyond a threshold. The graph below will make it
easier for our readers to understand.
AGILE COMMUNITY © MindTree 2011
AGILE MYTHS BUSTED 23
AGILE MYTH 15
In Agile Projects Process Compliance is a Big Issue
Process compliance is an opportunity to reap benefits in terms of increase in maturity of
engineering and project management processes. When we don’t do it right, it can
become a challenge or an issue. With reasonable awareness and mindset this challenge
can be overcome. This is true for Agile as well as traditional projects.
In almost all interactions during
my training sessions or
discussions I come across very
interesting questions on process
compliance. Last week someone
asked me asked, ‘What about
CMMi and Agile? Is process
compliance an issue in Agile
projects?’
Agile relies on ‘just enough’ when it comes to processes,
documentation, architecture or design.
Agile teams believe in simplicity - or the art of not doing
more that what is required. For example, Scrum processes
can be mapped to CMMi Level-3.
Unless we define processes that suit Agile projects, Agile
teams will find it impossible to adopt processes that are
designed for traditional way of doing Software Engineering.
We understand this fact. Our QF team is working on
process flows and assets that will suit Agile projects. The
final round of gap analysis and review is in progress. The
good news is that some of the Agile projects in both ITS and
PES are using these assets. You will hear more on this
from our QF function in a month or two.
With this note let me share a set of references with
you. These articles or papers provide an overview of
what is happening in the industry and how industry
leaders are suggesting Agile adoption with CMMi.
CMMi or Agile: Why not embrace both?
Implementing Scrum (Agile) and CMMi together
Implementing CMMi using a combination of Agile
methods
Agile Methods and CMMi: Compatibility or
Conflict?
Comparing Scrum and CMMi: How can they work
together?
Scrum and CMMi Level-5: The Magic Potion for
Code Warriors
Happy Reading !
Principles behind the Agile Manifesto agilemanifesto.org
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
For more details about Communities @ MindTree visit https://konnect.mindtree.com/communities
Recommended