Here's an idea - probably too time consuming (though I'm beginning to think
that Ron Jeffries is a Time Lord, what with all the stuff he does..)

I don't mind seeing agile products, as long as I don't feel I'm getting
tricked while looking at the product website. For instance, I'm instantly
turned off the second a website asks me to enter my name and company for the
privilege of viewing their product. On the other had, I'm more than willing
to look at and even try a product if I can do it anonymously and within 2
clicks of visiting the product website.

So, my idea is to allow a product if it obeys these rules:

1) I don't have to enter any info to try/view the product
2) I don't have to weed through marketing literature (2 click max) to get to
the product demo.

Chris.

On 11/30/06, Ron Jeffries <ronjeffries <at> xprogramming.com> wrote:
>
> Hello, members. On Thursday, November 30, 2006, at 5:20:31 AM,
> Michael wrote:
>
> > TargetProcess Company is pleased to announce the release of
> > TargetProcess v.2 <http://www.targetprocess.com> , the next generation
> > project management software
> > product for agile projects.
>
> Question: Should this have been permitted, on the basis of being an
> avowedly agile-focused product, or not?
>
> Thanks,
>
> Ron Jeffries
> www.XProgramming.com
> To tolerate a problem is to insist on it. -- Software for Your Head
>
>
>
> To Post a message, send it to: extremeprogramming <at> eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe <at> eGroups.com
>
> ad-free courtesy of objectmentor.com
> Yahoo! Groups Links
>
>
>
>

--
--
Chris Wheeler
chriswheeler.blogspot.com
coach, programmer & practitioner

[Non-text portions of this message have been removed]

•  33
  New Members
•  1
  New Links

Hello, Chris. On Thursday, November 30, 2006, at 8:31:12 PM, you
wrote:

> Here's an idea - probably too time consuming (though I'm beginning to think
> that Ron Jeffries is a Time Lord, what with all the stuff he does..)

Bummer. Outed.

> So, my idea is to allow a product if it obeys these rules:

> 1) I don't have to enter any info to try/view the product
> 2) I don't have to weed through marketing literature (2 click max) to get to
> the product demo.

I've polled the most conveniently available moderator, and he says
he's not going to test the proposed product announcements to see if
they pass these criteria. He likes them, though, that detail aside.

Ron Jeffries
www.XProgramming.com
Prediction is very difficult, especially if it's about the future. -- Niels Bohr

•  33
  New Members
•  1
  New Links

Hello, yahoogroups. On Thursday, November 30, 2006, at 10:06:50
AM, you wrote:

> I ignored it in the queue for several days. Someone else approved it.
> The reason I ignored it was overselling - one of the issues we try
> to get people to look at is whether they need an automated project
> management system at all. Some projects do, some don't.

> This product may bring something useful for certain environments,
> but I don't see it in the brief overview.

> I personally don't see any difficulty with product announcements
> in general; what I don't like is products that hit the wrong end of
> what we are, in general, advocating.

I approved it, reluctantly, on the grounds that knowing is better
than not knowing. But I didn't upgrade the poster: left him
moderated. Also we were spammed with a second announcement from
someone else at the company. I rejected that one.

The product struck me as apparently heavy, and not all that
well-described. I was cusped about it, gave it the benefit of the
doubt, but though I'd inquire what the People think ...

Ron Jeffries
www.XProgramming.com
To Fly, Flip Away Backhanded -- Master Frisbee

•  33
  New Members
•  1
  New Links

Shooting in the Dark
Ron Jeffries
11/29/2006

While we wait for the estimates to come rolling in, and before I
forget, here's a report on our work so far on the Shot Pattern
Analysis program.

http://www.xprogramming.com/xpmag/dbcShootingInTheDark.htm

Ron Jeffries
www.XProgramming.com
Assume that anything you didn't like was the funny stuff.
-- Jim Shore

•  33
  New Members
•  1
  New Links

Charlie Poole wrote:

> This came up in another thread and thoroughly shocked me.
> Apparently, folks are coming along and "discovering" TDD
> without realizing that you do the tests first.

