Agile Implementation

Entering a New World

What exactly is Agile? What does it mean and stand for?

Read more…

Ravi Warrier
ravi@raviwarrier.name
August, 2007
Introduction
The intent of this document is to help readers understand “Agile methods” and how to change the
philosophies of existing traditional software development and align them to the agile movement.

While the agenda of the agile movement is clearly defined by various groups in terms of values’,
principles’ and practices’ definition; it is not very clear with respect to selecting the right approach to
adopt.

This document will try and propose an objective approach to decide what the right agile methodology
for your organization is.

Creating a Model

Practice(s)

Principle(s)

Value(s)

Intent

Figure 1: Evolution

Identifying the Intent

As with any paradigm shift, the first task is to understand the reason for the shift. It could be just one or
a matrix of reasons that would make an organization or project teams want to change the way they
work. Irrespective of the count, it is important to go deep into these reasons since these reasons will
further down model the approach that is best suited to the execution of the project.

The way to do this is similar to a typical task of analyzing business or delivery problems. One needs to
identify what are the key areas that raise most concerns. Categorizing them into buckets such as
‘Customer Satisfaction’, ‘Requirements Management’, ‘Quality of Deliverables’, ‘Meeting Deadlines’, etc
helps.
Asking the right questions is really important here as without the direction the questions (and answers
to them) provide, narrowing down and coming up with key problems would become a difficult
endeavor.

These questions might help you gain perspective:

• How many times has this problem occurred (in a defined period)?
• Has this problem caused us to stop on or deviate significantly from our proposed path?
• How much has this problem cost us (quantified as money units)?
• Is this problem likely to occur again?
• What is the real cause of this problem?
• Is it something we can fix?

Based on the answers to the above questions, you will be able to judge which of the problems have
been a real pain in the neck for your project(s). By doing this exercise, you will also realize the root cause
of the problem, which in turn becomes one of the intent (key reasons) that attribute to the need to
adopt an existing delivery model or create a new one.

Identify the Right Values

Agile values define the beliefs that are most important for developing software. In brief, these strongly
correlate to the four-fold philosophy of the Agile Manifesto:

 Individuals and interactions over processes and tools (value: communication),

 Working software over comprehensive documentation (value: simplicity),
 Customer collaboration over contract negotiation (value: feedback) and
 Responding to change over following a plan (value: courage).

All the intents identified earlier can be attributed to one of the values that are mentioned above. And
each agile value has a set of principles and practices that extend it.

Selecting Principles
This is the easy part of this tumultuous journey. It’s a straight road ahead until the next bend.

Agile Manifesto has laid down 12 principles 1 based on the four philosophies (or values) mentioned
above. Each of the twelve principles may satisfy one or more values. And it is not rocket science to map
each of the principles to related values. For example, the following principles satisfy (either directly or
not) the agile value “Communication”. Remember, this can be entirely different based on your
experiences.

1
See Appendix A
Table 1

Agile Value Agile Principles

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

Principles are meant to have deeper underlying meaning which can of course be implied in satisfying
more than one value.

Choosing the right methodology or creating a new one for yourself

A lot of software development methods have been defined over the last many years. The list includes:

• Extreme Programming (XP)

• Scrum
• Feature Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development (ASD)
• Agile RUP
• Crystal Family of Methodologies (Crystal)
• Lean Software Development (LSD)
• XBreed
• Internet Speed Development (ISD)
• Agile Modeling (AM)
• Pragmatic Programming (PP) and
• Many more are added to the list as we speak

Each of these methodologies has defined a set of practices 2 dependent on the four agile values. Based
on the values that are important to your software development projects, you may choose to inherit and
practice what has been laid down by the methods listed above.

Or you might want to create a hybrid method on your own based on these practices or the ones defined
by you. Either approach is fine. But there are a few things that you would need to know while creating a
hybrid method for yourself.

2
See Appendix B for list of practices for Scrum, XP and DSDM
Each of the methods listed above satisfy all the four values of the
agile manifesto. What you need to consider when you implement
only a few of the practices of any methodology, is that while you

AGILE
are free to adopt selectively, you might not earn the
acknowledgement of adopting the method. For e.g., if you partially
practice XP, leaving out practices that do not cater to solving your
problems; you cannot claim to be executing XP projects.

