Agile Development Methodology

The original version of this document was created and put into action by my friend and ninja, Azubuko (Buko) Obele while we worked at our first start-up. The document has since undergone some revisions as I've adopted it for my own purposes over time. This is an agile, iterative approach to product life-cycle management and it work in small and large firms alike. (Buko, you're a genius).

Processes and Methodologies

This document specifies recommendations for the software development process and the IT infrastructure strategy for developers and managers.

Overview

Philosophy

The intent of this document is to establish a foundation for development traditions and ultimately a company culture whose central philosphy of the development strategy is to maximize communication, collaboration, feedback and transparency. In doing so, the company will succeed in constructing an adaptive development infrastructure that can rapidly address changing business requirements and market realities.

Communication will ensure that the company's software and infrastructure development efforts are focused on addressing concrete business requirements.

Colaboration will allow the company to encapslate areas such as knowledge and distribution, reuse and automation, and proper allocation and management of resources. This will ensure productivity and efficiency.

Transparency will ensure that the company's development efforts are generating value and that risks are apparent.

Feedback will ensure that the development efforts are in fact meeting concrete business requirements and allow governence teams to understand the "current" situation and plan for the future.

Core Competency

Middle-tier vendors are moving into the forefront consolidating and standardizing services that may be purchased "off the shelf". This long list of solutions includes groupware solutions, Customer Resource Management (CRM) solutions, datasource abstraction tools, corporate communication tools, and enterprise-level SDKs and utilities among many. While it may "seem" easier to integrate vendor components, long-term customization and Quality of Service (QoS) costs may hinder the company's competitive edge. On the other hand there is no sense to "re-invent the wheel" especially when the middle-tier vendors have nearly perfected the services and components they sell.

Finally, it is always advantageous for the company to participate in IT Infrastructure Strategies mentorship and advisory programs offered by such industry leaders as the META Group, Inc.

Product Driven

Development Teams are encouraged to think in terms of "products" as opposed to "projects". A product is a deliverable with a well defined cost and risk and one that will create some well-defined value for the customer and company. A "product" should include all implementation, development, and operation costs of underlying infrustructure and application. The composite should be treated as part of the company's "portfolio". Tactical and Strategic methodologies will allow the company to effeciently grow and reassess the portfolio.

Tactical or "per-project" planning is conducted for each new application or infrustructure-driven project. The phases of Tactical planning are described as part of the Development Process section.

Strategic or "periodic" processes deal with periodic reassessment of the company's IT portflio, including Infrastructure Impact Assessment (IIA) and Prdictive Cost Modeling (PCM).

Agility and Velocity

The development process should capitalize on the company's energy and small size. The ability to quickly respond to evolving requirements and market conditions will allow the company to remain agile and adaptive. The ability to quickly initiate product development while sustaining a high, predicatble rate of development will allow the company to retain a high velocity. To accomplish this, the development process itself must follow "Agile" methodologies with a focus on Test-driven development while keeping unnecessary documentation and meetings to a minimum.

Risk Management

Enterprise-scale infrastructure deployment and large-scale software development is inherently a high-risk/high-rewards endeavor. Methodologies and processes must reduce risk whenever possible. Risk assessment must take complexity, time to market, and specific business-related value into account. Commitment to collaboration, communication, transparency and feedback will also help make high-risk scenarios manageable. Long-term projects with large iterations should be avoided as they tend to require large investments of time and resources and are inherently lacking in agility. It is recommended that focus is on test-driven development, continuous integration, short iterations to create immediate value and to produce tangible returns, centralization, and portfolio view of infrastructure patterns and services.

Development Process

Inception

The goal of the product inception phase is to identify and define the business problem. The result of the inception phase is a high-level description of the product's purpose and a non-exhaustive set of produt requirements. It should be clear from the onset who the product is used by, what "pain" the product should "cure" or "alleviate", what potential value the poduct brings to the company and in technology-neutral, abstract terms, what the product should do. How the product will work is irrelevant at this stage; only the Why and What matter. A product idea may only pass this phase if the risk is justified by value.

