I recently sent the following email to a Yahoo group I belong to on Agile Analysis...It has been quiet at this group for some months now... anyone out there doing what they consider to be agile analysis on current/recent projects?I'll be honest, I am still skeptical on this topic... see
http://businessanalysis56.blogspot.com/2006/01/information-system-requirements-still.html ...but I am still open to being persuaded.Dave W
..and ended up starting a conversation on the topic that started with the following reply from Kent Mcdonald:David,I would say yes there are people doing what they consider to be agileanalysis on current/recent projects, they just don't happen to be posting tothis list. The most active discussion surrounding agile analysis typeactivities appear on the Agile Modeling list.(
http://groups.yahoo.com/group/agilemodeling/) This list is moderated byScott Ambler who has done a lot of writing on Analysis related activities. Isuggest you read his writtings and join the mailing list. Based on readingyour blog post, I think you may find some of it interesting.
As a matter of fact, when I first started this list, I got a bit of pushbackasking if a list focusing on Agile Analysis was really necessary and whether it continued the fractionalization of the software development community.You can look back in the archives and follow the discussion. My thought basically was that we would "let the market decide" and based on your observation about traffic, they may have been right. None the less, I believe there still is value in talking about doing analysis in an agile manner. This has different meanings for different projects in different environments. In those environments that support full blown agile, that means developers working with customers directly. In environments thataren't quite ready for agile, that means that analysts collaborating with both developers and customers to make sure they are working with the customers to understand their needs and with the developers to understand what information they need to properly develop what the customer needs.
David, I read the blog entry that you referenced and had some thoughts. Ihope you don't mind that I replied to parts of it in this message.-----------------------------------------------------------------------------------------------------------------------
If you are familiar with newer Agile or Extreme methods for developingsoftware, you will know that they disdain formal requirements, preferring towork directly with end-users to deliver software in small increments. Ibelieve that these methods are a natural reaction to software developers'long-standing frustrations with receiving poor, incorrect or no Requirementsto work with. Developers should be focused on creating software, and timethey spend trying to find out what they should develop, or developing thewrong software, is a waste of their valuable time.The key to your statement above is *formal*. Agile methods recognize theimportance of requirements just as much as other methodologies, they justhave the philosphy that given a choice between recording the key points andthen having the ability to collaborate directly with the customer/user whensoftware development is underway vs documenting everything and throwing thedocument over the wall to the developers, they would choose the former. Weall know that real life fits somewhere in the middle. A common agilerequirement mechanism is the user story, which typically consists of astatement in the form AS A I Want so that. Where the details are expressed as acceptance testsso that the requirement artifact can provide multiple uses. Agileapproaches also discourage requirements inventory where all of therequirements for a project are fully elaborated at the beginning of theproject. Rather they suggest that the requirements are listed at a veryhigh level at the beginning of the project for scoping purposes, then theyare elaborated upon during the iteration in which that particular chunk offunctionality is built.Why do Developers get poor Requirements? There is often no common disciplineor accepted practices being used when creating Requirements in a softwaredevelopment project; but, if Developers do get good Requirements, theresulting software is better is almost every way, primarily that it willmeet the needs of the business that requested and paid for it.Agree here.As a discipline, Project Management faced similar problems in the past, buttoday its practitioners all recognize common approaches and techniques: WorkBreakdown Structures, Gant Charts, Pert Charts, Critical Path Analysis, andmore. They also have seen their work coalescing as a profession through thePMI and its PMP certification. Project Managers also started with theadvantage that their job title actually describes what they do - ProjectManagers manage projects. Software Developers have the same advantages,although the wide variety of languages and environments mean no singlecertification can be had.There are positives and negatives to being considered a "profession" and tocertification. More comments on that later.So, I think Model Driven Architecture will play an increasing role overtime; in the mean-time, if it shows that methods for producing requirementscan be rigorous enough (good enough) to generate code, then why not use suchmethods to document Requirements for developers to use for the rest ofsoftware development
I think if you look at software development overall (including the Analysis,development, testing, etc.) from a value perspective, you may find yourselfasking how rigorous should your requirements activities be in order toprovide the information that developers need without performing non valueadded work. Where that line falls varies between teams and projects.
An ancient Chinese saying tells us that 'All wisdom begins with callingthings by their right names.' So, the job of gathering and documentingRequirements needs a Name. I am being somewhat disingenuous here, as thereis well-known job name already, but it is not always used the same way; I amtalking about the "Business Analyst". It is not bad title, and it is one Ihave had off and on since 1984, and it does describe what we do --- analyzethe business --- but not what we create: the Requirements.
I actually think analyzing the business is doing more than creating therequirements, it should also be about collaborating with the customers tohelp them arrive at the best solution to their business problem.
I think this is part of the reason that, when some companies hire a BusinessAnalyst, they believe they are also getting a Project Manager and SoftwareTester (the latter better known as Quality Assurance Analysts). I have alsomet Business Analysts who would agree with this. I would certainly agreethat having multiple skills will make you more marketable, but it should beclear that these are three separate skill-sets that are not alwayscompatible.
I would be one of those BA's that agree with that statement.
The last question about the Business Analyst job is the importance ofspecific business knowledge and experience, aside from analytical andrequirements-related skills. Again, companies will ask for Business Analysiswith experience in Supply Chain Logistics or Life Insurance or ExpressDelivery or Human Resources or Commercial Credit or Finance/Accounting.Well, I have worked in all of these business 'domains' and more withoutneeding to change how I do my job. In the end, the business people beingserved by Information Systems - executives/sponsors, managers, end-users ---are the ones who need to know their business; what I need to do is be ableto quickly understand their business in order to gather and document theirInformation Systems Requirements.
Agree completely. It has also been my experience that someone who does notnecessarily have a long history in a particular industry, but is able toquickly pick it up, is often not influenced by filters, and would be morelikely to ask those probing questions that could lead to groundbreakingchanges in how the business works based on borrowing ideas from otherindustries.
Finally, you may ask how technical a Business Analyst needs to be. My basicrecommendation is you need to understand what technology can do in order todeliver the solutions that meet the Requirements, but you don't need to knowhow the technology will do it. I started as a PL1 and IMS programmer beforemoving to Business Analysis; since then, I have done Requirements forsystems implemented on mainframes, minis and PCs, using environments fromTSO to OS2 to Windows to Browsers; again, the technology to be used to didnot really change how I did my job; in fact, the best Requirements are thosethat can be implemented in multiple technical environments.
Knowing the technology certainly does not hurt. And sometimes it's nice toknow when a technologist is giving you bad information, especially whenworking with the developers to realize the requirements.
And about certification for Business Analysts, we can now look to theInternational Institute of Business Analysis, at www.iiba.com . It is beingcreated and developed following the appropriate ISO standard forprofessional certification organizations and, much like the PMI, isdeveloping a Body of Knowledge for Business Analysis andcertification/testing based on that BOK. If you consider yourself a BusinessAnalyst, it is imperative you seek out the IIBA, and highly recommended thatyou join.
The good thing about the IIBA is that it is provide a source for BA's to gofor information about Business Analysis and providing a network for peopleto 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 knowledgeabout a given area and take a test on it, they do not provide a reliablemeasure of that person's ability in the subject area that they are beingcertified on. BOK's are great because they provide a compiled set of someknowledge about an area. They become dangerous when people start tointerpret that set of knowledge as *the only correct* thinking for a givenfield, and people forget that items in the BOK do not work equally well inall situations.I would agree that you should join the IIBA if you consider yourself a BA (Imyself am a member). Just remember what a certification is really tellingyou, and remember that just because some practices do not find their wayinto the BOK does not mean that they are not correct or useful in certainsituations.
Looking forward to anyone's thoughts.Kent J. McDonaldkent@kentmcdonald.comhttp://www.kentmcdonald.comWords to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value-----Original Message-----
