Agile And Tsp Discussion

I am researching (comparing and contrasting) PSP (PersonalSoftwareProcess) and TSP (TeamSoftwareProcess) with agile methods. As part of this, I'm looking for opportunities to pilot (measure, deploy, and measure again) PairProgramming and TestDrivenDevelopment within my company, both independently and in combination with TSP.

The only posts I could find here referring to actual or anticipated experience were:

ExtremePspExperience, which was awfully interesting, but only one PSP assignment and not an actual project or TSP project
LaurieWilliams' PhD thesis comparing PSP to CSP (CollaborativeSoftwareProcess, a PSP-based process which includes PairProgramming)
ToddPasley's thesis in progress, which "... plays on the TooMuchDocumentation mentality of XP demonstrated by XpAndDocuments and how some individual data collections (practices of PersonalSoftwareProcess) maybe be deemed as inclusive in 'Just Enough Documentation' if it can be found to better achieve the GoalsOfExtremeProgramming??"

Anyone else out there doing anything like this, know of anyone else doing it, or interested in it? -- KarenSmiley, August 14, 2003

Karen, I did a text search on 'tsp' in Wiki (FindPage, second text box) and got 21 results. A couple were in reference to TravelingSalesmanProblem, but most were for TeamSoftwareProcess. You might want to repeat the search and see if there's some good info there.

Actually, I did text searches in Wiki for 'PSP', 'Personal Software Process', 'TSP', and 'Team Software Process' before posting this ;) and looked at all of the page matches. I found a few places where TSP was being discussed, and put in links to the new TeamSoftwareProcess page; but at the time, I only found the two items above on experiences or research in combining PSP or TSP with anything agile. I will try the searches again periodically, though. I searched http://www.seir.sei.cmu.edu and found nothing. I'm also searching the Internet in general (no luck yet), and I'll post here links to anything interesting that I come across. Thanks! -- KarenSmiley, Sept. 15, 2003

Added ToddPasley thesis link to list above - Sept. 19, 2003

Great discussion on this topic at TriangleXpMeetingNine (Sept. 22, 2003) of the TriangleXpUsersGroup

9/30/2003 New AgileTeams discussion group created to supplement this page (will allow file sharing, etc.) - http://groups.yahoo.com/group/agileteams/ . Just send email to mailto:agileteams-subscribe@yahoogroups.com to join!

Relevant presentations at the First TSP Users Group Conference, Sept. 2003: (http://www.sei.cmu.edu/tsp/user-group.html - unfortunately, SEI no longer has the 2003 presentations online)

Adding daily scrum meetings to a TSP project - www.sei.cmu.edu/tsp/tug-2003-presentations/vanburen-webb/
Using FeatureDrivenDevelopment with TSP -
Comparison of AgileProcesses and TeamSoftwareProcess - www.sei.cmu.edu/tsp/tug-2003-presentations/smiley/

The TUG 2003 version and a newer version of my paper "Comparing Agile and TSP" are still available online at

http://www.agileteams.com/paper_CATSP.html.

Also, I presented "Agility and the Team Software Process" at the RtpSpin's March 2004 meeting; see

http://www.rtpspin.org/meeting.html and http://www.agileteams.com/paper_AATSP.html.

There were a few papers at SEPG 2004 on combining agile and TSP. (I gave a presentation there, but no, mine actually wasn't on that topic!) See the SEPG 2004 site and look for titles "Agile TSP" and "Extreme TSP".

(http://www.sei.cmu.edu/sepg/)

-- KarenSmiley

Here's a link to a report from the SEI discussing how TSP/ PSP and Agile methods are complementary. It's called 'CMMI or Agile: Why Not Embrace Both!':

http://www.sei.cmu.edu/library/abstracts/reports/08tn003.cfm

I worked on a project a few years back at Microsoft using TSP/PSP. Some of the issues might have been in the application of TSP/PSP in that scenario, but I doubt it given that there were two TSP/PSP "experts" working with the project. TSP/PSP is about as rigid as it gets. SDLC waterfall seems downright nimble compared to TSP/PSP. Got to where we referred to filling out our TSP tracking sheets to "filling out our TPS reports". It tries to control every single aspect of building something, and as a result the team spent 80% of their time trying to figure out and execute the next step in TSP/PSP instead of building product. TSP/PSP is the process to follow in software if you want your project to fail and need to spend 3x as much money as normal making that happen. -- Chris Cole

I worked on a project a few years back at Microsoft using TSP/PSP. . . -- Chris Cole

I'm sorry you've been ruined for life by typical Microsoft mismanagement. Watts himself warned against the use of PSP in such a way. While he prescribes a waterfall-like process for the purposes of teaching the concepts, he specifically mentions that you should customize the techniques after course completion to your specific process.

I use PSP with TDD frequently, for example, and I don't find it very overbearing at all. I use a Fossil instance just to keep track of my time (much lighter weight than Jira, and as well, keeps my private info private). I also keep track of the number of defects found, where they were injected and resolved, but not specifically the kinds.

My phases are planning (but only if needed), design (I like to use cleanroom blackbox and statebox representations, but skip clearbox in most cases). Then comes "code and unit test" phase, where I use TDD. Then comes integration test, documentation (where I transcribe the current design, as distinct from the initial design concept, into human-readable form on a wiki), and finally, post-mortem to crunch my personal stats.

Things I don't do (often):

Planning. I'll write up a plan if someone comes to me with a project large enough that it has a deadline, if they want regular status reports, or if I'm given a budget. This almost never happens in my line of work, so I skip this "phase".
Earned value planning and reporting. I probably should do this, but my deliverables as a QE don't often have deadlines, so there's no real point in building an EV chart. I find lean-style ContinuousFlowDiagrams? and YesterdaysWeather are, combined, a GoodEnough approximation for my estimation needs.
Distinguish between high- and detailed-level designs. I just don't operate at that level of abstraction.

Metrics I collect and analyze:

How long it takes me to go from phase to phase. If I notice I'm spending 3x time in integration test as I do in code-and-unit-test, then that's a red-flag that I either didn't understand my 3rd-party dependency interfaces well enough, or that said 3rd party dependencies are horribly buggy. In the former case, I need to spend more time in the design phase not just studying, but also confirming, my dependencies (in Cleanroom terms, acquiring "intellectual control" over my dependencies).
How many defects I inject in which phase. This data helps in arriving at a design review checklist for myself.
How many defects I remove in which phase. This data helps in arriving at a design review checklist for myself.
The kinds of defects I encounter. This data helps in arriving at a code review checklist which I go through before I submit a pull request. Nothing sucks more than having a PR open for months because of a bunch of niggley little details that would have been addressed in only a few hours with the aid of a good checklist. I learned my lesson on that first-hand, which is what got me into self-studying PSP to begin with.

That's pretty much it. My adaptation of PSP is pretty slim compared to what's in the book.

Full disclaimer: I've never been through the course. I just don't feel I need to. The book is plenty self-explanatory.

-- SamuelFalvo?

CategoryAgileMethodology CategoryMethodology CategoryComparisons CategoryDiscussion