Yet Another Agile

Methodology
A simplistic approach to address most non-Agile
pain points

A whitepaper that helps you identify what approach to going

Agile suits you best

Ravi Warrier
ravi@raviwarrier.name
August, 2007
Based on my experience with projects, its teams and the customers and by doing a simple analysis of
what are the most common pain points of these three entities, I have come to an approach that can be
applied in the world of Offshore Contractual Software Development (OCSD). By OCSD, I mean all IT
companies in the world that provide services such as software development, testing, or maintenance of
existing systems to external customers that are not located in the same location (most commonly – in
another country).

I came up with this approach by simply collating a list of all the problems that the customer and the
vendor teams would want to do away with, thereby benefitting from its absence. I took the 6 most
common problem statements (and presumably the most troublesome) from the list to derive this
methodology.

The Six Most Common Pain Points (in no particular order):

1. Less or No Visibility / Lack of Effective Communication Mechanism: Customers often complain

that they have no clue of what happens in the projects they are sponsor. Project teams work in
silos and provide no or little information about the problems faced in the project or the
execution status. The customers also would prefer some visibility of the product during the
development cycle.
2. No Improvement in Processes: Project teams find it hard to change existing processes for the
lack of empirical data. Imbibing of good practices and avoidance of impediments would help the
project teams to plan and perform better; but existing methods to capture such information in
the organization is a painstaking task with (sometimes) heavy and subjective templates to be
filled.
3. Bloated Software: Most of the times both customers and vendors realize late in the stages of
development, that the features that are developed add no or little business value to the users.
At this point, customers (and sometime vendors) change requirements or chop features to make
the application lean. This results in hefty re-work and decreases the stability of the system.
4. Poor Quality: If this list was ordered in ascending ranks of problem statements, this one would
be on the top. While customers complain frequently on the poor quality of deliverables from
project teams, the project teams in turn blame inadequate time lines and frequent change
requests for this monster’s existence. Whatever the reason maybe, we might be able to salvage
this problem.
5. Effort and Schedule Overruns: Incorrect estimations, re-work (due to any reason) and
inconsistent planning are the usual culprits for effort and schedule overruns. Overruns such as
these cost vendors and customers up to 300% of the actual contractual obligations, averaging at
60% most of the times.
6. Ever Changing Requirements: Customers are meant to be finicky, but their nature causes many
projects to miss their quality, schedule or budgeted cost goals. If requirements can be frozen,
approximately 80-85% of projects would not fail to deliver as promised.
My concoction to reduce most head-aches
Based on the list I presented above, I created a hybrid process using practices of three different agile
methodologies. Here is the recipe of practices I recommend as “must have” with additional practices as
optional condiments.

Must Have Practices (Set One) – Increasing Visibility

Deliver Frequently (Also known as ‘Small Releases’ in Extreme Programming and ‘Frequent Delivery of
Products’ in DSDM).
This practices suggests that you have frequent releases of “potentially shippable software” that allows
the customers to see gradual (and incremental) progress during the execution of the project. The
frequency is suggested to be between 1 – 4 weeks in length and at the end of every such period some
functional piece of software must be delivered or demonstrated to the customer.
This is possible with the adoption of iterative and incremental development approach.
The frequency at which release are made also depends on the volatility of requirements. Higher the rate
of change requests, shorter should be the duration.

Optional Practice
Whole Team – Extreme Programming (Also known as ‘Active User Involvement’ in DSDM)
This practice involves not only the project team members, but also Customer teams and End Users in an
active dialog to verify and validate the progress.

Must Have Practices (Set Two) – Improve Processes

Daily Scrums, Sprint Retrospectives – Scrum (Also known as ‘Continuous Improvement’ in Extreme
Programming)
The purpose of this practices is to communicate – ‘What works’ and ‘What Could Work Better’.
Daily Scrums are internal team meetings where the team members inform each other on task updates
and problems they faced. Sprint Retrospectives are done at the end of iterations to identify good
practices and problems that can be avoided in future sprints. Thereby, fine tuning existing processes to
work better.

