Agile Development — Introduction
Agile development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.
Agile development focuses on achieving personal, technical and organizational goals. Agile methods achieve organizational success by focusing on delivering value and decreasing costs which translates to increased return of investment. The iterations involved in agile development leads to continuous integration preventing unexpected delays before release and allows the team to change direction at will. Everyone either exec, users, stakeholders, developers, testers etc gain from the continuous deployment models as they are able to see success weekly for example.
Agile development values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and response to change over following a plan. Examples include extreme programming(XP) and Scrum. In this post I will focus in XP.
The XP life-cycle
The XP teams perform nearly every software development simultaneously. They do planning, analysis, coding, testing and deploying within a rapid frequency in what is called an iteration.
The planning phase is however more intense in the first weeks of production. In later iterations, the planning focuses on what will be done in the iteration. On-site customers help in analysis by checking if the requirements are met as well as using customer tests.
Programmers use automated tests- test driven development, which reduces the number of manual tests required. They work closely with testers in doing the tests.
The XP team
The members of the XP team include the following:
On-site customers
These are responsible for designing the software the team builds. They do a lot of planning and provide programmers with the requirements details upon request. They do not have to be real customers as the role can be carried out by other members who know the requirements. Two customers are required for every three programmers.
Product manager
Maintains and promotes the product vision. Good product managers have a good understanding of the market and should have authority to make trade-off decisions of what to produce and what not to. It is advised they they are always present full-time but they can delegate their duties to onsite customer.
Domain experts
These are the experts in the field that the software operates and have the answers to domain related questions in their fingertips.
Interaction designers
They define the UI. They should have a good understanding of the users and spend time to gather feedback from them. They divide their time between the group and the users.
Business Analysts
They argument a team that already has a product manager and domain experts. They help the on-site customers to to capture the details they may otherwise miss.
Programmers
They create software. They spent most of the time doing pair programming and apply TDD.
Designers and architects
They guide the team’s incremental design and architecture efforts and help the team members to see ways of simplifying complex designs.
Technical specialists
Everyone has his own area of expertise, but it is advised for every programmer to know other parts of the system.
Testers
Help in producing quality product by helping customers to identify holes in the requirements. They are technical investigators also who carry out tests on the product to aid in preventing bugs from reaching the production. With automated tests, they work becomes simpler. In the absence of dedicated testers, the programmers and the customers can take this role.
Coaches
They help the team succeed by providing a good working environment, linking the team with the organization and also provides guidance to the team. Since XP teams self-organize, with time the work of the coach reduces.
The programmer coach
Help other programmers technically and also act as regular programmers.
Project Manager
Help the team work with the organization well and coaches on non-programming practices.
These roles are however related and it is common to find people filling in for other roles
Adopting XP
To adopt XP, the following prerequisites should be considered:
There should be full management support.
The team should agree to use it since this changes a big part of their style of work
The team should be co-located to promote constant communication between the members which is essential in XP.
Onsite customers should be present
The team should be of the right size
All the practices should be adopted
To effectively use XP, the code base should be new, members should have strong design skills especially the leader, an easy to refactor language should be used, the programmer coach should be experienced and the team should be friendly and cohesive
Since it is hard to change, every team member should be supported in the shift process.
All the working agreements should be discussed before starting
For a new project, it is easier to implement XP and all the practices should be carried out. Start the first iteration with the stories that will definitely be in the first release plan
Adoption of XP should be incremental for a legacy project. One of the most important thing to consider is how to pay for the technical debt. Working on reducing the technical debt will lead to a low velocity in the beginning. However, with reduced debt, the velocity will eventually pick up. Focus on bringing structure to the team before starting on the technical aspects.
XP is meant to be used in an organization that uses iterations to produce code. If the organization is phase based, try to introduce some aspects of iteration in the phases. For example, you can do some do an iteration on some stories in the planning phase which will lead to some code after the phase. The coding and testing phase are mandatory. These two can be integrated.
