Tobin Titus

> Perhaps the personas have come to mean
> more in the field than they were intended
> to mean in Redmond.  
I completely agree, which is why the personas were meant to be used internally and were never meant to provide any type of "guidelines" to the "field".  My copies of these persona documents say "Microsoft Confidential", I would imagine yours, if you were provided with them, were the same.  If you weren't provided with them, I still fail to see how you can comment on them appropriately.

> Funny how cultural stereotypes seem to
> lead to conflict and fragmentation.  
> Makes me wonder why one would need to
> create them, especially when you can
> just get to know the folks directly.

Who said anything about cultural stereotype? These are most definitely stereotypical traits found in the professional development community, and were never meant to fragment - only to identify who is using our products and what their needs are.  It was through our direct contact with folks that we were able to come up with these personas. I'm not at liberty to discuss the process by which the personas were created, but I assure you that it was through communication with the public.  While we are saying "Jim wants this feature, John wants that feature, and oh, hey, Tim wants the same feature as Jim", we might as well start trying to identify why Tim and Jim want the same features and what type of things they are doing, how they work and what we can do to help them succeed. I'm sure even in your own process that you have a way to identify your target audience, their needs, and how you intend to meet those needs, do you not?

> I don't think I'll be moving into the
> frigid north any time soon, so I expect
> that I'll keep giving feedback through my
> blog, as I've done for the past couple of
> years, as well as through my lectures and
> workshops.
And we'll keep listening as long as you are providing feedback. We value that feedback, good or bad, more than can be expressed. It's not just a slogan. I see people in here busting their humps day in and day out.  I come into work between 5 and 7am and don't leave until odd hours of the night. I do this trying to fulfill my commitments to my team, my division, my company, and ultimately to _my_ customers.  The impressive thing is that I see cars here when I get in every morning, and there are still cars here when I leave -- german and japanese cars if that tells you anything!  I read blogs, I look for input and displeasure with our product. I look for satisfied customers and raving fans as much as I look for customers who are upset, customers who are mad, and customers who have down-right had it.  I was one of those customers! http://aspnetpro.com/opinion/2004/09/asp200409jg_o/asp200409jg_o.asp  It was a caring individual who stepped up and listened to me that kept me from flipping off the deep end.  I don't say any of that to gain your sympathy.  We _earned_ a good number of those complaints, and its only right that we _earn_ that trust back by paying attention to our mistakes.

> If you want to come to Austin and spend
> some time with a team of agile
> practitioners and learn about the ways
> and means of a persona that Microsoft
> has yet to recognize either by formal
> stereotype, through applicable features,
> or informed practice guidance, drop me
> a line..
I would love nothing more than to head to Austin. However, I'm probably not the best person to talk to about process.  It might be better to send some of the guys from the VSTS team your way.  Next time I'm in town though, I may take you up on your offer (I was born in Texas!) In any case, I would venture to say that the VSTS team has their own personas outside of the three _developer_ personas you've seen. I wouldn't expect to see process guidance make their way into the developer personas as these are strictly technical construction skillsets and behavior.

As always, I do appreciate the time that the MVPs such as yourself take to provide feedback -- I was an MVP myself (ever so briefly) so I understand the commitment you put into everything.  Thanks again.

> I can't comment on the personas as they are
> portrayed in your docs, and indeed I'm not
> commenting on them.  I am commenting on the
> personas as they exist in the wild.  On
> these, I can comment appropriately.

So what's your beef with Microsoft in all of this then?  If you are commenting on how others portray the personas, then you can't get your nose out of joint with Microsoft over that.

> Usability personas are stereotypes.  I
> understand that they can be useful in trying
> to get a conceptual grasp on remote
> customers, but in the end they're still
> models, estimations, and analogues.  They're
> arbitrary and artificial boundaries drawn
> around a set of real, observed behaviors.  
> The risk comes when these kinds of analogues
> are attempted to be overlayed back on the
> humans from which their traits were
> derived.  It has the potential to lead to as
> much prejudice and ignorance as to insight.

I agree that some have mistakenly asked "what kind of developer are you?" and other such pointless questions.  These personas were not meant to draw "arbitrary boundaries" around the community. It's unfortunate, in my opinion, that this has happened.  It's even more unfortunate that several people have brought more attention to the personas and asserted that they were, indeed, for that purpose.

> You can earn my trust back by drastically
> shortening the release cycles and getting
> out solutions to the most common complaints
> logged in the product feedback center

I would highly doubt that we would gain your trust back if we shortened a release cycle and produced a bad product.  It's very interesting that if we did please you by shortening the cycle, we would likely displease other groups who complain that we release too often already.  We have to put our emphasis on good software and not so much on the timelines.

> not merely the bug fixes (although it would
> be nice to have those first).  This you can
> do by engaging in more Test-Driven
> development,

And there it is. All the world's problems are nails, and they can _only_ be solved with the agile-hammer.  This is a very narrow view, IMHO, but one you are obviously going to stick to.  Microsoft is attempting to address this audience as of late, and I'm sure you've seen that.  The fact that we aren't where YOU want us to be in that process is regretible.

> which will necessarily shape
> the software in more and more, ever smaller
> instances of plug-in patterns and allow for
> more frequent release of smaller, isolated
> chunks of functionality.  Pushing off a til
> a Q3-2006 or to Orcas is one of the most
> glaring examples of Microsoft's lack of
> agility.
Smaller, isolated chunks of functionality would not neccessarily please the largest group of developers.  Microsoft already gets complaints that they change things too quickly.  Microsoft doesn't want to be agile just to fulfill their buzzword factor. They strive to meet customer need in a way that make some sort of business sense.


> Who's talking about process?  RUP is a
> process.  MSF is a process.  I'm talking
> about tactical programming methods.  There
> are certainly project management aspects of
> Extreme Programming, but they are there
> mostly to bring project management in line
> with the agile approaches to laying down
> code.

Agile zealots typically try to muddy this water to hide the fact that agile methods affect process deeply. Say what you will, but even the most "extreme" xp evangelists out there accidentally slip up and call it a process.