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