Just after you posted that, someone posted this awesome rant to the Rails
mailing list:

Taylor Strait wrote:

Subject: [Rails] TDD killing my joy of Rails

> I've been working through the book 'Beginning Ruby on Rails E-Commerce'
> which is very heavy on Test Driven Development. As in, you have to
> write tests for scaffolding methods and validations and crap like that.
> And then they fail. And you KNOW its the test not the method. So you
> spend 2x the time writing a test that has to be adapted when
> requirements change. You really are doubling / tripling your code.
>
> Rails went from fun ActiveRecord magic tricks to a world of 'TEST
> FAILED.' As a beginning Rails developer it has really taken all the fun
> out of RoR development. Is TDD so much better than writing methods and
> testing using a combination of the application interface and Navicat to
> check the database? Because I hate it.

Translation:

Rails was invented via Developer-Centric Testing. So Rails is flexible,
powerful, well-factored, and fun to play with.

However, some of the books lean on TDD (because some of the authors lean on
it). So even if TDD for legacy GUIs is still hard, TDD for your
database-driving stuff is still easy and mission-critical.

So someone's first introduction to TDD comes in the form of a _requirement_
in a book on the mission-critical stuff in a Logic Layer. So instead of
learning TDD from scratch, in a sample project, and instead of understanding
the ideal of minimizing keystrokes between passing tests, someone has got
themselves stuck in arbitrarily failing tests, and then debugging to make
the tests pass.

Growing pains, folks!

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

•  32
  New Members
•  1
  New Links

Hi all,

We will have the next meeting of the Agile-Carolinas group on
Wednesday, Dec 13th.

Ken Auer will lead a discussion on: "the continuous refinement of
XP". Meaning: the refinement of requirements, design, results,
plan, and people.

Ken Auer is the founder and president of RoleModel Software. He has
over twenty years of experience in agile software development in a
variety of roles from developer to management. Ken has been active
in the development of object oriented software since 1985 and has
been well known as a speaker and participant in many industry wide
conferences. He founded RoleModel Software in 1997. In late 1998,
RoleModel Software began building the first "Extreme Programming
Software Studio" based on his vision. This is a place where
apprentices, skilled journeyman, and software masters work together
in an environment of continuous learning with extremely effective
modes of collaboration to produce unusually adaptable and robust
software for its clients. He is also the co-author of "Extreme
Programming Applied", published by Addison-Wesley in October 2001.

We have a great group of people and you will enjoy the discussion.

The meeting will start at 6:00pm with free pizza and networking. At
6:30pm Ken will start his talk/discussion and we will go until 8:00pm
or so. Location in Charlotte:
Room 101, Cameron Applied Research Center on Craver Rd, UNC-Charlotte Campus
Parking: http://facilities.uncc.edu/maps/files/CampusMap8_5x11.pdf
Park in Cone Visitor Lot, walk to Cameron, building 42 on the map.
Mapquest:
http://www.mapquest.com/maps/map.adp?formtype=address&addtohistory=&address=%5b1670%2d1699%5d%20University%20Walk%20Cir&city=Charlotte&state=NC&zipcode=28213&country=US&location=gaimZKL18IwbOVyDNNw92MecjakLZtkwS9lD2lqHGKBqoWiFuMEcIGoxG4Vs5bzm%2bmIbfRMBrY5bGheVIRkag3A3%2bEuqLjoumfmLiXoTPhOq1ysNxUzYn0m0c%2bELMTYhhsoHnsRYokb4qrEU8RNlSBlj% 2fh3eKgEnMPakELSYy3E%3d&ambiguity=1

Please RSVP to jhlittle <at> kittyhawkconsulting.com if you will be attending.

The Agile-Carolinas group has the following resources. You may join
there also, for free:
Web site: http://agile-carolinas.pbwiki.com/
Discussion group: http://finance.groups.yahoo.com/group/agile-carolinas/

Your interest and comments regarding Agile-Carolinas are welcome.
Happy to answer any questions you may have.

Please also pass this on to a colleague or others who may be interested.

