Page 1

Agile Community | MindTree

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.


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

M

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

i


AGILE COMMUNITY © MindTree 2011

Shadab: Tell us why Agile is still misunderstood despite

Shadab: How do you think people should adopt Agile

being in existence over the last 10 years?

Methodology in their projects?

Raja: There are two primary reasons. The first reason is

Raja: Agile Software Development in a distributed

the evolution of Agile itself. This evolution involved a

environment does not mean step-by-step

cultural transformation in the industry from the

implementation of any specific agile methodology such

traditional way of creating and maintaining software to

as Scrum with high expectations on on-time high-quality

the evolutionary way. During February 2001, 17

delivery. It means collaboration among distributed

methodology experts convened at ‘The Lodge’ at

teams to collate processes that follow agile principles

Snowbird Ski Resort in the Wasatch Mountains of Utah

and to put together a methodology that works for them.

and defined ‘Agile Manifesto’ and ‘Agile Principles’.

Projects that follow distributed agile suffer when a

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.

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

Shadab: Ok. On a different note if we see the trend it

collaboration. Agile projects need team members who

was Waterfall earlier & now Agile way of software

are self-motivated and leaders by themselves. Agile

development, what will be next?

teams need to be self-organized. In order to become

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

self-organized, team members need to imbibe values such as commitment, openness, focus, respect, courage, simplicity, feedback and integrity.

up with statements on how things can be done better in

I have attempted to provide a message or two in each of

future. I have narrated this in my Konnect blog, ‘The

these myths or misinterpretations. Besides, I strongly

Future of Agile’.

believe that agile team members need to understand

In future, there will be new ideas and approaches. However the fundamental principles will remain the

the applicability and essence of what they do and how they do what they do.

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.

ii


Agile Myths 1.

Take The Waterfall Model and Add One Arrow

2

2.

Agile means 'Start Coding With No Documentation'

3.

Agile means 'Ad Hoc' or 'No Processes'

4.

Agile means 'No Planning'

5.

Agile Team Members Must be Super Stars

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

10.

Agile is Just Another Fad

11.

TDD is Enough to Ensure Software Quality

12.

A Chain of Unit Tests is a Complete Regression Suite

13.

Agile Doesn’t Allow for Long-Term Planning

14.

Agile Testing is All About Unit Testing, TDD, and Test Automation

15.

In Agile Projects Process Compliance is a Big Issue

4

6

8 10

17

18 19 20

21 22

23 Image source: geekherocomic.com


AGILE COMMUNITY © MindTree 2011

AGILE MYTH 1

Take The Waterfall Model and Add One Arrow

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?

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.

AGILE MYTHS BUSTED

2


AGILE COMMUNITY © MindTree 2011

There is a serious issue in visualizing Agile as a series of

1)

Adherence to Coding Standards & Usage of Code Quality Tools (Eg. Code XRay)

tiny waterfalls. To understand this issue read “The Pipelining Anti-Pattern” and understand what it is

2)

Automated Unit Tests

about. Agile Software Development is based on ‘Agile

3)

Automated Build

Manifesto’ and ‘Agile Principles’. You will find link to

4)

Continuous Build/Integration

these in my blog ‘The Future of Agile Manifesto’.

5)

Test Automation

6)

Test Driven Development (TDD)

7)

Refactoring

Agile Software Development is about early and frequent delivery of

Our Agile Community has a very good document repository that includes white papers, articles and

working software at regular

presentations on Agile on our social intranet – Konnect –

intervals in a sustainable pace.

platform. I encourage our community members to read

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.

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.

Agile is about delivering business value to customer and

One way of learning & getting insights is through myths

requires a great deal of focus and discipline.

and misinterpretations too! Why not?

In order to accomplish these agile teams follow several engineering best practices. Some of them are:

AGILE MYTHS BUSTED

3


AGILE COMMUNITY © MindTree 2011

AGILE MYTH 2 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?”

Agile means Start Coding With No Documentation CONSIDER THIS In Agile projects customers or business users and software engineers sit together. Business users tell the requirements & developers

Image Source: dilbert.com

write code. They do not do any

Agile Manifesto values working software over

documentation. The dev team

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.

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

Agile discourages any document that is going to be read only by the creator and

that this approach does not

reviewer. In my experience, I have seen project teams that create document for

work for products or

anything and everything. I call them 'Document Driven Teams'. In one such

applications offered to a wide

instance, I came across a document that had 7 pages out of which the relevant

range of customers.

content was only 2 pages

AGILE MYTHS BUSTED

4


AGILE COMMUNITY © MindTree 2011

“In one such instance, I came across a document that

CONSIDER THIS ONE TOO In projects that follow

had 7 pages out of which the relevant content was only 2 pages …

traditional approaches project

teams create UI design document by pasting all

… Everything else was the pre-filled document template with title, logo, table of

screen shots and providing

contents etc., If any software professional is feeling good about creating a

some description for each of

document like this by spending several hours & if that document is not going to

them. As the product or

