Sorry for the OT post but I'm positive that several people here are
consultants... or work
with them.

I'm writing another article in my "5 Things the CIO should know..." series,
which includes
"7 things the CIO should know about telecommuting" (http://www.cio.com/article/
108501), "5 things the CIO should know about software requirements" (http://
www.cio.com/article/29903), and "...about fighting spam"
(http://www.cio.com/article/
28830).

This time, I'm asking contractors and consultants about their experiences with
clients --
in particular, with the upper management at the client company. I'd love to
include your
input.

There's just one question to answer: If you could get the (client) boss(es) to
understand
JUST ONE THING about computer consulting and contracting, what would it be?

Or, to put the same question another way: If you were given a single wish of
something to
change (about a current or past client) what would it be?

If you're an active consultant or IT contractor, I'm sure you have more than one
response.
But by asking you to give me only ONE answer, I can prioritize the issues that
matter most
to consultants and contractors. (I spent several years in that role myself, so
believe me... I
have my own list!) I'll turn the responses into a list of the top items, and --
since this is for
CIO.com -- in this case the upper management at your client might actually read
it. If I do
my job well, he or she might actually learn from it.

If you aren't a consultant, that's okay -- I'll still be happy for your input.
Because there are
plenty of problems that consulting and contracting causes for IT staff. (I'd
give a few
examples here but I don't want to make suggestions that cause you to say, "Yeah,
just like
that!")

In either case, your "just ONE thing" can be something tiny and annoying, or a
wide
generality. This is about what gets *your* shorts twisted in a knot; you don't
have to worry
about whether it bugs other people too.

Anecdotes are wonderful. Please, share horror stories.

Two important requests:

* PLEASE do not make your single answer a rant about outsourcing overseas. We
have
plenty of material on that subject already and it's entirely predictable. I'm
much more
interested in writing this article with specific advice that's more, well, close
to home.

* Remember that I'm writing an article and I need to quote my sources. I
generally can't get
away with anonymous quotes. So please *please* give me your name, company name
("self
employed consultant" is fine though your company name is better), some idea of
your
company size (that is, a solo developer may have different perspective from a
larger
consulting firm), your personal role (i.e. "a consultant who specializes in web
development" or "a Java programmer on staff"), number of years consulting, and
location.
If you refer to a client, supply some kind of description for credibility (i.e.
"a large
insurance company in the midwest" if you don't feel comfortable saying, "When I
was a
consultant at State Farm..."). At a minimum, send me a private e-mail message at
esther at
bitranch dot com. The point is that I need to provide references, or the article
lacks
credibility.

I'll check back here -- because I'm sure this will be a fun topic for the
community to
discuss -- but I'd also be happy to hear from you privately.

I'll collect input until, oh, sometime next week. Say, the end of July. Then
I'll collate the
responses and turn them into something (arguably) brilliant to which you can
point
prospective clients.


Esther Schindler
Senior Online Editor, CIO.com
http://advice.cio.com/blogs/youre_the_boss

Sorry, i missed out on the thread,
 

Thanks Ahmad for the info. I've looked at VSTS but have an issue with using TFS in my organisation. So all i can do with VSTS Tester Edition is write manual and create automated test cases. Not so pleased really. Having worked with Testdirector/Quality Centre, i've become more accoustomed to recording pass/fail status and comments against each test condition in a test case. The word templates in VSTS don't allow me to do so.

 

You've mentioned Test-log.... can u send me a url to the application? does it allow mapping of user requirements/story cards to test cases?

 

Br,

Harsha

 

On 25/07/07, Ahmed Omar <ahmed.omar@mail.link.net> wrote:

Dear sachin,

You can manage your test case by Test-Log application Or VSTS certainly in TFS server based application .

The other way to manage your test case that you can use story-board If u interested on Agile testing certainly in SCRUM team

you can use test log this tools suitable if you are working in a small company if you are working in a firm exceeding than 100 employee

At that moment preferred to use VSTS tools .

 

 

 

Hello list,

possibly a bit off topic;

I am compiling a 'top tips' for whiteboarding in an agile software
development process for small web development teams (selenium tests,
some simple agile dev methods, and unit testing).

Appreciate any links, advice, and practices with respect to what works
for this crowd with respect to daily whiteboarding to estimate effort
in testing, development, and architecture.

thx in advance, Jim Fuller

Dear Testers!!!

1) Call for Speakers - Dublin Test Conference - SQS -
http://testerqa.com/index.php?option=com_content&task=view&id=334&Itemid=1

2) Vmware offers performance testing tool -
http://testerqa.com/index.php?option=com_content&task=view&id=333&Itemid=1

3) Lionbridge Opens Translation Institute in India, Provides Free
Software to Empower Translators -
http://testerqa.com/index.php?option=com_content&task=view&id=332&Itemid=1

4) Moravia's QASight Releases New FaultFinder Testing Automation Tool
-
http://testerqa.com/index.php?option=com_content&task=view&id=331&Itemid=1

