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.
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.
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.
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 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.
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.
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.
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-----