Thanks, Joe

Joseph Little
917-887-1669 (cell)

[Non-text portions of this message have been removed]

•  32
  New Members
•  1
  New Links

> The "travel light" principle. One should attempt any endeavor with
simple
> tools, and with XP values, then see if they scale. If you go in the
other
> direction, you will have trouble removing Things if you can't tell
you don't
> really need.

Yes, I do agree with that. We never recommend to start right from
TargetProcess if customer is completely new to agile. But "travel
light" is abstract principle and "light" for one company will be
"heavy" for another.

>
> Michael wrote:
>
> > Why do you think agile project management is not demand
> > any tools excepts traditional XP? Iterative development
> > is not a new concept and why it should not be supported
> > by web based tools? How can you inject it into remote teams without
> > such tools?
>
> The "travel light" principle. One should attempt any endeavor with
simple
> tools, and with XP values, then see if they scale. If you go in the
other
> direction, you will have trouble removing Things if you can't tell
you don't
> really need.
>
> This applies to any complexity situation. "Things" could be:
>
> - excess lines of code
> - excess heavy databases
> - excess paperwork in your shop
> - excess teammates
> - excess consultants
> - excess supporting tools
>
> It's generally easier to start simple and add the complexity that
you find
> you need. It's generally much harder to start complex and then
identify and
> remove the elements you _don't_ need.
>
> --
> Phlip
> http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
>

•  34
  New Members
•  1
  New Links

>The product struck me as apparently heavy, and not all that
>well-described. I was cusped about it, gave it the benefit of the
>doubt, but though I'd inquire what the People think ...

I am really want to discuss about "heaviness" in TargetProcess. We've
tried made it as simple as possible, and if we've failed somewhere we
will improve for sure. For me "heaviness" is usage pain. How many
clicks/actions developer or team lead should make to complete the
goal? How much time the tool usage takes each day? On our opinion
TargetProcess supplements usual XP tools like cards and white boards.
Sho why it is heavy?

Michael
http://www.targetprocess.com

--- In extremeprogramming <at> yahoogroups.com, Ron Jeffries
<ronjeffries <at> ...> wrote:
>
> Hello, yahoogroups. On Thursday, November 30, 2006, at 10:06:50
> AM, you wrote:
>
> > I ignored it in the queue for several days. Someone else approved it.
> > The reason I ignored it was overselling - one of the issues we try
> > to get people to look at is whether they need an automated project
> > management system at all. Some projects do, some don't.
>
> > This product may bring something useful for certain environments,
> > but I don't see it in the brief overview.
>
> > I personally don't see any difficulty with product announcements
> > in general; what I don't like is products that hit the wrong end of
> > what we are, in general, advocating.
>
> I approved it, reluctantly, on the grounds that knowing is better
> than not knowing. But I didn't upgrade the poster: left him
> moderated. Also we were spammed with a second announcement from
> someone else at the company. I rejected that one.
>
> The product struck me as apparently heavy, and not all that
> well-described. I was cusped about it, gave it the benefit of the
> doubt, but though I'd inquire what the People think ...
>
> Ron Jeffries
> www.XProgramming.com
> To Fly, Flip Away Backhanded -- Master Frisbee
>

•  35
  New Members
•  1
  New Links

Hello, Michael. On Friday, December 1, 2006, at 5:24:20 AM, you
wrote:

>>The product struck me as apparently heavy, and not all that
>>well-described. I was cusped about it, gave it the benefit of the
>>doubt, but though I'd inquire what the People think ...

> I am really want to discuss about "heaviness" in TargetProcess. We've
> tried made it as simple as possible, and if we've failed somewhere we
> will improve for sure. For me "heaviness" is usage pain. How many
> clicks/actions developer or team lead should make to complete the
> goal? How much time the tool usage takes each day? On our opinion
> TargetProcess supplements usual XP tools like cards and white boards.
> Sho why it is heavy?

In my post, heaviness refers not to how easy the product is to use,
but the kind of process it implements. In fact, a process that goes
beyond cards and whiteboards is heavier than one that doesn't.

