Visual Studio 2010 Webcasts

Visual Studio 2010 and MSDN are BIG – and they are getting bigger!  In this session, we’ll explore all the changes to the Visual Studio family of products, including Team Foundation Server as well as recent upgrades and changes to our MSDN line-up.  Please join us for a 60 minute “CAN’T MISS” – high level overview, where we will discuss the many changes to our offerings which will likely impact current customers and future customers.  We promise you won’t be disappointed!

Speaker: Tim Adams, Tony Jimenez and Randy Pagels, Microsoft Corporation

Date	Time	Join the Meeting	Audio Call Only	Conference Call ID
Tuesday, 10/27	9:00 AM- 10:30 AM (CST)	Join the meeting	1-888-320-3585 [English]	438667128
Thursday, 10/29	2:00 PM- 3:30 PM (CST)	Join the meeting	1-888-320-3585 [English]	438667128
Tuesday, 11/3	9:00 AM- 10:30 AM (CST)	Join the meeting	1-888-320-3585 [English]	438667128
Thursday, 11/5	2:00 PM- 3:30 PM (CST)	Join the meeting	1-888-320-3585 [English]	438667128

The Agile Adoption Mixing Board

When I talk to clients about adopting the basic values from the Agile Manifesto, I tell them to imagine sliders between the four entries on the left and right. A good adoption is like mixing a band and as the band plays you adjust the mix constantly to get the best sound. Purists may claim you must adopt each value to its fullest which is like sliding all the sliders on the mixing board to one side which never sounds very good.

I’ve had a client who had recently invested in offshore resources and a new remote office for the development teams. They could not immediately get the development team together so they could not fully embrace the “Individuals & Interactions” value or some of the practices attributed to it. So we used some tools like Skype, WebEx, and Team Foundation Server and put in a little process around communications between the sites to help retain some of the collaborative aspects of the team. So I see this like moving the slider on my Agile mixing board a little over to the right and the “Process & Tools” side. This client does see the value of having everyone together so there is a plan that once they can feasibly move development to one location, they will do so. And when they do we can remove some of the processes put in place and stop using the tools so the slider moves back to the left a little more.

Claims that you must adopt Agile in its entirety and never change your adoption to meet your current environment are not very practical for some companies. I definitely think you should always evaluate the impediments you perceive are preventing you from transitioning to Agile practices to ensure you are not reverting to muscle memory, but there are definitely real world scenarios that can make some adoptions possibly detrimental to the business if immediately (and blindly) adopted. I like this blog from Ryan Cooper about how conflict can arise from these situations.

So I think good Agile coaches are like good sound men who are constantly listening to the band and as the environment changes they adjust the mix appropriately. We listen to the team and the stakeholders to determine how much to adopt and what may have to wait for later. Anything that you do determine should wait needs to be logged with the following details:

• What it is exactly you are not going to adopt.
• What the benefit of adopting it would be.
• The cost of not adopting the practice.
• “Smells” that will indicate you should definitely adopt the practice.

This way we acknowledge that we are not adopting one of the best practices prescribed by Agile (or whatever flavor we are adopting) and then outline the cost and the return for justification later if the smells start to occur. This adoption log can also be great fodder for retrospectives.

So listen to your team and be vigilant when the environment changes so that you adjust your mix of Agile adoption to best fit the situation.

Visit with the Team System 2010 Team in Raleigh, NC

Last week I had to opportunity to visit with the team working on Team System in Raleigh, NC. I contacted Jason Barile via Twitter a few weeks before and asked if I could stop by and he went all out to accommodate me and a few coworkers. I was pleasantly surprised when the meeting started and most of the Product Managers and Test Leads for the build, test, source control, and install/administration parts of Team Foundation Server were in attendance.

We talked about many aspects of VSTS 2010 during the meeting:

• How TFS Basic can be a "gateway drug" for those wanting to move from Visual SourceSafe but are not going to use all the features of the Team Foundation Server platform. The team talked about how easy it will be to upgrade from basic to the full version and that all your history will immediately be dumped into the warehouse as soon as you upgrade and your history will look as if the warehouse was installed from day one.
• There was plenty of discussion around implementing Agile practices with Team System and how much more tools will be available in 2010 to support those practices. There are plenty of new additions coming from Conchango to continue their support for Scrum in Team System.
• We spent some time talking about all the new offerings around testing that I was especially interested in since my company sold our QA product suite so there was a new gap in our offerings around automated feature testing that VSTS 2010 will fill in very nicely.
• My team was very excited that the upcoming VSTS 2010 Beta 2 release will include a go live license so some of our clients interested in early adoption can go ahead and implement this release with some support from Microsoft and a direct upgrade path to the final release.

After the meeting we went to lunch with Jason, Buck Hodges, and Adam Barr and continue our conversation. It was interesting during lunch when Jason brought up my views on exclusive check out I expressed in my interview with David Starr from the Elegant Code Cast. I explained that as a consultant I am dropped into teams of various make ups and not all of them have good practices around source control implemented even when they are using TFS. I have frequently had issues with developers making changes to solution and project files with shared check out and not being diligent when merging changes into source control. This has resulted in broken builds, missing files, etc. and me pulling my hair out. It has also been an issue with projects that have not implement good development practices like the SOLID principles and I have had entire data access layers in one class and people constantly stepping on each other's toes. I've had to adapt my source control practices to work around some situations like these that as a contractor I had little control over and no ability to change.

Below is a short (and poorly shot) video of the Microsoft team in Raleigh and a quick, walking interview with Buck, Adam, and Jason on their favorite features in VSTS 2010.