Agile Software Development and Business Analysis
By: Scott W. Ambler
In this article Scott W. Ambler, Practice Leader Agile Development in the IBM methods group, overviews agile software development and the implications for business analysts.
| Attachment | Size |
|---|---|
| Agile Software Development and Business Analysis.pdf | 39.51 KB |

Low Hanging Fruit
As always, it depends. Typical consultant answer, I know, but unfortunately true.
Here are some suggestions for low-hanging fruit:
Introduce short iterations. I'm a firm believer that iterations should be no more than 4 weeks in length, but prefer one or two week iterations if possible. Short iterations help to squeeze the bureaucracy and waste out of the process because you simply don't have time.
Co-locate the team. Both developers and stakeholders should sit together as much as possible, and the development team itself should be in a single room together.
Active stakeholder participation. Put those folks to work! It's easy to do, and provide huge benefit in terms of improved feedback.
Document less, code more. The primary goal of software development is to produce high-quality working software which meets the needs of its stakeholders. The secondary goal is to ensure that you have adequate documentation. Keep those priorities straight.
Put a lot of whiteboards up, and let team "own" as much whiteboard space as possible. That way they don't need to capture as much information in official documentation because it's right there in front of them. And they have easy to use modeling tools at their disposal as a result.
Treat acceptance tests as requirements artifacts. There's a lot less documentation to do.
- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM
http://www-306.ibm.com/software/rational/bios/ambler.html