Happy Testing!!!

TesterQA!
www.testerqa.com

On Jul 26, 2007, at 10:21 AM, Ward Cunningham wrote:

> I was about to ask Brian for some tips on translating Omnigraffle
> to Ruby, something that I've been trying to master myself, when I
> got to the statement above. Brian, are you saying that I should
> stop fooling around and get back to work? If so, I was beginning to
> think that myself. But Omnigraffle is sweet and there is oh, so
> much potential.

I get my fill of telling people to get back to work from my kids and
their homework. So it's up to you.

Given the plist gem (from rubyforge), which will turn a graffle
document into hashes of arrays, manipulating graffle docs is easy. I
would rather you used my gem (graffle.rubyforge.org) and asked for
features (or contributed). Note: I want to put off being able to edit
and save a graffle file for now.

(Someday, I have this idea of having a running test drive Graffle
through its scripting interface. Imagine the different elements in a
workflow highlighting themselves as they executed, and turning red if
the test fails. But I doubt I could justify such glitz to myself
unless it looked like it needed that kind of push to become accepted
by product owners.)

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog

Our group is just starting to use an Agile (Like) process and we are
having some intersting discussions on how and by whom the testing will
be done.  I was looking for some seminars on this I might attend in
the near future.  Does anyone have any suggestions?  Thank you.

>Personally, I don't really care to turn my developers into good testers
and my testers into good developers. I *do* care that my project has good
testers and good developers. I would prefer that most of the testers were
also developers and vice-versa. But these are not building blocks and
cogs we're talking about. They're people. If I had someone on my team
who was not good at developing or testing, but was really good at
identifying important concepts and describing them clearly, I would be
overjoyed at having them.

Exactly.

>And if we think a developer needs better testing skills or a tester needs
better developing skills, let's sit down with them and work together. Maybe
they'll learn the skills we want them to. Maybe we'll learn that it's not as
important as we thought. Maybe something else will happen. But whatever the
distribution of skills and abilities on the team, if they're functioning
well as a team, the people will accomodate that distribution to get the job
done.

Exactly.  Instead of thinking "more skills" or "certain skills", how about
"appropriate, diverse, and advancing skills /for the individual and team
context/"?

---Michael B.

George:>Personally, I don't really care to turn my developers into good
testers
and my testers into good developers. I *do* care that my project has good
testers and good developers. I would prefer that most of the testers were
also developers and vice-versa. But these are not building blocks and
cogs we're talking about. They're people. If I had someone on my team
who was not good at developing or testing, but was really good at
identifying important concepts and describing them clearly, I would be
overjoyed at having them.

Amen.

---Michael B.

Ron:>I'm not able to come up with a non-sarcastic argument supporting the
opposite of my position, which is "more skill is better than less".

Well, that's a heuristic, and a vaguely worded one at that.  It's a
heuristic that I generally agree with--but heuristics, like programs, are
potentially dangerous when we're not cognizant of how they might fail.  So
my non-sarcastic suggestions are:

1) Sometimes breadth of skills (one sense of "more skill") is more important
than depth of a given skill set.
2) Sometimes depth of one skill set (a different sense of "more skill") is
more important than a breadth of skills.
3) A less-skilled person may have the ability to bind and motivate the team
on an emotional basis.
4) A more-skilled person may have interpersonal problems that damage the
cohesion of the team.
5) A more-skilled person may suffer from anchoring, assimilation, or
confirmation biases that an lesser-skilled person can help to expose (cf.
How Doctors Think (Groopman)).
6) Some tasks are important but don't require a whole lot of skill.
7) A less-skilled person who can then be trained might be a more appropriate
hire when cost is a factor.
8) An organization (say, the Army or an Agile team) might prefer unskilled
people for certain positions so it can more easily develop their skills in a
way that conforms to the organization's way of doing things.
9) More skill might be irrelevant in a given context, and attaining it might
be wasteful and a distraction.
10) People on the team may resent the highly skilled. (e.g. James Bach
reports that his boss at Apple told him never to hire a Ph.D. because they
are not "practical"; people who are regular expert witnesses are sometimes
less preferable than "virgin" witnesses whom the jury will find more
unaffected).
11) A more highly skilled person may be reluctant to listen to advice.
12) A more skilled person might be more inclined to add value that the
client doesn't care about--gold-plating.
13) A more skilled person with a reputation to protect might be sufficiently
risk-averse that he might not try something new or challenging.
14) A person who is skilled in some domains might be sufficiently complacent
not to consider new or different ways of thinking that might be valuable.
(McLuhan was particular fond of pointing out that the experts were invested
in their own expertise; Taleb talks about a similar pattern in The Black
Swan.)

---Michael B.

On Thu, July 26, 2007 13:32, Kilbride, James P. wrote:
> I still believe that there are some skills that having them eliminates
> other skills. It's difficult to evaluate how an illiterate person will
> evaluate a poster, for example, if you are not illiterate. So if I want
> a tester to tell me whether somebody with poor english is going to
> understand what I want done the fact that they have good english is
> likely to mean they arn't going to be able to fulfill the test I want.

James, is illiteracy a skill?  Could you, perhaps, be describing a
point-of-view rather than a skill?

Some people have the ability (a skill) to view through several points of
view, not merely the one that comes most naturally.  To use your example,
a person who learned to read late in life might be able evaluate the
poster from both the literate and illiterate viewpoints--if they hadn't
forgotten what it was like to be illiterate.  Someone with the proper
imagination might be able to do the same.

  - George

--
   ----------------------------------------------------------------------
    * George Dinwiddie *                      http://blog.gdinwiddie.com
    Software Development                    http://www.idiacomputing.com
    Consultant and Coach                    http://www.agilemaryland.org
   ----------------------------------------------------------------------

Hi Brian,

>> I'm not able to come up with a non-sarcastic argument
>> supporting the
>> opposite of my position, which is "more skill is better
>> than less".
>
> Here's one, from my own experience.

Perhaps if we add a verb:  "Having more skill is better than
having less."  Having skill doesn't (necessarily) mean
you'll over-apply it.

For folks (like me) who become enamored of shiny new skills,
we may need to add a meta-principle:  "Having more skill at
choosing when to apply your skills is better than having
less."  ;-)

My guess is that counterexamples to that are rare.

And if I'm right that it's hard to argue with that position,
then it seems unlikely that anyone was /trying/ to argue
with it.  So if there's an argument, it's about some other
point.

Perhaps someone could write up a list of the points that
people in this conversation generally agree on, and another
list of the points of disagreement.  I've lost track.

Dale

--
Dale Emery, Consultant
Inspiring Leadership for Software People
Web:    http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

On Jul 25, 2007, at 10:48 AM, George Dinwiddie wrote:

> On Wed, July 25, 2007 9:28 am, Brian Marick wrote:
>> The reason for a barbecue was that the team was located a short car
>> drive away from most or all of the users. The feeding frenzy needed
>> to be a big enough deal to get people into their cars.
>>
>> It was also to make the point that feedback is important enough that
>> I'm willing to spend a non-casual amount of my own money to get it.
>
> Brian, I'm curious.  How effective have you found this sort of
> action at
> getting appropriate attention and making a point?  Can you offer any
> insight into the salient characteristics of environments where it's
> successful vs. those where it's not?

