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

No comments:

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.