Likewise, if your hybrid method does not satisfy all the four values
of agile manifesto, then to claim your method as an “agile
method” would be wrong.

While you have a choice of practices/methodologies to select from, the agile values are not on a platter
to choose from. It is all or nothing. In-betweens are your choice too, but then it cannot be called “agile”.

Implementing the Model

Once you have selected or created the model(s) that you wish to incorporate as your organization’s
software development method, you have to set it into motion.
This is very much like driving your car for the first time as a teenager. You need to be cautious and
meticulous of the things that you do, lest you jerk or bang into an innocent bystander.

These are a few things that I’d suggest on your first venture into this new world of agile software
development.

Identify a committed team

If this is a pilot that you are doing, I’d suggest that you ask for volunteers within the organization to be a
part of an agile team. Forcing something new down people’s throats will result in a higher chance of
failures. Ask people to step forward. Give them assurance that this project is a pilot and the failure of
which will not result in individual’s appraisal. Give adequate training on the new process to the ones
who have volunteered and once again ask them if they want to still be on the agile team. The ones who
say “Yes” will be committed enough to the cause.

Make sure that the team is well balanced in terms of experience and skills. A cross-functional team with
varied levels of experience works best.

Select a non-critical project

Do not select a critical project. Adopting agile values and practices takes time and the team will need
breathing space to slowly mould itself to the changing development environment. Having a pilot on a
critical project will tend to pressurize the team on deliverables which will leave no time for the change
required.

Most pilots fail due to the fact that these practices are new to people and that they have to change
years of mindset which might not be easy at times. In such a case, you do not want a critical project as a
guinea pig for your experiments.
Give the team a breather
Do not breathe down the necks of team members of a pilot agile project. In fact, do not do this even
with the experienced teams. One of the core practices of agile is to have a self-organizing/managing
team. Don’t ask for daily or lengthy reports which will move the focus from development activities to
‘pleasing the management’ activities.

Do not strike out early

Changing to a newer development method will tend to fail initially due to a variety of reasons. Do not
strike out agile, just because the pilot failed. Instead, retrospect on why it failed and try again.

Another side to this coin (if you fail all the time) maybe to introspect and re-evaluate your need to go
agile or the method (especially if it is self-concocted) you are implementing. You might not have
selected the right methodology or set of practices.

If after everything it still fails, you might want to dawn on a realization that agile might not be for you.

Inspect the adoption periodically

Keep inspecting the process periodically during the pilot; but do not do it so frequently that it
undermines the values of agile. The purpose of this inspection is to visualize break downs early on and
getting heads up on fixing issues before or as soon as they occur.

Evolving the model(s)

One of the key attributes of agile is continuous improvement. Once you have had successful pilots and
have rolled out the new paradigm of software development to the entire organization; you will need to
improve and evolve your processes. Repeat the activities stated in the article to find newer problems to
solve and newer practices that can be implemented to solve them.

Conclusion
Understanding agile or various methods based on it is not difficult. Implementing practices laid down by
such methods have their own complexities, but even that is not difficult. The most difficult part of
shifting is figuring out what works for you and how to start implementing it – paving the actual path.
Once the road is paved in the right direction, driving down it is never that big a problem.
Appendix A

Twelve Principles of Agile Manifesto

• 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 time scale.
• 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.
Appendix B
Practices of Scrum, XP and DSDM
Scrum
Self Organizing Teams
Deliver Frequently
Plan to Learn (Retrospect)
Communicate Strongly
Test Everything
Measure
Clear the Path
Extreme Programming (XP) Dynamic Systems Development
Method (DSDM)
Small Releases Active User Involvement
Continuous Improvement Empowered Teams
Test Driven Development Frequent Delivery
Planning Game Fitness of purpose
Whole Team Iterative and Incremental
Development
Pair Programming Reversible Changes
Design Improvements Base-lining of High Level
Requirements
Simple Design Integrated Testing throughout
the lifecycle
System Metaphor Collaborative/Co-operative
approach between all
stakeholders
Collective Code Ownership
Coding Standards
Sustainable Pace