A good question. I'd first say the point gets made only when the
money reinforces an attitude that I'm continually displaying
throughout my time there. (I typically go for week-long visits,
roughly once a month.) For example, I'm very big on the relationship
between the team and the product owner. Early in my first visit, I
say to the product owner, "Nobody may have told you, but you probably
have the hardest job on this project, so I *need* to talk to you.
I'll buy you lunch. What's a good day?" Most often the product owner
is not spending enough time with the team, so my being willing to,
essentially, buy her time starts to make the right point. But lunch
alone wouldn't do much.

I also continually show a rather casual attitude toward bureaucratic
roadblocks. Again, the important thing is to demonstrate taking
action, not just complaining.
	 (In fact, I like to think I'm reasonably sympathetic to the fact that
	 roadblocks are often there for a reason. Chesterton's gate:
	 http://stuartbuck.blogspot.com/2004/05/chesterton_14.html
	 But while they may be appropriate on average, *this* project is
	 meant to be an outlier.)
Most often the action doesn't involve money, it's more a matter of
"We can set up CruiseControl *right now*, on that machine over
there." But I have in the past offered to buy a 1 gig memory upgrade
for a programmer's underpowered machine; I like to think that
accelerated her manager's push to get her a replacement before the
Officially Mandated Laptop Ownership Period had passed. Maybe not.

In addition to being a point that's reinforced throughout a visit, I
think it's also important for the money to be spent in a direction
the team already wants to go: more contact with users, more product
owner involvement, more ease at work. A lot of what I do seems to be
giving teams permission to do what they know needs to be done.

An example of less effective spending: I often buy teams books that
are relevant to their problems. The most common are Cohn's _Agile
Estimation and Planning_ and _User Stories Applied_, Wake's
_Refactoring Workbook_, and my own _Everyday Scripting With Ruby_. I
think people appreciate them as gifts and make some use of them. I
don't think they make teams much more likely to consult the
infosphere than they were before. It's hard for me to know for sure.

Finally, my spending works best with teams that have early adopter
personalities. I should note, though, that *everything* I do works
better with such teams, so that probably has more to do with me than
with them.

-----
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog

On 7/26/07, Kilbride, James P. <james.kilbride@...> wrote:
>
> Ooh I like this. In particular I feel like the  conversations talk a lot about
both Discipline AND Skill (last conversation  mostly about skill) but loses ease
and joy. A team without joy under discipline  and skilled is still not as good
at agile possibly as a team with less  discipline/skill but working with utmost
joy.
>
> I think most of my concerns is that we talk in  abstractions and they tend to
take left/right dichotomies when the truth of  agile is actually straddling the
line. Just enough discipline(process) to  balance the ease of working to balance
with the skill level the team has that  manages to keep the joy in the work..
>
> And that balance changes as the team changes and as the job  changes. You have
to constantly rebalance the 4 to keep the team on that narrow  point of optimal
performance(long term and short term) and that's why it's  agile.

<SG>
English is so ambiguous.  When you say "you", do you mean the team,
its manager, team lead, or who?  I believe it is the whole team who
has to constantly rebalance itself.  Nobody can do it for the team!
For agility to blossom, management needs to give the team the
authority and responsibility to rebalance itself through frequent
retrospectives (facilitated until the team can do it themselves).  The
team has the responsibility to ask for external help when they need
it.
<SG/>

Because it's constantly rebalanced. Not because it's constantly
change,  or because it's giving up discipline, or having enormous
discipline. But because  it's a knife's point.

<SG>
Some have used the term "chaordic" to describe this knife's edge.
</SG>

>
> James Kilbride

On 26 Jul 2007, at 16:05, Matt Heusser wrote:

> "Burt Rutan of Scaled Composites can put someone in low earth orbit
> in about
> a fifth time the time and a tenth the price of NASA.
[snip]

No he didn't (not LEO anyway). His team put something that got up to
367k feet and back down again - twice within 14 days. That's very,
very cool but a _long_ way from LEO and the shuttle. We're in X-15
territory - apples and oranges.

Cheers,

Adrian (who still wants to be an astronaut :-)