You are probably familiar with the Agile Manifesto that was written in 2001 by several forward-thinking software developers.
However, it is a manifesto for software development and, as you may have seen in a previous post, business architecture is about more than software requirements. Does that mean we cannot apply the 12 principles behind the Agile Manifesto to our work as business analysts? In fact we can, and we should. Here is my adaptation of the principles, with changes in bold italics.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable models of the business.
2. Welcome changing requirements, even late in development of the models. Agile processes harness change for the customer’s competitive advantage.
3. Deliver models of the business frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business experts and analysts must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within an analysis team is face-to-face conversation.
7. Tested models of the business are the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, analysts, and business experts should be able to maintain a constant pace indefinitely.
9. Continuous attention to excellence in analysis techniques and good business design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best business architectures, requirements, and business designs emerge from self-organising teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Producing software in an agile and iterative fashion has many benefits, as long as you are producing the software the business actually needs (and drives it towards achieving its strategic goals), rather than what individual users say they want. How do you know the business’s acceptance criteria are the right ones? How do you know the backlog of user stories is internally consistent? Producing business architecture in an Agile fashion is what drives out a robust backlog of user stories, with the right business knowledge to be able to define the most appropriate acceptance criteria (see my earlier post: Business analysis is about more than software requirements).
What do you think?