The term Agile refers to a family of methodologies including; Extreme Programming, Lean, Scrum, etc. According to the latest industry data, Scrum enjoys the largest market share at 49.1% (Version One "The State of Agile Development" 3rd Annual Survey: 2008). Each methodology has its own unique differences, however all Agile methodologies share the following characteristics:
• Develop the highest value features first
• Short iterations, frequent releases
• Fixed resources and time, scope remains variable
• High visibility, high bandwidth communication (aka face-to-face)
• Small cross-functional, self-managing teams
• Inspecting and adapting (continuous improvement)
Common Potential Pitfalls
- Customer understanding of the agile process:
- The need to review and provide feedback after each development iteration
- Availability of resources for review after each development iteration
- Scope Creep (expansion of software functionality is common request)
- Realistic iteration milestones
- Customer communication
Agile Development is People driven instead of process or plan driven; the aspect of the project is managed by people in colaburation, which include: Scope, Requirements, Risk, Change, Quality.
Scope - Identifies high level vision, deliverables, expectation and what is out of scope. All Team Members must be aware of the scope and in agreement. All Team members needs to have the skills to be an expert in business domain; unlike in classic process mode, for example business analyst might be the only be member expected to be the domain expert.
Requirements - Details scenarios of what the software should do fromt he user or customer perspective. In a non agile process driven project requirement gathering could be very time consuming process involving analyst, user interface expect, engaged lenghty meeting with business stake holders. For example in a more process driven approach a business analyst will often prepare a highly detail requirement document, while user interface expect creates pixel perfect ui wire frames which are then followed by complex design and architectual documents created by development team, all must enter a formal approval process, which dould take weeks and month before coding/development can start.
Gathering requirements on an Agile project should typically not involve a long time consuming series of process and documentation. The developer should have a face to face meeting with product stake holders and document only what is necessary to get working code back to the business stake holder or customer by breaking the work into small iterations, possible as small as one week. For instance in a project with many user screen and reports, an iteration might be delivery of one single report. Using Agile a developer sitting in front of a business stake holders can sketch out use cases and activity diagrams along with notes of the work needed to be done, once understanding is reach coding can begin with a few skitches.
In a non Agile enviroment change management can be very long process and costly; can be initiated by anyone on the team who notices that something is missing or incorrectly specified the change may need to go to a change board committe to determine if the appropriate fix within scope and project goals. Then change may need to be estimated to show the potential changes to the budget and the schedule, after this estimation another approval might be necessary since it maybe determined to be cost is prohibited to make the change. After all these have occured requirement and scope document will need to be updated, design document changed, test and code re-written. For these reasons change is seen as the enemy to progress in a plan driven projects to have demanding proceess and deep detail documentation because they very often add to the scope of the project. Also management might have a hardtime accepting the change to the final delivery date so development team maybe asked to observe the additional work and still deliver original date and this will negative add to team moral.
Quality - is how well the software does and is expected to do, how free it is from bugs.
Agile Team work closely together, in the best case scenario they can work face to face and side by side and customer can directly communicate changes to the developers. High level of trust is necessary, customer needs to trust developers to make proper changes in the way they describe, developers needs to trust customers and product stake holders to describe changes accuretly and to agree to proper time frames to iterations.
As for Change in Agile environment the product stake holder or customer might work together directy with the developer to explain the change and then the developer will make the change to the software. The developer will need cross functional skills such as skills tof a business analyst or tester. The idea is to get working software with changes as quickly as possible back to the customer. Iterations are the key to Agile development, as changes are made to the software they are quickly circled back to the customer and user for acceptance.