Visual WIP Beta 2 is now out!

New and improved UI and better custom visualization support

Visual WIP the Kanban visualization tool for Team Foundation Server that makes your Work In Progress (WIP) visible!

SimpleTwoMonitors

 

This is the second Beta release of Visual WIP as the API is stabilizing. Changes may be made to what framework Visual WIP will be built on and further UI changes will probably be made as well.

What’s new

  • Pan and zoom is reset when loading settings
  • Added support for work item type and size specific design
  • The TfsWorkItemWorkProvider now adds support to open and edit work items.
  • Work items looks more like sticky notes
  • Auto loading of settings on the command line
  • Auto refresh interval is moved to settings file

Implementation details

  • WorkItemViewModel now inherits from DynamicObject to simplify work item field binding and error handling.
  • Simplified event bubbling implemented
  • Some out of memory problems has been addressed

Find out more and download at http://visualwip.codeplex.com

Some screen shots

A basic ToDo – Doing – Done board with no WIP limits.

Basic

A simple process with WIP limits. The Analysis and Development columns has to sub columns, Doing and Done, that share the WIP limit.

Simple

A three swim lane process with WIP limits

Swimlanes

The settings window for a Team Foundation Server single query column. Team Foundation Server columns are populated based on Team Queries. Define your own or use existing ones.

SingleQuery

Team Foundation Server work item editor. Double clicking on a sticky note on the board will bring up the work item editor for making changes and see more details.

WorkItemEditor

Advertisements

How to create a Cumulative Flow Diagram in Excel and TFS 2010

Cumulative Flow Diagrams (CFDs) are valuable tools for tracking and forecasting the performance of your processes. In this post I will show you how you can create a Cumulative Flow Diagram in Excel that fetches the data from Team Foundation Server 2010 (TFS 2010).

Update
As been pointed out on the KanbanDev mailing list by Daniel Vacanti the approach of counting items per process stage is a simplified way to construct CFDs. Daniel points in his book Actionable Agile Metrics for Predictability out that this approach only works when the following two conditions are satisfied:

  1. Work items are not moved backward in your workflow.
  2. Work items are never completely removed before they are completed.

Keep this in mind if you use this approach.

Result

In this example I ‘m using a modified MSF for Agile Software Development v5.0 template. I have added the following states to the User Story work item workflow:

  • Analysis
  • Analysis Done
  • Development
  • Development Done
  • Test
  • Deployed

Let’s get started.

Continue reading

Visual WIP a kanban board for TFS

About Visual WIP

VisualWIP 2010-11-23

Visual WIP is a visualization tool to make your Work In Progress (WIP) visible. The visualization is a card-wall with stickies in different columns.

If work-in-progress limits are set for a column the same amount of kanban’s(slots/placeholders) are added to the column. If more work is added to the column than the set work-in-progress limit the column background will change color.

The main goals of Visual WIP is to:

  • Visualizer a process work-in-progress by using strong visual signals with a card wall metaphor.
  • Utilize multi monitors to enable to both show an overview from more that 10 feet’s and show detailed information when closer.
  • Use a plug-in model to enable customization and support different electronic backing systems. The main focus is to support Team Foundation Server 2010 but SharePoint is also in the roadmap.
  • Not tied to a specific process as Kanban can be applied to any process. Currently MSF for Agile for Team Foundation Server 2010 is the process that Visual WIP is developed against.

See progress by following the Visual WIP tag or go to the project at VisualWIP.codeplex.com

You can also follow Visual WIP at twitter @VisualWIP 

Project status

Since my last status report the following major changes has been made:

  • You can now save and load the board design.
  • A new size and positioning that uses drag and drop
  • Two new column types are added
    • Rich text – add any kind of rdf based text to your board. Add check lists, definition of done and more
    • Uri – add a html or xaml based page to the board. Add reports from TFS, twitter pages and more
  • The xaml based board design is more or less moved to run-time loaded xaml files that you can customize to fit you needs
  • Support for modifying column setting after they are added is almost done but not activated.
  • Showing Avatars based on the name of the person assign to a work item
  • Some GUI changes

Here are some screen shots:

MainWindow 2 2010-11-23 

MainWindow 2010-11-23

Window 1 2010-11-23

I’m looking for feedback so please comment here or at http://visualwip.codeplex.com/discussions

There should never be a Kanban process template for Team Foundation Server(TFS)

As described in David J. Andersons book Kanban – Successful Evolutionary Change for Your Technology Business

Kanban is not a software development lifecycle methodology or an approach to project management. It requires that some process is already in place so that Kanban can be applied to incrementally change the underlying process.

Kanban is an evolutionary process improvement tool that can act as a catalyst for improving your existing process.

[ Edit: David J. Anderson just posted to the kanbandev group – Is there a Kanban Process? ]

If you don’t have a process already in place or you are very unhappy with you current process you may, and I say may, want to put in place a new process in one big change.

Otherwise, and this is the most likely scenario, you should start by doing a value stream map of your current process. Based on that value stream map apply the Five Core Properties of a Kanban Implementation:

  1. Visualize Workflow
  2. Limit work-in-progress
  3. Measure & Manage Flow
  4. Make Process Policies Explicit
  5. Use Models to Recognize Improvement Opportunities