I have not tried the product, so do not know in detail how heavy or
light a process it evokes, but I notice that it has:

A bug list -- not a good sign in my opinion ...
Time tracking -- not the first Agile chart I'd draw ...
Projects -- are these what XP would call stories? With ...
Priority, Status, Effort, Progress, Time Spent, Time Remaining
(Which, because the tool has them, are all likely to be used.)
No less than 5 (five!) tabs of information for each project ...
Customization -- which could be good, given how complex an
approach it seems to handle ...
The stars are all red, and I wanted some white and blue ones ...
A "burn down" chart that I don't understand at all, with an
apparent "effort" focus. Maybe that just means points or story
size, I'm not sure ...
An apparent focus on work assignment rather than dynamic work
selection ...
Bug Tracking with nine or a dozen columns of information ...
Complex bug addition page -- really planning to have lots of
defects I guess ...
Bug event list -- so we can be all over those bug fixers ...
Screenshot bug capture looks pretty cool, I must admit!
"Dozen of features and patterns" -- seems a lot. (Did you mean
"dozens", by the way? Or "many"?)
Workflow -- ?
Requirements info stored in the tool instead of in conversation
and tests ...

This quote is an example of what troubles me:

What Should I Do Today?

This is the top question for any developer. Some of us write tasks
on cards, others keeps all tasks in mind, in email Inbox, some use
various productivity tools. TargetProcess provides an integrated
ToDo list for all assignments, including user stories, tasks and
bugs.

I don't see why it's really helpful, on an Agile team, to ...
Have a computerized list at all ...
Use a computer to keep track of what could be on the wall ...
Record "all" "assignments" ...

Big enough team, distributed enough, sure ... and those are the
things John Roth was talking about that we are pushing against
people doing at all.

That's not to say that people don't do them, and don't need to do
them. But will this product help people do what they should be
fixing?

Overall, it looks like a good-looking tool into which much work has
gone. I don't see, for myself, how it is that it enhances the things
I like to see Agile projects doing. I do imagine that if you can get
people to try it, many of them will use it. I'm not sure that's a
good thing, but I am known to be a fanatic.

Ron Jeffries
www.XProgramming.com
Thousands of years ago, the first man discovered how to make fire.
He was probably burned at the stake he had taught his brothers to
light - Howard Roark (The Fountainhead, Ayn Rand)

•  34
  New Members
•  1
  New Links

I see quite large gap between what we want to put into TargetProcess
and your comments. Maybe it is our fault.

> A bug list -- not a good sign in my opinion ...

Do you really not have bugs in your projects? At least you should
handle them like user stories. TargetProcess do exactly that.

> Time tracking -- not the first Agile chart I'd draw ...

Time Tracking can be switched off. And there will be no
such columns as Time Spent, Time Remaining etc.
We've tried to make TP flexible. If you don't need time tracking,
turn it off and all time related parts will be removed from UI.

> Projects -- are these what XP would call stories? With ...

Projects are projects. Company may have many projects to work on
and XP stories are represented by "user stories" in TP
(inside exact project). TargetProcess is not a tool for only one
project, it supports multiple projects as well.

> Priority, Status, Effort, Progress, Time Spent, Time Remaining
> (Which, because the tool has them, are all likely to be used.)

Almost all of these columns calculated automatically except Priority
and Effort (in points) which are set manually.
You set Priority (Business Value) and Effort on cards in anyway!

> A "burn down" chart that I don't understand at all, with an
> apparent "effort" focus. Maybe that just means points or story
> size, I'm not sure ...

Burn down is natural, maybe we should put more info about it. Burn
down measures remaining effort units (points or ideal hours, since
different teams prefer different units).

> An apparent focus on work assignment rather than dynamic work
> selection ...

Yes, that is maybe right. We will try to improve here.

> Bug Tracking with nine or a dozen columns of information ...
> Complex bug addition page -- really planning to have lots of
> defects I guess ...

You may use just one field - bug name. Other fields are optional
and there are 7-9 fields in total. Is it really complex?
Bugzilla has 25 fields!

