I am really looking forward to going to the Bracknell VBUG group to talk about Scrum and VS2010 on July 7. It should be a great evening. http://www.vbug.co.uk/Events/July-2010/VBUG-Bracknell-SCRUM.aspx

I am a huge fan of both Rugby Union and the Scrum methodology. When I first heard of the framework there was a sense of wonderment at the use of the rugby term to describe the development framework.

For those folk who are not too familiar with the rugby version, this is a short video of just scrums.

From this, you see some scrums that go bad - (collapses,  going backwards), and some solid scrums.

For a scrum to work in either sense the following must be in place:

Cohesive Team – the tight 5 (front row and second row) must work as a cohesive unit for the scrum to go anywhere. Without great collaboration, the scrum goes nowhere. In much the same way a fragmented scrum team will not realise the hyper productivity that is the sweet spot. It should be fun, while being some of the hardest graft you have ever done. At the end you must be able to reflect with pride on the work that you have done.

Commitment – If you don’t commit, you will fail. In the rugby scrum it is the initial contact (the engage) that determines whether the scrum will collapse or settle. If either side does not completely commit, the scrum will collapse. If you are on a team where there is not a common level of commitment, the sprint will not go as well as you plan. The reliance on your fellow team members must be there. This trust takes time to develop, and where altering the team will affect the teams velocity.

Balance of Skills – The rugby scrum uses some of the most specialised positions on the pitch, and you need the selection right to be able to scrummage effectively, In the same way you need the right skill mix in the scrum team. There are no silos any more – you need to get to done. so you need people with the skills to design, build, test, package, deploy and document the incremental release. You can’t go in to a rugby scrum with the hooker, thinking you will sort that out after the scrum – you will have lost by then. Similarly you can’t go in to a sprint with the assumption that the testing will be completed later – you won’t get to done.

Focus and Intent – In both the game and the framework you need to have a clear goal and the intent to achieve it. In the rugby scrum a lack of intent will result in a collapse or similar. Watch at 1:08 where the opposition prop is “popped” out of the scrum allowing the wallabies to drive through. In the framework world, a lack of focus and intent will stop either getting anything done, or not clearing the PBI.

Communication – This is the key to effective teamwork, and the heart of the framework and the game. Where are you at, what are you going to do next and what is stopping you? The daily scrum is critical to keep the team focussed, in the same way the calls in the scrum keep the forwards working as unit.

Crouch – Touch – Pause – ENGAGE!

There are two really powerful ways to harvest the output from the build in to Wix.

Heat extensions that are native with the Wix Install or John Robbins Paraffin. The advantage with using Heat is that with some clients there is a lot of controls with utilising software from the interweb, and Heat is available from the same location as Wix.

The Wix installation is available from here, remember that you will need v3.5 to use with Visual Studio 2010. (Yes it is still listed as Beta, however it works very well!)

Once you have installed Wix and and the project aggregator, the steps to use Heat to harvest the project output are as follows:

So the project.wxs looks like

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Product Id="*" Name="SetupDemo" Language="1033" Version="1.0.0.0" Manufacturer="SetupDemo" UpgradeCode="78282ed7-9280-497b-affa-da3fce3f4f47">
    <Package InstallerVersion="200" Compressed="yes" Id ="*" />

    <Media Id="1" Cabinet="Demo1.cab" EmbedCab="yes" />

    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="ProgramFilesFolder">
        <Directory Id="INSTALLLOCATION" Name="SetupDemo">
          <Directory Id="AppRootDir" Name="Demo"/>
          <Directory Id="AppSymbolDir" Name="Demo" />

        </Directory>
      </Directory>
    </Directory>

    <Feature Id="ProductFeature" Title="SetupDemo" Level="1">
       <ComponentGroupRef Id="Project" />

      <!-- Note: The following ComponentGroupRef is required to pull in generated authoring from project references. -->
      <ComponentGroupRef Id="Product.Generated" />
    </Feature>
  </Product>
</Wix>

And the associated (Demo.wxs) looks like

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Fragment>
    <DirectoryRef Id="AppRootDir">
      <Directory Id="ComponentDir" ComponentGuidGenerationSeed="DBA8384E-CE1B-41af-B573-4203FB8A6A3B">
        <Directory Id="Demo.Binaries" />
      </Directory>
    </DirectoryRef>
    <DirectoryRef Id="AppSymbolDir">
      <Directory Id="SymbolsDir" ComponentGuidGenerationSeed="35A3DCB8-4F85-4e3f-AC83-C51B78C04B94">
        <Directory Id="Demo.Symbols" />
      </Directory>
    </DirectoryRef>
    <ComponentGroup Id="Project">
      <ComponentGroupRef Id="Demo.Binaries"/>
      <ComponentGroupRef Id="Demo.Symbols"/>
    </ComponentGroup>
    </Fragment>