be read by anyone in future, then there is no value in creating such a document.

application goes through development phase, plenty of

Agile Emphasizes on Understanding the True Value of Any

UI changes happen. However

Document Before Creating It.

the UI design or screen design document does not

On the other hand, it is not wise to execute projects with undocumented

get updated and hence

requirements or designs. Executing software projects with no documentation can

becomes obsolete. Agile

lead to disastrous situations.

teams do not create such documents. Instead they check-in HTML wireframes in the configuration

So, what do we do in Agile projects?

management system. If user manual or UI design

We create any document only when:

document is one of the

a)

it is necessary

deliverables, agile teams

b)

we are sure that it is going to be used by several team members in the

create these when the

project

application or product is

c)

we can ensure that it will be kept up-to-date

stable enough.

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 Promotes Face-To-Face Communication and Collaboration.

AGILE MYTHS BUSTED

5


AGILE COMMUNITY © MindTree 2011

AGILE MYTH 3

Agile means Ad Hoc or No Processes

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-whateverfeels-good’. Agile does not mean ‘hacking’ or not following any processes. Image source: http://www.glommer.net/blogs/?p=189

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

On engineering perspective you do follow processes

project goals. For example, if you follow Scrum, which is

related to query tracking, reviews, testing etc. Obviously

one among the popular Agile methodologies,

as you would see working in an Agile project does not

-

you attend Scrum Planning meetings

mean that you can avoid or evade from process

-

you follow estimation process

compliance. So which means if you introduce heavy

-

you track efforts

weight processes you can’t move swiftly.

-

you monitor impediments or issues, and

-

at the end you capture best practices, areas of

Thus you need right-weight processes.

improvement by conducting retrospectives. AGILE MYTHS BUSTED

6


AGILE COMMUNITY © MindTree 2011

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.

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?’

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.

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 MYTHS BUSTED

7


AGILE COMMUNITY © MindTree 2011

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.

Image Source: enagility.com

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

Traditional methodologies consider upfront planning. Agile believes in just-enough planning because Agile teams and stakeholders understand that change is inevitable.

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 highlevel project plan. This helps us respond to changes as they progress.

AGILE MYTHS BUSTED

8


AGILE COMMUNITY Š MindTree 2011

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. Image Source: thehindu.com

(B) On the otherhand, too much of upfront planning leads to situations such as huge investments in infrastructure that becomes a dead investment.

Image Source: chessinthesnow.blogspot.com

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.

AGILE MYTHS BUSTED

9


AGILE COMMUNITY © MindTree 2011

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.

The first & the most important value outlined in Agile Manifesto is ‘Individuals and Interactions’ over ‘Process and Tools’. Also, 7 out of 12 Agile Principles talk about teams & team members. These 7 principles are: 

left, provides guidelines or

throughout the project.

directives on considering

Principle-5: Build projects around motivated individuals. Give them

only super performers to

the environment and support they need, and trust them to get the job

form agile teams.

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.

you can see towards the

Principle-4: Business people and developers must work together daily

done. 

None of these principles, as

Principle-12: At regular intervals, the team reflects on how to become

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.

more effective, then tunes and adjusts its behavior accordingly.

AGILE MYTHS BUSTED

10


AGILE COMMUNITY © MindTree 2011

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

Shu

Ha

Ri

Level-1 (Shu) - Team members who can learn and perform. Level-2 (Ha) - Team members who have learned techniques. They keep collecting

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 that suit a context and apply

techniques.

Based on these 3 stages he categorizes team

them. They have the capability to tailor a

members into the following three levels.

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 MYTHS BUSTED

11


AGILE COMMUNITY © MindTree 2011

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 MYTHS BUSTED

12


AGILE COMMUNITY Š MindTree 2011

AGILE MYTH 6

Agile is for Product Engineering Only "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.

SCRUM MASTER, SWEDEN

IT PROFESSIONAL, US

"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."

"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.

AGILE MYTHS BUSTED

13


AGILE COMMUNITY © MindTree 2011

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 Too much of rigidity motivates us to complete all originally signed-off requirements and consider changes after project completion.

upfront planning. Agile believes in justenough planning because Agile teams and stakeholders understand that change is inevitable.

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

In Agile projects, changes are monitored and controlled

as we move forward and adjust our plans to deliver

at iteration level. After

value to business users or customers. How do we do

there must not be any change. If there is

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

iteration planning,

any change, it has to be approved by project sponsors at the highest level.

helps us respond to changes as they progress.

AGILE MYTHS BUSTED

14


AGILE COMMUNITY Š MindTree 2011

Image Source: dilbert.com

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.

AGILE MYTHS BUSTED

15


AGILE COMMUNITY Š MindTree 2011

AGILE MYTH 8

Agile is for Development Projects Only

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."

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

"You can use all agile some

project management best practices (such as daily stand-up, reviews and retrospectives) and reap benefits. Projects of other

of the time and some agile

categories (such as Testing or Production Support) can also

all of the time."

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.

