Here are the updated slides for my Getting Agile with TFS 2010 presentation.  I gave this presentation for two lunch and learns at ANT and then earlier this week at the Omaha Team System User Group meeting.  I had a great time giving this presentation multiple times.   Thanks everyone that attended these talks. 

Getting Agile with TFS 2010 Presentation Slides

Mike

I am going to giving two Getting Agile with Team Foundation Server 2010 talks in November, both in Omaha, NE.  On Thursday November 12th, I will be giving the talk for a lunch and learn at Advanced Network Technologies.  You can register for the event here.  On November 24th, I will be giving the talk at the Omaha Team System User Group Meeting.  Here is more information about the event and registration instructions.

This is the same talk as the one I gave at the Heartland Developer Conference in October but I will be using Beta 2 for these two.  Here’s some more details on the presentation and myself.  I look forward to seeing everyone there.

Presentation: Getting Agile with TFS 2010

This presentation will demonstrate a complete two week scrum iteration from the planning meeting to development, testing, and bug fixing to deployment utilizing the features found in Team Foundation Server 2010. New features include gated check-ins for Continuous Integration (CI), Test-Driven Development (TDD), Product Backlog enhancements including hierarchical views and support for multiple teams to work from a single backlog. The presentation also demonstrates the enhancements to the TFS Portal and Web Access to support Agile planning and displaying graphs such as burn-down charts. Each walk through includes a live demonstration of the feature in Visual Studio 2010.

Speaker: Mike Douglas, Deliveron Consulting Services

Mike Douglas is a Solution Consultant at Deliveron Consulting Services where he provides end-to-end solutions and TFS installation, configuration, and custom development for clients.  He has over 11 years experience building enterprise level applications on a variety of .NET technologies including WCF, Web Services, ASP.NET, Disconnected Smart Clients and Data Synchronization, BizTalk, and Team Foundation Server.  Mike enjoys trying to keep up with the constant change and evolution of .NET.  Mike is an experienced presenter having spoken at several Omaha .NET User Group meetings on CSLA.NET, Subsonic, and TFS.  He also spoke at the 2008 ESRI International User Conference on a GIS integration project he helped lead. Mike actively maintains the open source project, Team Deploy, on CodePlex for deploying MSIs using Team Foundation Server.  Mike also enjoys sharing his experiences in Code Generation, CSLA.NET, and TFS on his blog at www.CodeSmartNotHard.com.

Here are the slides from my An Iteration in the Life of an Agile Team with Team System 2010 talk at the 2009 Heartland Developer Conference.  Thanks for everyone that attended.  I had a great time giving the talk and at the rest of the conference.

http://www.codesmartnothard.com/content/binary/agile_vsts2010.zip

If you didn’t get a chance to attend my talk, I am going to be giving the presentation again (This time with beta 2!) at the next Omaha Team System User Group meeting on November 24th.  Check out the Omaha Team System User Group website for more details.

Thanks!

Mike

Our project team supports a couple large enterprise applications. We often find ourselves spending time troubleshooting production support issues.  These tasks end up taking a significant portion of time away from development.  We often put in a quick fix that satisfies the one particular condition that is causing the error.  More than we would like to admit, we unknowingly break another feature or another condition of that feature. 

Our team is working on a changing the way we fix these bugs.  Instead of fixing the bugs directly in code and then manually testing them, we are creating a test (either unit test or automated GUI test) that represents the failing condition.  This test is intended to initially fail.  Then it is the developer’s job to fix the broken test.  This is helpful for a couple reasons.  One, by being able to create a test that fails, this is good evidence that the real issue has been identified .  This should eliminate times where we "think" we see the problem and end up not fixing anything.  Secondly, the developer (and entire team if using a CI build notification process like Team Deploy) will know exactly when this is fixed.  Lastly, by adding these as tests, this condition will be tested forever, every time the tests run.  This will ensure that other fixes down the road won't break this condition of the feature. 

In addition to the benefits, this supports Agile and Test Driven Development.  Just like TDD, this starts with a broken test that the developer will fix.  The TDD term is "Red, Green, Refactor".
This isn't always an easy process.  Everyone thinks it is a good idea, but when it comes to doing it, it takes longer and the tests are often hard to create.  However, I believe the long term benefits greatly outweigh the challenges.  Let me know if works for you.

Code Smart Not Had

Mike