</Wix>

The Rangers have published an update to the quick reference stack, and one of my favourites is the Scrum chart. Download the full pack here.

The pack is broken down by headings

0. Start Here
1. Planning
2. Design
3. Dev Debug
4. Database
5. Testing
6. Build
7. General

The Scrum quick reference is in 7. General.

One of the most critical aspects of any project is when have you got to done. This is one of the central principles of Scrum, as it is the contract between the team that is going to produce something, and the Product Owner who is going to take delivery of it. In waterfall projects, it is just as critical. Due to the focus on the Big Design Up Front, it is costly in terms of time and effort to revisit a phase once it is “done”.

The thing is that there as many definitions of done as there are folk on the project, so it is vital to get the agreed definition visible – so everyone knows what they are committed to delivering.

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
Antoine de Saint-Exupery

At the highest level, any software solution should consist of:

1. Design
2. Coding
3. Testing
4. Build
5. Documentation

OK, so nothing profound there – however what is the benchmark standard for each of these, and how can I use VS to let the team now when we are done?

Design

The great thing about VS2010 is that it speaks UML. When this is tied in with the slick WPF interface, being able to move through many different views, zooming in and out allows you to get a solid understanding of your app quickly. A great summary is at Somasegar’s weblog. All of these are great, and the bonus is that the gated check in is here with Team Build. The purpose of a gated check in is to prevent code that is going to break either the build or the design. In this way the integrity of the design is maintained. The code that is checked in is automatically turned in to a shelve set, and depending on the what level of validation you want (where you set the bar) controls what gets fully checked in. The neat feature is that if your architecture says that the UI talks to the business tier, and not directly to the database, code that doesn’t comply never gets in to the branch. That will save a heap of rewriting!

Coding

2010 is better than the previous version by a long way. The killer feature - Multi-Screen support, followed on by:

• enhanced refactoring
• intellitrace (oh wow … unfortunately only in Ultimate edition)
• support for the all the Dubs (WCF, WPF, WF)
• enhanced intellisense in XAML
• all the Database GDR2 magic
• SharePoint templates
• Multi Framework targeting
• Code Analysis
• Code Metrics

All these features makes it a more straight forward proposition to write, compile, fix and refactor the code base. The guidance from the code analysis and metrics should be included in the done definition – what is the minimum level that you will accept in to promoting up the stack to live?

Testing

The major addition in 2010 is the Test and Lab manager. There is a much improved web testing that can be used to create performance and load tests. The key thing in my view is the lab management to help manage the VM estate so that the range of tests can be run against a known server state.

The testing tiers should be cumulative:

As many of these as possible should be automated so that they can be included in the build cycle. The sooner you know it is broke – the sooner you can fix it

Build

The big change in the build for 2010 is that it is now based on Windows Workflow. MSBuild can still be used, however the default templates are WF. The best practice is to create a custom build process template and share it across your projects.

The bad news is that the WiX integration was dropped, more on that in a later post.

Aaron has a great summary of the way build works: http://blogs.msdn.com/aaronhallberg/

Documentation

Sandcastle is a great tool for generating well formatted documentation based on the xml comments in the code. It can be integrated in to the build, you just have to write decent comments! There is a codeplex project to help get the best out of sandcastle.

Suggested “Done”

A basic definition of Done would be:

• User Stories in as work items
• Design completed
  • Class diagrams
  • Sequence diagrams
• Code written
• Code Compiles
• Code passes code analysis (agreed exceptions)
• Code passes metric gates
• All tests that have been written pass
• Code coverage meets agreed level (this is an “it depends” answer, if you have inherited a huge code base, it is a big ask to get to 80% coverage!)
• Smoke Test passes
• Build and packing completed (you are going to ship this, aren’t you)
• Documentation written

This is a very basic definition of done, the more detailed the definition will depend on where your team is at.

Martin Kulov has compiled this list of links to features in VS2010,  along with the http://www.teamsystemwidgets.com/ for the collection of extensions for TFS.

With the release of 2010 on 12 April, MSDN Premium subscriptions are moved to higher level products. This is all outlined in the VS2010 Roadmap, and the details of what is involved in each  subscription is outlined in the MSDN Subscriptions Matrix. So if you have VSTS Development Edition, you are upgraded to VS2010 Ultimate.

This was going to expire on 21 March, however is now aligned with the VS2010 launch date, so is open until 12 April. This promotional offer is a great way to step up the version of VS that you are using, at a considerable cost saving.