Discussion on Agile, and Methodologies in General, Part 2

From :
David Wright
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 6:52 PM
To :
agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?




Sorry, been under the weather for a few days... so let me review and return the favour! DaveW>>

>The key to your statement above is *formal*. Agile methods recognize the>importance of requirements just as much as other methodologies, they just>have the philosphy that given a choice between recording the key points and>then having the ability to collaborate directly with the customer/user when>software development is underway vs documenting everything and throwing the>document over the wall to the developers, they would choose the former. We>all know that real life fits somewhere in the middle. A common agile>requirement mechanism is the user story, which typically consists of a>statement in the form AS A I Want so that>. Where the details are expressed as acceptance tests>so that the requirement artifact can provide multiple uses. Agile>approaches also discourage requirements inventory where all of the>requirements for a project are fully elaborated at the beginning of the>project. Rather they suggest that the requirements are listed at a very>high level at the beginning of the project for scoping purposes, then they>are elaborated upon during the iteration in which that particular chunk of>functionality is built.>
DAVEW....1) How much time (hours per day) do Agile developers need to be with customers/users? Finding available time on key people's schedules is a constant challenge for me; I basically have to prepare ahead for a very focused 60 to 90 minutes that I might get a day (or every 2 days) to gather requirements. I often end up addressing multiple projects with different business people in parallel in order to keep productive. In fact, my company expects partcipation in multiple projects at the same time.2) High-level Requirements are common when scoping a project, either as "I need..." or "The solution must..." statements. I am currently working on a project where high-level requirements were used to define 4 separate phases. Benefits and costs estimated for each phase were used to prioritize the work, and I am now working with the business on detailed requirements for the first phase. I will be feeding those requirements to the assigned designer as they stabilize, who will start development of the first phase while I proceed to detailing the requirements for the second phase, and so on.WIll the results be 'formal'? I suppose, since they will be documented, communicated and approved, and form a baseline for development that virtually eliminates mis-understandings..

>>>>>>>I think if you look at software development overall (including the >Analysis,>development, testing, etc.) from a value perspective, you may find yourself>asking how rigorous should your requirements activities be in order to>provide the information that developers need without performing non value>added work. Where that line falls varies between teams and projects.>
DAVEW...Sorry, i don't follow you here. A good methodology with defined artifacts should ensure that what is delivered is of value, and no more; I don't have time to produce content that is not used. ...and any good methodology and artifact set will evolve over time to capture what is required, and drop what is no longer required.......

"Business Analyst". It is not bad title, and it is one I>have had off and on since 1984, and it does describe what we do --- analyze>the business --- but not what we create: the Requirements.>>>I actually think analyzing the business is doing more than creating the>requirements, it should also be about collaborating with the customers to>help them arrive at the best solution to their business problem.>
DAVEWRequirements definition is crucial to selecting the best solution for the business; if you have already started developing software, you have probably selected the technical architecture and operating environment. How do you know if you shouldn't have gone in a very different direction? Where do you make the choice to re-use an existing system, or buy instead of build?

>>.....I think this is part of the reason that, when some companies hire a Business>Analyst, they believe they are also getting a Project Manager and Software>Tester (the latter better known as Quality Assurance Analysts). I have also>met Business Analysts who would agree with this. I would certainly agree>that having multiple skills will make you more marketable, but it should be>clear that these are three separate skill-sets that are not always>compatible.>
>I would be one of those BA's that agree with that statement.>
DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of a project between delivering the best solution and delivering it on time is best resolved as an external discussion between 2 people, rather than an internal dilemna for one person... at least that's what works for me.>>

<snip>>>....................................................If you consider yourself a Business>Analyst, it is imperative you seek out the IIBA, and highly recommended >that>you join.>>
>The good thing about the IIBA is that it is provide a source for BA's to go>for information about Business Analysis and providing a network for people>to expand their knowledge about the subject.>>I would caution about putting too much stock in certifications and BOK's.>Certifications indicate someone's ability to learn one set of knowledge>about a given area and take a test on it, they do not provide a reliable>measure of that person's ability in the subject area that they are being>certified on. BOK's are great because they provide a compiled set of some>knowledge about an area. They become dangerous when people start to>interpret that set of knowledge as *the only correct* thinking for a given>field, and people forget that items in the BOK do not work equally well in>all situations.>>I would agree that you should join the IIBA if you consider yourself a BA >(I>myself am a member). Just remember what a certification is really telling>you, and remember that just because some practices do not find their way>into the BOK does not mean that they are not correct or useful in certain>situations.>>
DAVEWYes, methodologies and documented processes for any activity that produces different deliverables each time (like Information Systems) should not be treated as written in stone. Certification is a long-standing approach to creating and perpetuating a profession; in fact, there is an ISO standard for doing it. Managers and HR directors for years have been telling me how important it is to 'act professional' and all, I think I would like to actually be recognized as one.>

Dave Wright