The term Agile is one of the buzz words in the Business Analysis press at the moment. Agile methodologies promote a project management process that encourages frequent inspection and adaptation. It uses a leadership philosophy that encourages teamwork, self-organization and accountability, and a set of engineering best practices that allow for rapid delivery of high-quality software. It encourages a business approach that aligns development with customer needs and company goals. One flavor of Agile is Extreme Programming which is sometimes affectionately known as XP.
The main aim of Extreme Programming is to reduce the cost of change by introducing basic values, principles and practices to a system development project. Proponents of Extreme Programming and Agile Methodologies in general, regard ongoing changes to requirements as a natural and desirable aspect of software development projects.
In Extreme Programming the level of customer satisfaction depends on the Extreme Programming cycle, which is sometimes known as “the circle of life”:
- the customer decides which features have value,
- programmers estimate the cost of providing the features,
- the customer chooses the best combination of features based on value and cost,
- programmers build the features, learning how to estimate costs in the process,
- the customer learns how to define value and how to make effective choices.
This is highly effective, and when both parties are fully engaged, then both sides benefit. The trouble with this win-win virtuous cycle occurs if you have an intermediary between the business and the developers, or one party who has not fully engaged.
If you place an intermediary such as an analyst between the customer and the developers, then the third party gets all the benefit. The best results occur if the Business Analyst acts as a facilitator to enable the interaction. This lets the developers see and feel the urgency and need, and to understand what the users really want. The users understand the level of complexity of any underlying modeling and so are able to assess relative value of features. The Business Analyst learns from both parties and is able to translate terminology on the spot, or illuminate areas which lack clarity. One such meeting, lasting an hour or so can save weeks of Use Case building and requirements documentation in traditional system development methods.
In the situation where one party has not fully engaged, the problem is of a different caliber. Often the customer lacks engagement because they have seen Agile as a way to save themselves time and expense with documentation. This can occur if an evangelist for an Agile methodology gives high abstraction level feedback for a successful project, often in a throwaway comment, in a social situation. This is really a high risk situation, and one to be avoided at all costs. It is the Project Manager’s responsibility to ensure that business owners do not see use of an Agile methodology as a way to save costs by eliminating documentation. If she fails to ensure engagement, such project will inevitably suffer from cost overrun, mission creep and even failure when the deliverables do not meet the needs of the users.
The way to ensure a successful development project is to have sufficient capacity in the disciplines of Business Analysis and Project Management to ensure that the lessons are learned and both parties remain engaged. By applying Extreme Programming, a system development project will be more flexible with respect to changes, and will meet the needs of the users when it is live. By having close engagement between the business users and the developers, the customer learns how to define value and how to make effective choices, and the programmers learn how to estimate costs. If this is all kept in-house then the business keeps all the benefits.
Although Extreme Programming itself is relatively new, many of its practices have been around for some time. The methodology simply takes best practices to extreme levels. However it is not an excuse to avoid engagement in a project or omit documentation. Its strength lies in the rapid time to market, and the acceptance that change is inevitable. Its weakness lies in its attractiveness to budget slashers who do not understand or fully embrace the methodology, or misguided evangelists who believe that by putting the users in with the programmers you can cut out the Business Analysts and Project Manager.
The benefits of Extreme Programming and Agile Methodologies are self evident to their supporters, who can show you any number of successful projects, completed on time and within budget. The detractors can enumerate the risks and point to projects which have over-run or gone of the rails through lack of discipline. In reality, they are both right, because in life we get what we look for.
The responsibility of the Project Manager is to ensure that we focus is success, and use the right methodology for the situation. The Business Analyst is the facilitator to enable the interaction between the customer and the developers, and so deliver the successful product. Customers will see success by embracing change and allowing Agile development teams to work with users for rapid delivery of high-quality software, using a business approach that aligns development with customer needs and company goals.
Bruce Thompson
Webmaster of The Institution of Analysts and Programmers, Bruce Thompson is a PRINCE2 Practitioner and active Agile evangelist for more than 10 years. He has delivered a number of successful projects using DSDM and Extreme Programming.
For further information on Agile see the Wikipedia entry for Agile Software Development
For more information on analysts in the loop see Business Analysis in Extreme Programming by Ron Jeffries
If you are in Business Analysis, Project Management or Agile Software Development and are interested in joining like minded individuals, visit The Institution of Analysts and Programmers website