Must Have Practice (Set Three) – Right Features for Best Business Value

Design Improvements & Simple Design – Extreme Programming, Fitness for Purpose (DSDM)
Constant design improvements during the life cycle of the project help identify unnecessary
functionality and also prioritize features that would result in higher ROIs for the customer. Weeding out
dead weight from the project will result also in higher productivity and better quality.
This can be done as a part of planning or retrospective meetings by the team involving the customers
and end users. Demos at the end of iterations also help the customer/end users to realize what is
important to them and what is not.
Must Have Practices (Set Four) – Increasing Quality

Code Standard – Extreme Programming, Continuous Testing – Extreme Programming (Also known as
‘Integrated Testing’ in DSDM)
Defining Coding Standards and Guidelines for project teams to follow will help in standardizing and
maintaining the quality of code. Practices such as continuous testing allow project teams to identify
defects early on during the development compared to the late detection of defects as in the Waterfall
model.

Optional Practice
Pair Programming – Extreme Programming
Another method of organizing development teams is to pair programmers to work together on the same
piece of work on one terminal that is shared between the two. One writes the code (called the driver),
while the other one reviews it in parallel (called the navigator). The pair takes turns in playing each role.
This pair is also rotated on other tasks. Two of the primary advantages of this practice are that two
minds work on the same code resulting in better logic and the fact the code is reviewed as it is written,
resulting in better code sooner.

Must Have Practices (Set Five) – Sticking to Planned Effort and Schedules

Planning Game – Extreme Programming (Also known as ‘Planning Poker’ in Scrum)

Sustainable Pace – Extreme Programming
As per agile practices, the estimation for effort and scheduling needs to be done by the project team
and not managers or customers. The team will based on their experience suggest the amount of effort
and time that it will take to carry out tasks. This leads to a stronger commitment from the team and
increases their productivity since they now have full responsibility and accountability of sticking to their
commitments.
Sustainable Pace suggests that the team work at a sustained pace through the project (for e.g. 40
hours/week) and avoid spikes in effort to meet deadlines. Planning that is carried out keeping in mind
this practice is more effective and realistic.

Optional Practices
Self Organizing/Managing Teams – Scrum (Also known as ‘Empowered Teams’ in DSDM)
Giving the team the responsibility of planning and estimating may not be enough. It is advisable that the
team is also empowered to meet their commitments. Hence, having a self managed team proves
beneficial to the project.

Generating Burn-down Charts – Scrum

A burn-down chart reflects on the progress the team has made so far in the iteration. It is a graphical
representation of the current velocity of execution of the team versus a steady pace. This allows the
team to visualize the amount of work remaining and hence move things to a higher gear.
Must Have Practices (Set Six) – Stabilizing Requirements

Product Backlog – Scrum (Also known as ‘Base-lining Requirements at a High Level’ in DSDM)
Sprint Backlog – Scrum
A Product Backlog is a list of all functional and non-functional requirements of the project. It may also
include tasks that need to be carried out to clear impediments or resolve dependencies. Having a
product backlog allows the team to see a larger picture, though only the requirements that will go into
immediate production need to be detailed.
A Sprint Backlog on the other hand is a sub-set of the Product Backlog and contains only those
requirements/tasks that the team is undertaking for the current iteration.
While the iteration is in progress, the customer (Product Owner) is free to modify all product backlog
items except those that have moved to the sprint backlog.
As mentioned above in practices set one, if the requirements volatility is high, then it is better to have
shorter durations for iterations.

As you might have noticed, even though the practices are categorized as per the problem statement it
immediately solves, it also would help reducing or eliminating other problem which might not figure in
the List of Six.

Disclaimer
These practices have been borrowed from various agile methodologies, but each of these
methodologies has more practices that it suggests implementation. And since, we do not in this
concoction of practices implement all practices of a particular methodology; we should not claim to be
practicing that methodology. However, by taking a dose of this mix, you can claim to be “agile”.
All credit for defining the above practices go to organizations of respective agile methodologies. But
however, I take full credit for this tangy cocktail!