As you can read above and in referenced texts there are no reference to a specific set of process steps or artifacts. Process steps and artifacts are the core parts of a TFS process template. Therefore it is not especially interesting to develop a specific Kanban process template.

However, TFS has some very useful features that can be very useful when applying Kanban on you existing process.

  • Process templates – If your existing process is similar to any of the may TFS process templates out there, use the one that has the best fit as a starting point and make adjustments.
  • Reporting – the built-in data warehouse is great for collecting and reporting on your flow of work. You probably need to add some new reports but much of the reports and data is already there.
  • Test and Build system – Focus on Quality and Deliver Often are two out of the six steps in the recipe for success and the automated Test and Build system in TFS are great tools to achieve these steps.

There are pieces missing in the TFS product today for it to be a great fit for applying Kanban. Some of these are:

  • No build-in Workflow Visualization tool
  • No build-in support for “enforcing” work-in-progress limits (WIP limits)
  • No good tools for making process changes friction less
  • Some useful reports are missing

These are areas where new tooling for TFS could be very useful but a complete Kanban process template is most likely a waste of time.

I’m currently working on an open source Workflow Visualization tool called Visual WIP. You can find the project at codeplex.com and you can follow the progress by following the Visual WIP tag

Continuous deployment with TFS 2010 Build Agent

When looking at Visual Studio Lab Management and how deployment are done I found this diagram.

LabComponentsExtended

If you look at the Virtual Machine 1 box inside the Hype-V Host box you find Build Agent. This is the same as Build Agent A.1 used on the Build Machine for doing “normal” builds as shown in this diagram.

BuildServerStandalone

This means that you can use the the TFS Build Agent to do continuous/automated deployment even if you don’t have the Lab Management parts.

How to set it up

To make it work you could set it up something like in the diagram below.

DeploymentDiagram

On the Team Foundation Application-Tier the build controller will delegate the different parts of the build and deployment to the different build agents based on the assigned tags passed to build for the different parts. This can be done by adding process parameters as described at the end of Jim Lambs post on How to Create a Custom Workflow Activity for TFS Build 2010 RTM

You have to modify your build workflow to do the deployment. To do this you add a AgentScope activity for every server you want to deploy to. In the AgentScope you add what ever workflow activity you need to perform the deployment. Below is a very simple example.

BuildWorkflow

How to build ClickOnce applications with TeamBuild for multiple environments

  

In ths post I will show how to build ClickOnce applications with TeamBuild for multiple environments in Team Foundation Server.

I have been trying to build ClickOnce applications in our TeamBuild for some time now and only after long ours of googling and trial and error was I successful. The most useful information I found on this blog:

Publish ClickOnce project with Team Build?

Made some modifications and refactoring and here are the code we currenlty use:

This is how you call the ClickOnce build from you TeamBuild project file (line breaks added for readability):

    <Msbuild
          Projects="$(SolutionRoot)ConfigFilesBuildClickOnce.targets"
          Targets="BuildClickOnce"
          Properties="SourceDir=$(SourceDir);PublishDir=$(PublishDir);                      ClickOnceAppName=$(ClickOnceAppName);ClickOnceExeFile=$(ClickOnceExeFile);                      ClickOnceProduct=$(ClickOnceProduct);Company=$(Company);                      ClickOnceDescription=$(ClickOnceDescription);ClickOnceUrl=$(ClickOnceUrl);                      VersionNumber=$(VersionNumber);SigningCert=$(SigningCert);                      SigningCertPassword=$(SigningCertPassword)"
            />

