Team System training - what should it look like?
I've been having converstations with one of my coworkers about Team System training. We have done a couple Whidbey-focused classes (that include some Team System) already, but VSTS is not very applicable to people's jobs just yet. I figure that there will be some VSTS adoption when Beta 2 comes out, though I don't know how much. I'd like to get some thoughts from those of you looking at VSTS, to see what your thoughts are from two perspectives. The first is what training should be available (I'll get to that in a moment), and the second is timing.
So first, the content - Team System is different than most MS products in that not only will developers and architects need training, so will project managers, business analysts, testers and development managers. There could even be some basic overview training for IT executives and business users. Project managers need to know how to manage using the work item database and MS Project. Testers will need to be trained on work items as well as test case creation and management. Business analysts will need to know about work items as well, and potentially the whole team should have some clue on the MSF flavors. Lastly, there is that cool project portal with reporting that could probably be covered in 1-2 hours with those people that aren't part of the development effort, but care about it (users and executives). I think this last one could be a recorded training session that they just watch as a group at their offices. Alternately an instructor led webcast when the trainer isn't onsite.
My thoughts are to section the content with a 1-2 training class on process and work item tracking. Then have a half to full day for PMs, a half to full day for BAs, and 1-2 days for testers. Obviously there will be dev/arch training as well. Add all this up and I end up cycling a lot of people in/out and have about 2 weeks of training to get all the parties involved. Obviously, the customer could pick and choose whether or not to even traing their people in the variety of ways. That's option 1, and probably the easiest to pull off.
I've also thought (I really would like some comments on this idea) about teaching it with the full flow of the process. Start the class with an overview, get into BA stuff, then give the BAs a lab. While the BAs are working on their lab, cover PM stuff, then give them a lab, then start into architecture/design, etc. The nice thing is that the lab the BAs do will be to create the requirements docs that will be used for the architecture/design labs. The PMs will be creating tasks and making work items, etc. While this idea sounds really neat to me, I don't know if it will work from a timing perspective to keep the class moving. In this scenario, the entire class would share one Team Foundation Server and all be TFS clients, as they would in the "real world".
The other item we've been discussing is public training. While I anticipate a lot of private training classes - where we go to the client and teach an entire team (maybe combined with consulting to help them install and configure TFS), I'm curious if there will be demand for public training. At some point there will be, to deal with new hires, etc. I'm just not sure when. I don't want to be one of those companies that throw out dates for public classes just to see if it "sticks", and then cancel it when only one person signs up. Anyone have any ideas?