Excellent read - http://dvpms.squarespace.com/our-journal/ (owned by my partner Vernon Zwiers)
Prudent adoption of Agile Modelling in Business Analysis and Design
This article is not going about addressing the intricacies of Agile Modelling. This article does however place this absolutely valuable method in the Business Analysis and Design area of expertise.
Have a look at Scott W. Amber’s web site, http://www.agilemodeling.com/ for in depth information about Agile Modeling. Scott W. Amber is the founder of Agile Modelling.
The first thing that must be looked at is the characteristic profile of the Technical community. Yes, it is a generalization, but serves the purposes of this article. Engineers and technical people (which is also my background…) always look for the short way of getting things done quickly. It is not a matter of what is known but where it can be found when needed. One only has to look at a technical person doing a home project. The Construction Manual is only necessary if things go wrong at some stage, even if the project is completely new to the person.
Agile Modeling fits in exactly with this profile, which is, “Get it done quickly with as little input as possible and we can always apply the same process if anything goes wrong to fix it.” It was developed from a technical point of view meant for technical use. The design of this methodology is to get rid of as much analysis work as is possible and just get to designing and implementing the system. Thus it has certainly created a place in the analysis for itself and that is for purely back end system level functionality. It falls horribly short when it comes to involving the Users of a system when trying to make the system reflect how their business is done.
Another common characteristic is that technical people avoid other humans like the Business Owners and the System Users at all costs. Thus when looking at Agile Modelling and asking the Business owners during the analysis whether they understand what is happening, the usual answer is received, “Well as long as they know what they are doing, that’s fine.” Internally they are probably thinking to themselves, “We’ll nail them later at sign-off time.”
Unfortunately there are some things that no Business Analyst can shortcut or get away from and that is, plain simple, hard work, huge effort and sufficient documentation, which is understood by everybody, to allow a system to be written. The User has to be made part of the team right from the beginning and their input is worth gold as they are the experts in their particular field of work, not just the technical people. In order to facilitate this a Business Analyst has to have as part of his or her arsenal some way in which to get this information in a form that the Business User is comfortable with and understands, at each step of the way.
So where does Agile Modelling fit in with Business Analysis and Design?
The ideal point is when the design gets down to the class level. At this point it is a extremely valuable and highly recommended method to enhance the system design at the point of system expansion to support the requirements gained through the analysis.
The whole point is that as Business Analysts we must not limit ourselves to the hype and hoorah that is created, but make sure that we understand these techniques and know where the value of all these techniques lie. This will give us an understanding of where they will benefit the projects that we work on. We need to embrace and incorporate them in our work where they make sense and combine them to create a solid system when the work is finished. At all times we must be able to apply what are Appropriate, Necessary, and Sufficient for the situations that we are analysing.
