Agile Methodology – An Introduction

Conventionally, it is a contradiction to mention ‘Agile’ in the same sentence as ‘Fixed’. The Agile method of software development is founded on the need for continuous change that modern software systems must go through to adapt to changing consumer needs.

In the real world while software requirement (i.e., scope) is changeable, time to market and cost allocated are not. Software development in such a scenario presents significant challenges in defining the project and tweaking the methodology to meet the need.

E.g., consider the case of an analytic system for capturing and reacting to online consumer behavior. In such a case, the software continuously needs to adapt to new consumer behavior patterns as they emerge. How do you predict budgets and timelines for building a suitable and complete system for such dynamic scenarios?

This is especially a challenge for a product engineering vendor, who is often asked to deliver against continuous change while staying within the budgets assigned to the development project. The challenge for a service provider is to project a budget and keep to it while assimilating change.

In practice, assessing the problem critically and answering questions like the ones below help identify the constants and the variables in the problem domain and operating environment.

• Are the results (business and technology objectives) of the project well-defined?
• Are the target users well-profiled?
• Are you developing a new product, or enhancing an existing one?
• Is the recommended technology stack stable?
• Are there organizational or industry experiences and metrics available to predict the standard velocity of development?
• Is there a need to deliver a rich user experience and will that change with feedback from the market?
• Are you developing a generally available internet application?
• Is user behavior pattern a key determinant of business logic?
• Do you expect diverse sources of data – with unstructured or variously structured data?
• Does the product domain and competitor landscape require continuous feature enhancement?

The above is only a starting list of questions and usually needs to be expanded while exploring any new Agile development opportunity. Then there is a need to work with product managers, architects, and business stakeholders and try to answer them. The attempt is to understand the size of the current backlog, the expected velocity of development, and the rate at which the problem domain and technology are changing and use these factors to estimate team size and timelines.

Further, while consulting a customer on Agile development in a fixed price model, the following 7 Practices are a must –

• Understand the problem domain well
• Define and prioritize the product backlog to the extent possible
• Identify which items in the backlog may be ‘exchanged’ with higher priority requirements received during development.
• Get user stories defined as cleanly as possible
• Project the team’s expected velocity from experience and available metrics
• Identify possible causes and probability of change during the project, and quantify the extent of the impact.
• Have buy-in from all stakeholders on a continuously collaborative give & take of backlog and prioritization.

With the above in place, projecting budgets and timelines with greater accuracy becomes possible; and it is easier to define and stick to allocated budgets and still succeed in delivering the Business and Technology goals of the project while going Agile Methodology.