Friday, March 31, 2006

Discussion on Agile, and Methodologies in General, Part 3

From :
Kent J. McDonald
Reply-To :
agileanalysis@yahoogroups.com
Sent :
Monday, March 27, 2006 7:33 PM
To :

Subject :
RE: [agileanalysis] Any activity in this Group?

Sorry to hear you were under the weather. That seems to be going aroundhere as well. I've moved up the sections I am replying to and cutting therest out. Hope that's ok (want to keep the message from getting too long).

DAVEW....1) How much time (hours per day) do Agile developers need to be withcustomers/users? Finding available time on key people's schedules is aconstant challenge for me; I basically have to prepare ahead for a veryfocused 60 to 90 minutes that I might get a day (or every 2 days) to gatherrequirements. I often end up addressing multiple projects with differentbusiness people in parallel in order to keep productive. In fact, mycompany expects partcipation in multiple projects at the same time.

Kent... It depends on the environment. Reality dictates that you figure outwhat works within the constraints you are working in. Working on multipleprojects at the same time is not ideal, but I know it happens quite often.
-----------------------------------------------------------

DAVEW...Sorry, i don't follow you here. A good methodology with defined artifactsshould ensure that what is delivered is of value, and no more; I don't havetime to produce content that is not used. ...and any good methodology andartifact set will evolve over time to capture what is required, and dropwhat is no longer required.

Kent...A good methodology is only part of the story. The real key is how do peopleimplement that methodology. Take the RUP for example. Rational decidedthat they were going to make the UP into a product, and wanted to make surethat they provided artifacts to cover as many different types of projects aspossible. The trouble is, more than a few people ignore the advice to craftthe methodology to fit the needs of that particular project and end up doingmore than they need because the methodology "requires" it. More often thennot, the "and drop what is no longer required" does not occur in practice.The ability to do that, to me, is a sign of a mature developmentorganization.

----------------------------------------------------------->

Kent... 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 thebusiness; if you have already started developing software, you have probablyselected the technical architecture and operating environment. How do youknow if you shouldn't have gone in a very different direction? Where do youmake the choice to re-use an existing system, or buy instead of build?

Kent...I'm not sure that I was implying that you started developing software. WhenI said "help them arrive at the best solution to their business problem." Iwas thinking things such as understanding what the problem really is andlooking at all possible approaches, which may not include a technologysolution. I should have also made a comment about helping the customerdetermine if they really have a problem, or if they are focusing on thewrong problem.
------------------------------------------------------------

DAVEW.....Ah well, power to you. .. I happen to believe that the inner tension of aproject between delivering the best solution and delivering it on time isbest resolved as an external discussion between 2 people, rather than aninternal dilemna for one person... at least that's what works for me.

Kent... 2 Heads is always better than one. I just happen to be a believer that ifthose 2 heads are experienced in a variety of skill sets (with obviousspecialties in one or two fields) the result will be better becausecollaboration is more likely to happen vs when people only specialize andfeel the need to do extensive "Hand offs" between functions. Of course youcannot always get people that are able to and enjoy doing a variety ofdifferent tasks, but it is always something for which to strive.
--------------------------------------------------------------

DAVEWYes, methodologies and documented processes for any activity that producesdifferent deliverables each time (like Information Systems) should not betreated as written in stone. Certification is a long-standing approach tocreating and perpetuating a profession; in fact, there is an ISO standardfor doing it. Managers and HR directors for years have been telling me howimportant it is to 'act professional' and all, I think I would like toactually be recognized as one.

Kent... I don't think you have to be certified to "act professionally", and Isuspect that there are some people with certifications that do not always"act professionally." Certifications have their place, but they have theirflaws as well. My advice to Managers and HR would be to "use with caution."

Kent J. McDonaldkent@kentmcdonald.com
http://www.kentmcdonald.com
Words to Lead By: Collaborate; Iterate; Serve the Team; Consider Context;Practice Excellence; Reflect and Adapt; Deliver Value

Wednesday, March 29, 2006

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

Discussion on Agile, and Methodologies in General

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

Thursday, March 02, 2006

Come and see my presentation at Business Analyst World, Toronto, May 2006

I am happy to announce that I am scheduled to make a presentation at this year's Business Analyst World in Toronto, on May 11. My subject is Integrating Business Analysis Artifacts (including Business Rules).

The details are available at:

http://www.projectworldcanada.com/toronto/conf_detail.asp?ConferenceID=2646

I highly recommend this conference to all Business Analysts. It is an annual event in Toronto and other locations around North America, paired with ProjectWorld.
See http://www.projectworldcanada.com/ for details.

So come on down, I look forward to meeting any and all who have visited this blog since its inception last year.

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.