> Workflow -- ?

Simple state management. For example, bug workflow may be different
in different companies.

> Requirements info stored in the tool instead of in conversation
> and tests ...

TP does not foce you to store requirements in the tool.
You may do that, but may not. In fact tool implementation
often is not about the tool, it is about the people.
If project manager or team lead will be wise and know how to
lead the team effectively, she will not burden the process,
but will use the tool to increase efficiency. If not, no one
can help.

Michael
http://www.targetprocess.com


--- In extremeprogramming <at> yahoogroups.com, Ron Jeffries
<ronjeffries <at> ...> wrote:
>
> Hello, Michael. On Friday, December 1, 2006, at 5:24:20 AM, you
> wrote:
>
> >>The product struck me as apparently heavy, and not all that
> >>well-described. I was cusped about it, gave it the benefit of the
> >>doubt, but though I'd inquire what the People think ...
>
> > I am really want to discuss about "heaviness" in TargetProcess. We've
> > tried made it as simple as possible, and if we've failed somewhere we
> > will improve for sure. For me "heaviness" is usage pain. How many
> > clicks/actions developer or team lead should make to complete the
> > goal? How much time the tool usage takes each day? On our opinion
> > TargetProcess supplements usual XP tools like cards and white boards.
> > Sho why it is heavy?
>
> In my post, heaviness refers not to how easy the product is to use,
> but the kind of process it implements. In fact, a process that goes
> beyond cards and whiteboards is heavier than one that doesn't.
>
> I have not tried the product, so do not know in detail how heavy or
> light a process it evokes, but I notice that it has:
>
> A bug list -- not a good sign in my opinion ...
> Time tracking -- not the first Agile chart I'd draw ...
> Projects -- are these what XP would call stories? With ...
> Priority, Status, Effort, Progress, Time Spent, Time Remaining
> (Which, because the tool has them, are all likely to be used.)
> No less than 5 (five!) tabs of information for each project ...
> Customization -- which could be good, given how complex an
> approach it seems to handle ...
> The stars are all red, and I wanted some white and blue ones ...
> A "burn down" chart that I don't understand at all, with an
> apparent "effort" focus. Maybe that just means points or story
> size, I'm not sure ...
> An apparent focus on work assignment rather than dynamic work
> selection ...
> Bug Tracking with nine or a dozen columns of information ...
> Complex bug addition page -- really planning to have lots of
> defects I guess ...
> Bug event list -- so we can be all over those bug fixers ...
> Screenshot bug capture looks pretty cool, I must admit!
> "Dozen of features and patterns" -- seems a lot. (Did you mean
> "dozens", by the way? Or "many"?)
> Workflow -- ?
> Requirements info stored in the tool instead of in conversation
> and tests ...
>
> This quote is an example of what troubles me:
>
> What Should I Do Today?
>
> This is the top question for any developer. Some of us write tasks
> on cards, others keeps all tasks in mind, in email Inbox, some use
> various productivity tools. TargetProcess provides an integrated
> ToDo list for all assignments, including user stories, tasks and
> bugs.
>
> I don't see why it's really helpful, on an Agile team, to ...
> Have a computerized list at all ...
> Use a computer to keep track of what could be on the wall ...
> Record "all" "assignments" ...
>
> Big enough team, distributed enough, sure ... and those are the
> things John Roth was talking about that we are pushing against
> people doing at all.
>
> That's not to say that people don't do them, and don't need to do
> them. But will this product help people do what they should be
> fixing?
>
>
> Overall, it looks like a good-looking tool into which much work has
> gone. I don't see, for myself, how it is that it enhances the things
> I like to see Agile projects doing. I do imagine that if you can get
> people to try it, many of them will use it. I'm not sure that's a
> good thing, but I am known to be a fanatic.
>
> Ron Jeffries
> www.XProgramming.com
> Thousands of years ago, the first man discovered how to make fire.
> He was probably burned at the stake he had taught his brothers to
> light - Howard Roark (The Fountainhead, Ayn Rand)
>

•  34
  New Members
•  1
  New Links