For every environment or configuration change you want you use this. Below you find the BuildClickOnce.targets file (line breaks added for readability):

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Import Project="$(MSBuildExtensionsPath)MicrosoftVisualStudioTeamBuildMicrosoft.TeamFoundation.Build.targets" />
    <Import Project="$(MSBuildExtensionsPath)MSBuildCommunityTasksMSBuild.Community.Tasks.Targets"/>
    <Import Project="$(MSBuildExtensionsPath)MicrosoftSDCMicrosoft.Sdc.Common.tasks"/>

    <Target Name="BuildClickOnce" DependsOnTargets="">

        <PropertyGroup>
            <ClickOnceApplicationUrl>$(ClickOnceUrl)$(ClickOnceAppName).application</ClickOnceApplicationUrl>
            <AppPublishDir>$(PublishDir)</AppPublishDir>
            <SdkPath>C:Program FilesMicrosoft SDKsWindowsv6.0A</SdkPath>
        </PropertyGroup>

        <BuildStep
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Message="Buildning $(ClickOnceAppName) ClickOnce version: $(VersionNumber)">
            <Output TaskParameter="Id" PropertyName="StepId" />
        </BuildStep>

    <CallTarget Targets="UpdateWebPage" />

        <!--
  ************************************************
  Generate application manifest
  ************************************************
  -->
        <Exec
        Command="mage.exe -New Application -TrustLevel FullTrust                  -ToFile &quot;$(AppPublishDir)$(ClickOnceExeFile).manifest&quot;                  -Name &quot;$(ClickOnceAppName)&quot; -Version &quot;$(VersionNumber)&quot;                 -FromDirectory &quot;$(AppPublishDir)&quot;"
        WorkingDirectory="$(SdkPath)Bin"/>

        <!--
  ************************************************
  Signing application manifest
  ************************************************
  -->
        <Exec Condition="'$(SigningCertPassword)'==''"
          Command="mage.exe -Sign &quot;$(AppPublishDir)$(ClickOnceExeFile).manifest&quot;                    -CertFile &quot;$(SigningCert)&quot;"
          WorkingDirectory="$(SdkPath)Bin"  />

        <Exec Condition="'$(SigningCertPassword)'!=''"
            Command="mage.exe -Sign &quot;$(AppPublishDir)$(ClickOnceExeFile).manifest&quot;                      -CertFile &quot;$(SigningCert)&quot; -Password &quot;$(SigningCertPassword)&quot;"
            WorkingDirectory="$(SdkPath)Bin"/>

        <!--
  ************************************************
  Renaming source files to .deploy
  ************************************************
  -->
        <ItemGroup>
            <SourceFilesToRename Include="$(AppPublishDir)***.*"                  Exclude="$(AppPublishDir)*.manifest;$(AppPublishDir)*.htm"/>
            <SourceFilesToDelete Include="$(AppPublishDir)***.*"                  Exclude="$(AppPublishDir)*.application;$(AppPublishDir)*.manifest;$(AppPublishDir)*.htm"/>
        </ItemGroup>

        <Copy
            SourceFiles="@(SourceFilesToRename)"
            DestinationFiles="@(SourceFilesToRename->'$(AppPublishDir)%(RecursiveDir)%(Filename)%(Extension).deploy')"
        />

        <Delete Files="@(SourceFilesToDelete)"/>


        <!--
  ************************************************
  Generating deployment manifest
  ************************************************
  -->

        <GenerateDeploymentManifest
          MapFileExtensions="true"
          AssemblyName="$(ClickOnceAppName).application"
          AssemblyVersion="$(VersionNumber)"
          MinimumRequiredVersion="$(VersionNumber)"
          DeploymentUrl="$(ClickOnceApplicationUrl)"
          Description="$(ClickOnceDescription)"
          Product="$(ClickOnceProduct)"
          Publisher="$(Company)"
          SupportUrl="$(SupportUrl)"
          EntryPoint="$(AppPublishDir)$(ClickOnceExeFile).manifest"
          Install="true"
          UpdateEnabled="true"
          UpdateMode="Foreground"
          OutputManifest="$(PublishDir)$(ClickOnceAppName).application"/>

        <!--
  ************************************************
  Signing application manifest
  ************************************************
  -->
        <Exec Condition="'$(SigningCertPassword)'==''"
            Command="mage.exe -Sign &quot;$(PublishDir)$(ClickOnceAppName).application&quot;                     -CertFile &quot;$(SigningCert)&quot;"
            WorkingDirectory="$(SdkPath)bin"/>
        <Exec Condition="'$(SigningCertPassword)'!=''"
            Command="mage.exe -Sign &quot;$(PublishDir)$(ClickOnceAppName).application&quot;                     -CertFile &quot;$(SigningCert)&quot; -Password &quot;$(SigningCertPassword)&quot;"
            WorkingDirectory="$(SdkPath)bin"/>


        <!--
  ************************************************
  Generating Bootstrapper
  ************************************************
  -->
        <ItemGroup>
            <BootstrapperFile Include="Microsoft.Net.Framework.2.0">
                <ProductName>Microsoft .NET Framework 2.0</ProductName>
            </BootstrapperFile>
        </ItemGroup>

        <GenerateBootstrapper
          ApplicationFile="$(ClickOnceAppName).application"
          ApplicationName="$(ClickOnceAppName)"
          ApplicationUrl="$(ClickOnceUrl)"
          BootstrapperItems="@(BootstrapperFile)"
          Culture="en"
          FallbackCulture="en-US"
          CopyComponents="true"
          Validate="false"
          Path="$(SdkPath)Bootstrapper"
          OutputPath="$(PublishDir)"/>


        <BuildStep
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Id="$(StepId)"
          Status="Succeeded"/>

        <OnError ExecuteTargets="MarkBuildStepAsFailed" />
    </Target>

    <!--
  ************************************************
  Marks a buildstep as failed
  ************************************************
  -->
    <Target Name="MarkBuildStepAsFailed">
        <BuildStep
          TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
          BuildUri="$(BuildUri)"
          Id="$(StepId)"
          Status="Failed"/>
    </Target>

    <!--
  ************************************************
  Updating web page
  ************************************************
  -->
    <Target Name="UpdateWebPage">
        <ItemGroup>
            <WebPage Include="$(PublishDir)publish.htm" />
        </ItemGroup>

        <RegEx
          Condition="Exists(@(WebPage))"
          Path="@(WebPage)"
          RegularExpression="#VERSION#"
          NewValue="$(VersionNumber)"
          Force="true"/>
    </Target>
</Project>