Monday, October 26, 2009

SKU’d again

Another Visual Studio Release and another round of SKU’s. It seems the marketing folks in Redmond that had a hand in this where the same ones that brought us the Vista and Windows 7 product line up.

So here is the basic break down of the Old versus the New SKU’s for Visual Studio 2010.

  • Visual Studio Standard and Visual Studio Professional become VS 2010 Professional
  • Visual Studio Professional with MSDN Premium and Visual Studio Professional with MSDN Professional become VS 2010 Professional with MSDN
  • Visual Studio Team Dev, Database, Architect and Test become VS 2010 Premium with  MSDN
  • The Visual Studio Team Suite becomes VS 2010 Ultimate with MSDN

  Of course Express is still available as before for the hobbyist, as before one for each language. There is also a combo install for express, but quite frankly I haven’t had time to look at it.

Microsoft is also offering an upgrade offer for MSDN Premium subscribers during the “transition” time, that will allow you to activate a premium subscription now and get Ultimate when Visual Studio 2010 is released in or around March of 2010.

In the end I find these marketing name games a pain, I like the seeming simplification, the names are to Windowy for my taste.

Sunday, October 25, 2009

What's New in EF 4

Julie Lerman has posted a Screen cast – What’s new in the Entity Data Model Designer in VS2010. Defiantly worth a look. She covers Complex Types and the new Foreign Key functionality as well as a slew of other changes. The screen cast runs about 20 minutes and can be found at

Tuesday, October 20, 2009

Microsoft has released VS 2010 beta 2 to MSDN and Technet subscribers. General availability is set for the 21st of October.

The UI is greatly improved since beta 1, here are a few screens to wet your appetite while you wait.

The Install start screen.

More install

Install process

The start up screen has been greatly enhanced since beta 1.

There are a number of changes, in fact too many to list in a single entry. Look forward to the continuation of the workflow series shortly..

Thursday, October 15, 2009

Practicing Scrum or Doing Scrum?

If your organization is like any other today, they’re looking for ways to cut costs and deliver on time and for many development teams it means Scrum or some variation.

When you ask your peers what methodology they are using many will say Scrum, but the fact of the matter is Scrum is not a methodology it is a wrapper around existing methodologies. Scrum will work with anything from CMM to XP.

  In the company I’m with now we do sprints, planning and daily stand up meetings. Even doing those things we’re not really practicing Scrum, we’re doing Scrum. We’re just going through the motions and when you do that quality is the first thing to suffer followed by moral. Each sprint becomes a death march and the developers don’t really pay much attention to what is on the backlog, it’ll be rolled forward if it’s not finished. You also begin to see backlog fudge, where some pet project or desire is added because someone felt like that’s what they wanted to do. Inevitably we no longer release or demo functionality to the users and owners at the end of the sprint. We’ve gone from Scrum and XP to “Scrumterfall”  Waterfall with a Scrum veneer.

So how do we bring turn around from just going through the motions to reaping the benefits of practicing Scrum?

  The first thing that needs to be addressed is the backlog. The backlog need to be scrubbed and reprioritized. This process needs to happen on a continual basis, otherwise the backlog becomes stale.

  Once we have a well prioritized backlog, we need to plan the sprints. Normally we plan sprints for two or three weeks, which honestly is not enough time, especially in a greenfield project, such as the one we’re currently working on. Sprints should ideally be thirty days. I like thirty work days as opposed to thirty calendar days, that way you know exactly what time you have to plan and execute with. Planning shouldn’t be a one or two hour meeting where you grab enough items off the list to fill the available velocity. Rather planning should last for a whole day. The highest priority backlog items should be broken down enough to give a decent effort. Once you’ve selected and planned the backlog based on releasing working functionality you’re halfway there. It is essential that all the team members buy into the work to be performed and agree that it can be accomplished.

During the sprint the Scrum master needs to play the role of “Heavy” and eliminate interference and remove obstacles from the dev teams goal. He/She needs to insure the backlog doesn’t grow to include “pet” projects or “I feel like doing something else” backlog items. He should lead the daily stand ups using a simple format. What did you do yesterday?, What are you doing today? and What obstacles are preventing you from completing your tasks? The daily stand ups are not optional affairs, they should include everyone always, no excuses.

  The team should work to accomplish all the tasks planned for the sprint, but realize that you may not always complete all of the backlog items for a given sprint. You may also discover during the course of the sprint that the scope of some backlog items were underestimated or impacted more than originally thought.

The sprint should be closed out with a demo of the features implemented during the sprint. Invite users and management to come and try the functionality for themselves. Involving the users is key, if they’re not engaged or see no tangible benefit they’ll be less like to support further development.