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 raja_bavani@mindtree.com 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 !

AGILE COMMUNITY © MindTree 2011

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