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 |
We can do better
A few points:
1. The challenge with people who are overly specialized, regardless of the speciality, is they'll do a really good job at whatever their specialty is. This sounds like a good idea, but do we really need them to do that much work? Often we don't. For example, a use case modeling specialist might choose to write a detailed 5-page use case when a half-page point-form one would have done just fine. But, when your primary skill is writing use cases, naturally you're going to strive to write the best darn use cases you possibly can.
2. It's important to have someone(s) on the team with BA skills. More importantly, they should work closely with the other people on the team so that way their BA skills are transferred to those people (and they might even pick up some new skills themselves in the process).
3. It's important that they have more than just BA skills, that way they are able to accurately judge just how much BA work they need to do, just how much design work, just how much testing work, .... People who are generalizing specialists seem to be far more productive in practice than people who are just specialists. Sadly, I don't have any numbers that show this to be true, but a lot of people seem to have observed this to be the case.
4. Specialists often proclaim how important their specialty is, and how the world would be a better place if we only did more of it. Generalizing specialists rarely seem to make such proclamations, instead their attitude is often that everyone should strive to get better at a variety of skills including but not limited to whatever it is that they like to focus on.
5. I suspect it will take us at least a generation to get rid of the Tayloristic thinking that's been foisted upon us by the traditional community. This sounds like a long time, but we may be doing pretty good if it only takes this long.
6. In Agile Modeling we're very clear that a system's stakeholders are far more wide ranging than a couple of end users. We also promote "radical" ideas such as the need to work closely with them and better yet even get them actively involved in the modeling effort. Some of other agile methods, particularly the extreme ones, could clearly benefit from this sort of mindset.
- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM
http://www-306.ibm.com/software/rational/bios/ambler.html