AGILE MYTHS BUSTED

16


AGILE COMMUNITY © MindTree 2011

AGILE MYTH 9

Agile impacts work-life balance Image Source: http://samingersoll.com

There are 12 Agile principles and the way we executed projects need to be aligned

I heard this from a project

with them. The eighth principle states:

team couple of months ago. Iteration after iteration

The sponsors, developers and users should be able to

the team was struggling to

maintain a constant pace indefinitely.

cope up with their

However, this does not imply consistent and extended overtime hours. I triggered

them ‘Agile’ meant not just

a discussion on ‘Agile and work-life balance’ in one of the external workshops. We

overtime but a lot of

had participants from India as well as abroad. As a team we agreed that work-life

overtime. One of the team

balance is not specific to ‘Agile’ and it happens because of:

members commented that

commitment to deliver. For

the team was going through 1)

Lack of effective planning & time management

never-ending fast pace

2)

Poor or inadequate estimation

running.

3)

Not having self-organized teams

4)

Ineffective tools

When you are into never-

5)

Weak engineering practices

ending fast pace running it is highly possible that you are

If you are going through work-life balance issues conduct a retrospective with your

going to enervate and

team & try to answer the following questions.

collapse. If you don’t reflect

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

as a team, learn lessons and implement continuous improvement action plans, you are not following ‘Agile’.

iteration to iteration? 

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?

AGILE MYTHS BUSTED

17


AGILE COMMUNITY © MindTree 2011

AGILE MYTH 10

Agile movement started 10 years ago. In a span of less than 10 years, agile development has

Agile is Just Another Fad

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. Image Source: sweetshoppedesigns.com

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”.

AGILE MYTHS BUSTED

18


AGILE COMMUNITY © MindTree 2011

AGILE MYTH 11

TDD is Enough to Ensure Software Quality When you ask, ‘How do Agile

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.

Wha t is TDD? How Does it work?

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.

Image Source: blogs.msdn.com

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.

AGILE MYTHS BUSTED

19


AGILE COMMUNITY © MindTree 2011

AGILE MYTH 12

A Chain of ‘Unit Tests’ is a Complete Regression Suite 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.

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.

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.

AGILE MYTHS BUSTED

20


AGILE COMMUNITY © MindTree 2011

AGILE MYTH 13 “Is it possible to use Agile for long-

Agile Doesn’t Allow Long-Term Planning

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 longterm 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.

Image Source: mytechplan.com

When the final release date is fixed,

Mike Cohn, the author of Agile Estimating and Planning has elaborated an

agile teams can work backwards to

estimation technique based on Fibonacci sequence and this technique is

decide on the number of releases &

quite popular. This technique is implemented using a wide-band Delphi

number of features or user stories per

estimation method called planning poker. This approach works well in

release. Otherwise, teams can work

arriving at gross-level estimates at the time of backlog grooming meetings.

forward from iteration to iteration with a decision on release cycles.

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

The outcome of this is approach is

past data is not available) to derive quarterly schedule or forecast. In

nothing but an initial estimate on:

practice, all team members participate in quarterly forecast (or release

a) number of releases

forecast) meetings – of course, when the release cycle is one quarter.

b) number (as well as list) of user stories identified for each release

Also, ‘Planning’ is not a one-time activity but a continuous one. Agile

c)

total number of story points for all

organizations plan first and revisit their plans at regular intervals (every

releases. With this data, one can

month or every quarter) and are flexible enough to identify and implement

arrive at high-level budgets.

course corrections.

So “Agile Doesn’t Allow for Long-term Planning” is just a myth.

AGILE MYTHS BUSTED

21


AGILE COMMUNITY Š MindTree 2011

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

Agile teams need to have a good understanding of these concepts in order to reap the benefits.

It is critical to identify and fix bugs as early in

Obviously, too much of Unit Testing, TDD or Test

projects. The cost of defect fixing is multifold

Automation may not yield proportionate benefit

when defects are found late in the cycle. This is

beyond a threshold. The graph below will make it

why it is important to focus on Unit Testing. Test

easier for our readers to understand.

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 MYTHS BUSTED

22


AGILE COMMUNITY © MindTree 2011

AGILE MYTH 15

In Agile Projects Process Compliance is a Big Issue

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?’

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.

Agile relies on ‘just enough’ when it comes to processes,

With this note let me share a set of references with

documentation, architecture or design.

you. These articles or papers provide an overview of what is happening in the industry and how industry

Agile teams believe in simplicity - or the art of not doing

leaders are suggesting Agile adoption with CMMi.

more that what is required. For example, Scrum processes can be mapped to CMMi Level-3.

 CMMi or Agile: Why not embrace both?  Implementing Scrum (Agile) and CMMi together

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.

 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 MYTHS BUSTED

23


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

Agile Myths Busted For Web  

Raja Bavani is a staunch Agile practitioner, an evangelist and a community champion. He shares his experience with Shadab Lari on 15 myths t...

Read more
Read more
Similar to
Popular now
Just for you