Business, Infrastructure, and Software development governance teams should be heavily involved in this process to present a holistic view of risk and reward. The deliverables of this phase should be (1) Meeting Notes and (2) Product Requisition Document (PRD).

Service Level Metrics, Feature Planning, Use Case Definition

The goal of this phase is to evaluate risk and to ultimately bring it under control. At this stage, the infrustructure planner should work with the product managers to define a potential solution and agree upon service levels. The product managers should describe a series of well-defined use cases and rate them in terms of risk. These use cases will describe the solution to the business problem from the application perspective.

Business specialists working with Software development management teams and Infrastructure planners should deliver a Feature Specification Document (FSD), Service Level Metrics Document (SLMD).

Development Planning

The primary goal of the stage is to bring the technical risks under control. Issues such as performance, scalability, reliability, and security should be addressed and metrics for product success should be established. The infrastructure planner should leverage as much existing infrastructure as possible, and infrastructure standards and processes where innovation allows. The planner should propose a blue-print for solving the business problem on the infrastructure level. Application management teams should define the solution in terms of application architecture. The infrastructure planner and application managers should collaborate to address technical risk and anticipate future risks and requirements. Application architecture and infrustructure architecture must address services, service level matrices, the complexity of the solution, estimated time to market and provide a model of projected costs. A basic prototype or other form of "proof-of-concept" should be used in a Test Lab setting to evaluate the doability of the proposed solution.

At this stage, the deliverables are a Release Plan (RP), Application Architecture Specification (AAS), Assemble Infrastructure Plan Draft (AIPD), and Predictive Cost Model Document (PCMD), Functional Prototype (optional).

Implementation

In this phase product development is borken down into a series of iteration cycles. The length of the iteration cycle will depend on the complexity and scope of the product. It is recommended that the iteration cycle be between two and four weeks in length.

This strategy puts concrete deliverables in the hands of customers who will inevitably provide invaluable feedback. The result of this kind of iterative loop is a quantifiable reduction of risk.

The deliverables are Iteration Plans and Checkpoints.

Release

A product is expected to transition through multiple "minor releases" before a "major release". Minor releases should occur frequently (at the discretion of product management). The purpose of any release is to determine of a set of risks has been successfully eliminated. Major releases will generally evaluate a much larger set of risks than Minor releases and will ultimately determine the success or failure of the product. Each release must be accompanied by a Release Contract in order to define and hold accountable every party involved in the release. The Release Contract must be approved by each party involved before the Release Conract is executed.

All functionality deemed in "alpha" or "beta" stages should adhere to release procedures as they will ultimately face some or all clients. Monitoring utilities should be enabled on live systems, customer feedback forms should be integrated into the product along with automated critical error/crash reports if possible. Feedback and system logs are envaluable in qualifying product performance in "live" environments.

Deliverables for this stage are Release Contract, Product, Product Evaluation

Deployment

Test-driven development requires continuous integration of code written by the development teams. Integration may take on the form of code merges within a Code Versioning repository (CVS) followed by deployment to Testing or Staging servers in the Test Lab. A "Release" is merely a deployment to "Live" (client-facing) environment with the assumption that the release passed all testing in the Testing Lab under live conditions. Deployments to Testing environments should occur frequently (on a daily or even bi-daily basis) by developers acting individually or in teams. Focus must be on unit, functinoal, and stress testing which for most cases, can be automated by easily atainable tools and utilities (JUnit, Cactus, etc.).

Testing will provide insights into the problem domain and expose architectural weaknesses in the infrastructure and the application forcing the management teams to revisit the planning stages. All "bugs", suggestions, and issues must be submitted to a task management application (JIRA) and resolving the riskiest ones should be a priority while the problem area is still "fresh".

Deliverables for this stage are Regression Testing Reports (RTR) as well as tuned Application Architecture Specification (AAS), Assemble Infrastructure Plan Draft (AIPD), and Predictive Cost Model (PCMD) documents.

original: Azubuko Obele
contributions: Yuriy Krylov