Willy-Peter Schaub's Cave of Chamomile Simplicity

Visual Studio 2008 Product Comparison Data Sheet

Rob Caron pointed us to a great resource, which provides a comprehensive product comparison of the Visual Studio 2008 IDE products. Note that it covers the IDE tools only, not languages or server tools, i.e. Team Foundation Server.

Download the nuggets from http://www.microsoft.com/downloads/details.aspx?FamilyId=727BCFB0-B575-47AB-9FD8-4EE067BB3A37&displaylang=en.

Thanks Rob!

TFS - the need for speed!

Visit John Rayner's blog for some interesting and exciting performance improvement statistics for TFS 2008.

Neptune going AWOL for a few days ...

Sorry, I will be in a SharePoint boot camp and will not be blogging much until early February. My responses may be delayed, as my colleague does not appreciate us taking laptops into the boot camp collaboration centre.

See you later ...

New Technology Quick Reference Posters Available

We have just uploaded new quick reference posters to www.drp.co.za and www.saarchitect.net which are focused on SharePoint 2007:

• 0500 Creating Web Applications
• 0500 DevelopingWithSharepoint2007
• 0500 SharePoint Concepts
• 0500 SharePoint Development Scenarios
• 0500 SharePoint Architecture
• 0500 SharePoint Workflow
• 0500 Site Structure
• 0500 The Request Pipeline
• 0500 The Request Pipeline Ghosting And Unghosting
• 0500 WFBasics

Comments, as always, are welcome!

TFS - Post Implementation Planning (Part 10 of 10)

Continued from Part 1 of 10, Part 2 of 10, Part 3 of 10, Part 4 of 10, Part 5 of 10, Part 6 of 10, Part 7 of 10, Part 8 of 10, Part 9 of 10

Conclusion

It should be apparent after reading the previous nine posts, that the Team Foundation Server environment is not a straightforward drag, drop and click environment. Instead, it is a comprehensive and complex SDLC and ALM supporting environment that requires up-front investigation and planning. By planning before deploying and by keeping the strategies simple and intuitive, you will ensure that TFS delivers value add to all stakeholders, with minimal overhead.

We have seen a lot of TFS adoptions that simply installed the tools and commenced use thereof ... only to slowly but surely fizzle out, with stakeholders being frustrated with the environment. With a few sessions of proactive planning sessions most of these adoptions could have turned into happy and successful stories.

Surely one does not simply jump in a plane, start the engines and take off when starting the journey of private pilot license training? Perhaps some people do, but as with TFS, the result is most likely a huge crater and unhappy faces.  

Ignore the planning at your own peril!

... the end.

TFS - Post Implementation Planning (Part 9 of 10)

Continued from Part 1 of 10, Part 2 of 10, Part 3 of 10, Part 4 of 10, Part 5 of 10, Part 6 of 10, Part 7 of 10, Part 8 of 10

Company X (Use Case)

The hypothetical Company X is a software development house, with 300 technical resources, 5 main project teams, and an average of 8 mainstream projects and 3 releases per project team per year. One of the project teams is solely responsible for common utility code and frameworks, re-used across team projects.

Each project team has its own project managers and executives, operating as independent silos within the organization. Within each team, each project manager is responsible for and able to select the area of specific methodology, unless a customer requirement dictates a predefined process.

Releases predominantly drive all teams, which also perform the ongoing maintenance with all released solutions, often with parallel releases and maintenance revisions. Although no formal process is enforced, most teams prefer an agile scrum methodology approach and project management is looking for more real-time status information on work in progress, testing and the quality thereof.

They installed a centralized Team Foundation Server, configured for use by all of the project teams and technical resources. They use ongoing boot camp style VSTS training and technology awareness sessions, to educate all technical resources to understand and use TFS and VSTS features effectively.

Environment Adoption

The environment differs from team to team. The customer of the custom solutions often dictates this. In general, the company has adopted an informal development and testing environment, allowing the introducing of a more controlled and monitored environment as documented in section Team Environment on page 3. The proposed environment integrates with TFS, allowing business analysts, end-users and other stakeholders to raise work items for new features, defects and general tasks for completion as part of the project.

The implementation of TFS and the encompassing ALM environment is limited to team projects, work items, version control and the use of basic unit testing. They will introduce other TFS features when the stakeholders are efficient with the phase 1 features and once there is bandwidth for further investigation, planning and training to implement automated builds and testing.

Suggestions

Team Project

To work out the recommended team project structure we should perform a simple calculation of the expected number of team projects required to support the average release schedule:

Year Buffer = 500 / ( number of teams * number of projects per team * releases per project)
= 500 / ( 5 * 8 * 3 )
= 500 / 120
= 4.167 approximate years before the 500 team project limit is breeched

Although this seems to indicate a comfortable time zone, during or after which a TFS server upgrade is required anyhow, the company structure of independent project management areas leans towards a per- team granularity. Finally, the fact that within each team a project manager (or customer) selects any methodology, we need to drop back, by one granularity, to the per-solution team project granularity. This strategy allows each solution to start based on a specific methodology, i.e. MSF Agile or CMMI, and categorizes work items and other team project artifacts on a per-solution basis. While this approach requires more effort to aggregate team-level status reports, it gives the project managers and other solution stakeholders complete control over their solution specific ALM environment.

The company “Company X” and all shown projects are hypothetical and not related to any actual company or projects. Any similarities are purely coincidental.

The recommended team project categorization is therefore as shown below:

Figure 15 – Team Project structure

Solution & Source Tree

The recommended server and client side source tree structures are outlined on page 8, as well as a partitioned solution structure is ideal and suitable for all teams across CompanyX.

The source tree strategy will introduce a common look and feel, improve maintainability and referencing, and yet still allow for team specific customization under the source node. The ability to customize within the source node will allow development teams to use their well-known structure, minimizing impact on their current development, test and build environments if necessary.

A consistent solution and source tree strategy will also ensure that a common build strategy and sharing of build scripts and other artifacts will minimize the overall automation of the build environment in phases 2, 3 or later.

Where needed it is recommended to also sub-divide the source node into functional areas, i.e. user interface, backend servers, batch services, etc. to introduce a source tree structure that can correlate with team project process areas. This would vastly improve readability and thus productivity of all stakeholders.

Branching

Based on the release, maintenance and obvious need for concurrent development, the suggested branching strategy is per-release branching.

Each team would need to assign a merge master, who defines and manages the forward integration (FI) and reverse integration (RI) within the source tree, including the definition of events that trigger a FI or RI event and the quality bar for conducting the integration. Quality branching and merging will ensure that incorrect integration will not affect the team productivity.

Figure 16 – Branching Strategy

It is important  that the team defines dev, main and prod branches, or branches that suit their environment, and then agree on what is forward and what is reverse integration. This specific environment can be highly confusing if done in a non standardised manner within the organisation ... hopefully future versions of VSTS/TFS will make the world of dense forests and branches more visual and clearer to visually understand. The next generation of the tools are showing a lot of promising innovations q;-)

Dependencies

Finally the dependency strategy is recommended to be server based, not workspace mapping based, whereby the referred dependency is solution based dependencies, and using branching from common team projects, such as the mentioned common code and framework projects as shown in the following illustration:

Figure 17 – Dependency strategy

The dependency and branching strategies are both in support of the concurrent development, as well as the re-use and sharing of common code, frameworks and projects. By using the server side dependency strategy the teams can also carry the dependencies through to the IDE and the build server without any customised and maintenance intensive workspace mappings.

... to be continued.

TFS - Post Implementation Planning (Part 8 of 10)

Continued from Part 1 of 10, Part 2 of 10, Part 3 of 10, Part 4 of 10, Part 5 of 10, Part 6 of 10, Part 7 of 10

Dependencies

The final planning concerns itself with dependencies of projects within the solution, other team projects and third party assemblies.

Figure 14 – Dependency Branching

The simplest and most common dependency mapping is “same solution assembly” dependency definition, which references projects within the same solution, which uses Visual Studio to manage the tracking and rebuilding of assemblies when required.

If we need to reference a project in another solution, known as “separate solution assembly” dependency, within the same team project, we should typically add the project to our solution and then revert to the “same solution assembly” dependency mapping.

With “other team project assembly” dependency, which is a common scenario with frameworks and common utility code, we have two options:

1. Branch from other team project into solution, as shown in illustration Figure 14, as the dependency relationship is stored on the source control server.
2. Workspace Mapping allows us to map the source from the other team project into our workspace. This, however, is a client-side approach, which requires all developers to setup the mapping manually and which complicates the build environment.

Next, we have the “3^rd party assembly” dependency, which is similar to “other team project assembly” dependency definition, but is typically limited to binary files, not source. The options we have are to create a team project that contains the 3^rd party assemblies, or to include the 3^rd party binaries in the local team project, under the SharedBinaries directory.

Finally, we have the “web service” dependency, which is best solved using an external configuration file to manage web services. For more information on this concept, please consult your MSDN documentation or “Google” for sample code and documentation.

Now that we have covered the core planning steps, we will investigate a hypothetical company, called Company X, and define the environment, team project, source tree, branching and dependency strategies.

... to be continued.

TDD - Test Driven Development ... who is interested in a 2-day boot camp in South-Africa?

We are planning two 2-day test driven development (TDD) boot camps and one TDD community event in Johannesburg, South-Africa, delivered by the experts from Accentient.

Is anyone interested in such training? If yes, please email me your details and preferred period for the event, or add it to this post as a comment (these comments will not be published).

The syllabus can be downloaded from http://www.accentient.com/downloads/syllabi/tdd.pdf.

TFS - Post Implementation Planning (Part 7 of 10)

Continued from Part 1 of 10, Part 2 of 10, Part 3 of 10, Part 4 of 10, Part 5 of 10, Part 6 of 10

Branching

Branching and merging strategies are possibly the most difficult and most complex planning decisions that we need to make. The recommendation is to avoid branching and using labeling instead, to minimize complexity and promote simple maintenance and administration of the main source tree.

Refer to poster 0202 Microsoft Team System Branching for guidance on branching and merging, which you can download from http://www.drp.co.za or http://www.saarchitect.net.

The following branching strategies are defined by the Microsoft patterns and practices guides, apart from the “no branching” scenario which is suited for small to medium sized teams, requiring no isolation of code, releases or features.

When should we consider branching strategies?

1. If possible never.
2. If code isolation is needed, i.e. parallel feature or release development.
3. If concurrent maintenance of the same code set is needed, for example due to parallel release development or due to large teams with overlapping focus on sections of the main source tree.

What should we cater for if we opt to branch?

1. Responsibility and authority to perform branching and merging.
2. Definition of events which initiate a branch and merge.

Branch for Release … creates branches to support ongoing releases. This common strategy creates a branch before release time to allow the team to stabilise the release and then to merge changes back to the main source tree after testing and release.

Branch Maintenance … creates branches to support ongoing maintenance and the protection of production code base. The branch for maintenance is very similar to the branch for release.

Branch for Feature … creates branches based on features. This strategy is a fine grained branching strategy, supporting parallel and concurrent feature development.

Branch for Team … creates branches to isolate teams from each other, allowing parallel and concurrent development. This is a common strategy when very large teams are working on a large solution, needing code isolation and working towards common milestones.

The following illustration is an extract from the “0202 Microsoft Team System Branching” quick reference poster, showing the concept of reverse and forward integration events.

Figure 12 – Branching … Extract from Branching Quick Reference Poster

A typical branch by revision timeline is as shown in Figure 13.

Figure 13 – Typical Timeline

1. At some point a revision 1 branch is created from the main branch.
2. At some point a revision 2 branch is created from the main branch.
3. Periodic or milestone driven reverse integration merges from the revision branches, in this case revision 1, are moved into the main branch.
4. Forward integration merges are typically based on events, such as a milestone or feature completion, and merge changes from the main branch to development branches. In this case we are forward integration revision 1 changes to revision 2 branch.
5. As quality bars are achieved and testing completed, reverse integration merge changes from the revision 1 development branch back to the main branch. Each merge should be labelled, i.e. RC for Release Candidate and 1.0 for the official release to market.
6. As revision 1 is released, changed are again forward integrated (merged) to the revision 2 development branch.
7. Finally the revision 2 branch is reverse integrated back to main, once a milestone is achieved, i.e. zero quality bar and feature set are met by the team.

To summarise we use branching to isolate code, supporting parallel development of revisions, releases, features and/or teams. Forward and reverse integration are used to move changes from main to development and development to main branches respectively.

Avoid branching if possible and if used, a clear strategy and responsibilities must be defined, to ensure that we avoid the following problematic and often catastrophic patterns:

1. Branching Problems
   • Cascading … branching, but never merging
   • Maniac … branching for no apparent reason
   • Berlin wall … branch to split team, instead of features.
2. Merge Problems
   • Big Bang … deferring merging to the end
   • Mania … merging instead of developing
   • Cross Country … baseless merging across branch hierarchies.

... to be continued.

TFS - Using the Team Edition (2008) for Testers to automate the drudgery

We are investigating the possibility of inviting TDD gurus from the US and hosting a Test Driven Development (TDD) sessions in South-Africa to drive the test driven development approach. Watch this space for more information. Send me an email or add a comment to this post, if you would be interested in attending such a 2-day TDD training event or a 2-3 hour community overview event.

In the interim, I want to step through the process of using the tools in Team Suite or Team Edition for Testers to create a simple class, a test class and to use a CSV file to automate the testing the class. A simple walk through, which will hopefully highlight the immense power that the tools expose ... the steps we will cover are:

1. Create base solution and calculator class
2. Create an application configuration file (app.config)
3. Create test project and integrate the data source
4. Create test data files
5. Run the test

NOTE: Please note that the complete code can be found on http://www.saarchitect.net under the Sample Code, in a zip file called DemoTesting-20080121.zip.

Create base solution and calculator class

First we create a very simple class we will test using the VSTS test environment. The Eagle eyed developers will note that IncrementByOne(...) has an error ... yeah right, one line of code and one bug, immaculate coding ... but it is intentional q;-)

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace DemoTesting
{
    public class Calculator
    {
        public Calculator(){}
       
        public int IncrementByOne(int value)
        {
            return value++;
        }

        public int IncrementByTwo(int value)
        {
            return value += 2;
        }
    }
}

Create an application configuration file (app.config)

We will create a configuration file which defines the following Excel file and worksheets:

Figure 1 - Excel Test Data File

To implement the configuration file to configure the above, we need to update the application configuration file to add:

1. A custom configuration section.

2. Connection strings.

3. Excel data sources.

Custom Configuration Section

Create a section element in the the configSections element, then an attribute called name as follows:

Connection Strings

Add a connection strings after the configSections element to reference a test data file, named testData.xls, using the ODBC provider as shown in the following code extract:

Add Excel Data Sources

Add the microsoft.visualstudio.testtools element and with two data sources based on Excel and referencing the connection string we defined above. We are also defining that the table names are TestOne for the first data source and TestTwo for the second data source:

The final application configuration looks like:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="microsoft.visualstudio.testtools"
                     type="Microsoft.VisualStudio.TestTools.UnitTesting.TestConfigurationSection,
                               Microsoft.VisualStudio.QualityTools.UnitTestFramework,
                               Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
    </configSections>
    <connectionStrings>
        <add name="ExcelConnection" connectionString="Dsn=Excel Files;
                            dbq=testData.xls;defaultdir=.; driverid=790;maxbuffersize=2048;
                            pagetimeout=5" providerName="System.Data.Odbc" />
    </connectionStrings>
    <microsoft.visualstudio.testtools>
        <dataSources>
            <add name="ExcelDataSourceOne" connectionString="ExcelConnection"
                                dataTableName="TestOne$" dataAccessMethod="Sequential"/>
            <add name="ExcelDataSourceTwo" connectionString="ExcelConnection"
                                dataTableName="TestTwo$" dataAccessMethod="Sequential"/>
        </dataSources>
    </microsoft.visualstudio.testtools>
</configuration>

The hard work is done at this stage!

Create test project and integrate the data source

Next we create a Test Project by right clicking anywhere in the class source and selecting Create Test Project. The wizard will guide us through the process, whereby we select the DemoTesting.Calculator class and all methods:

Next select OK  and give the test project a reasonable name:

Finally we update the test code as follows:

1. Comment out the Inconclusive Assertion, to indicate that the test has been implemented.
2. Update each test method as follows:
1. Add a DeploymentItem attribute to each test method, to define the test data file which must be deployed automatically per test. Note that at this stage we are assuming that we have a testData.xls file in the root of our test project.
2. Add a DataSource attribute to each test method, which ties back to one of the two data sources we defined in our configuration file.
3. Reference the test data through the TestContext, i.e. int.Parse(TestContext.DataRow["valueOrig"].ToString()). As shown, we convert to string, then parse to an int.

The final code is as follows, whereby I removed the comments and regions to reduce noise and bolded each line that was changed:

using DemoTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace TestProjectCalculator
{
    [TestClass()]
    public class CalculatorTest
    {
        private TestContext testContextInstance;

        public TestContext TestContext
        {
            get
            {
                return testContextInstance;
            }
            set
            {
                testContextInstance = value;
            }
        }

        [TestMethod()]
        [DeploymentItem("TestProjectCalculator\\testData.xls")]
        [DataSource("ExcelDataSourceTwo")]
        public void IncrementByTwoTest()
        {
            DemoTesting.Calculator target = new DemoTesting.Calculator();
            int value = int.Parse(TestContext.DataRow["valueOrig"].ToString());
            int expected = int.Parse(TestContext.DataRow["valueResult"].ToString());
            int actual;
            actual = target.IncrementByTwo(value);
            Assert.AreEqual(expected, actual);
            //Assert.Inconclusive("Verify the correctness of this test method.");
        }

        [TestMethod()]
       [DeploymentItem("TestProjectCalculator\\testData.xls")]
        [DataSource("ExcelDataSourceOne")]
        public void IncrementByOneTest()
        {
            DemoTesting.Calculator target = new DemoTesting.Calculator();
            int value = int.Parse(TestContext.DataRow["valueOrig"].ToString());
            int expected = int.Parse(TestContext.DataRow["valueResult"].ToString());
            int actual;
            actual = target.IncrementByOne(value);
            Assert.AreEqual(expected, actual);
            //Assert.Inconclusive("Verify the correctness of this test method.");
        }

        [TestMethod()]
        public void CalculatorConstructorTest()
        {
            DemoTesting.Calculator target = new DemoTesting.Calculator();
           //Assert.Inconclusive("TODO: Implement code to verify target");
        }
    }
}

Create the Excel based test data file

We create a Excel workbook, with two sheets TestOne and TestTwo as shown. We must save the excel workbook as testData.xls in the root of the TestProjectCalculator project.

Run the test

1. Select the Test Menu and either use the Test List Editor or Run -> All Tests in Solution
   
2. You will see the following test results in the test results window:
   
3. Double click on IncrementByTwoTest to see the results for the first test. All test data values in the excel test data file are processed and shown together with the test duration.
   
4. Double click on IncrementByOneTest to see the results for the second test. We note that each test failed as the result of each test was one less than expected:
   
5. Optionally fix the IncrementByOne method by changing the complex code to return ++value, instead of return value++. Rerun the tests and you will see a success story for all methods.

Conclusion

With very little code we have automated the test data for our unit tests and have hopefully shown how powerful the base test framework really is. Explore it and use it!

TFS - Post Implementation Planning (Part 6 of 10)

Continued from Part 1 of 10, Part 2 of 10, Part 3 of 10, Part 4 of 10, Part 5 of 10

Source Tree Structure

The following illustration shows “one” of the recommended structures in source control, whereby derivations are common and recommended, as the structure should promote productivity and manageability by the team.

Figure 10 – Source Structure Server Side

The Main root-level-folder, groups the projects, supporting branching for isolated development paths and containing source files and other artifacts such as documentation, build scripts and 3^rd party dependencies. If the unit tests are included in each project the developer can easily access and run the tests. If the unit tests are stored as a peer to source folders, all tests are stored in one central place allowing all tests to run as easily as one.

The Application folder contains the Visual Studio solution file(s) grouping a related set of projects. Additional artifacts, such as documentation, tests and build scripts, associated with the project are typically stored in the build, documentation, scripts and tests directories.

Please note that we are not saying that all documentation should be stored in version control, instead of the SharePoint portal. Our recommendation is to store overall project documentation on the portal and version specific documentation in the version control repository, so that the correct documentation is included with the relevant source code and other artifacts needed to maintain the code base.

Refer to poster --> 0202 Microsoft Team System Orcas 123 Guides --> for guidance on creating solutions. Posters are available on http://www.drp.co.za and http://www.saarchitect.net. The former is optimised for international access and the latter for South-African access from a bandwidth point of view.

On the client side, the recommendation is to keep a synchronised structure, optionally using cloaking to reduce the need to retrieve content from the TFS Version Control and thereby improving performance. When mapping the client side TFS workspace, also optionally consider mapping below the root to limit the number of files needed for your areas of focus.

Figure 11 – Source Structure Client Side

To summarise our planning with the source tree, it is important to create an intuitive structure that supports the relevant branching strategy as outlined in the next section. Simplicity and intuitively rules in this area!

To create the recommended structure, perform the following steps as outlined on our "Best Practices - VSTS 2008 (Orcas) 123 Guides" poster:

1. Refer to “How To: Create Your Source Tree in Visual Studio Team Foundation Server” on the patterns & practices site, which outlines the following basic steps and options.


   1. Create a Workspace Mapping 

   2. Create Your Main Folder 

   3. Create Folders for Your Project Artifacts

   4. Perform a Get Latest operation to export structure to workspace
2. Create the solution files and add to the source tree
   1. From the File menu select New, and then click Project.

   2. Expand Other Project Types and then click Visual Studio Solutions. 

   3. Select Blank Solution.
   4. Type the correct application name, i.e. eApplication, in the Name text box and select location C:\Sandbox\ScrapYard\Main\Source.

   5. Repeat steps 1-4 for all known solutions.
3. Create other solution views and add to the source tree
   1. Create an empty Visual Studio solution in a temporary directory,
i.e. c:\temp\scrapyard and close it.

   2. Copy the solution files from the c:\temp\scrapyard to C:\Sandbox\ScrapYard\Main\Source\XYZ, where XYZ is the appropriate solution, i.e. eApplication.

   3. Open the solution in its new home.

   4. In the Solution Explorer right click the solution icon and select "Add Solution to Source Control".

   5. Repeat steps 1-4 for all known solution views.
4. Create the project files and add to the “solution views”
   • Add existing projects to the relevant solution file by copying the project folder to the solution in Visual Studio. The solution file will automatically be checked out for edit. Check the 
solution file back-in, which check-in the new project folder as well.
   • Add new projects to the relevant solution file by creating the new 
projects as normal and ensuring that you specify the target directory 
to be in the correct path within the source tree.

... to be continued.

Interoperability ... the next frontier

We have taken huge flak for introducing the Linux/Microsoft picture as part of our architecture and technology core unit objectives. The objective is not to fuel the political and unnecessary open source versus proprietary versus everything else debate, but instead to highlight the fact that we are and have to interoperate, integrate and coexist in highly complex heterogeneous solutions in the real world. There will be no A versus B versus C, but instead a A with B with C environment in our world.

In a future technology event we will demonstrate Team Foundation Server (TFS) ... my real passion ... in a heterogeneous development environment and Linux-Mono-WCF collaborating as one really excited and happy family. We will also continue our passionate integration and interoperability research ... we are probably one of the first teams running a virtualised instance of the Windows Server 2008 operating system on a Linux/XEN server.

I wholeheartedly agree with my colleague who stated: "I am tired of the them and us, I know between us we joke about it, but I believe as a company we do not have the luxury of telling our clients what they will run, rather be able to adapt to their needs, in any case it is arrogant to think like that and many companies have disappeared because of that kind of arrogance..."

In fact, we recently ran a competition for the kids of those that attended our Linux/XEN virtualisation readiness session. Here are two of the winning "Mumbles" submissions:

TFS - Process Template Types and the selection thereof ...

Continuation of the post http://dotnet.org.za/willy/archive/2007/12/02/tfs-sdlc-guidance-or-dictatorship.aspx.

What is a Process Template?

The TFS process template is a set of XML files which define the team project environment and associated artifacts, such as team roles and permissions, reports, version control, SharePoint project portal, process guidance and work item tracking. In essence the process template defines the “process” that the team project will be guided through, which can be based on a custom process or on one of the following common process templates:

• MSF CMMI (http://www.microsoft.com/msf)
• MSF Agile (http://www.microsoft.com/msf)
• Lightweight Scrum (http://www.codeplex.com/VSTSScrum) <-- Created by TFS MVPs ... give it a try!
• Conchango Scrum (http://scrumforteamsystem.com/en/default.aspx)
• Essential Unified Process (http://ivarjacobson.com)
• Sarbanes-Oxley (SOX)
• Rational Unified Process (RUP) (http://www.osellus.com)

So what process template should we select?

Once we have explored and created the scaffolding as explored in the Post-Implementation Planning posts, we can proceed to the actual selection of the process template type, in other words the methodology.

Diagram: Post-Implementation Planning Scaffolding Artifacts

The core learning over the years has been that any methodology and process must empower the team. Otherwise, the passion, the enthusiasm and finally the commitment evaporates in front of the solution stakeholder’s eyes. Too often, a great concept or solution is compromised by dictatorship, i.e. a military style project manager dictating who does what, when and more importantly how, or by Swiss democracy in which every team member must cast their vote before the project can advance to the next milestone. If we force artifacts on Team members, it is hard to take responsibility for and ownership of them, whereas we automatically, take responsibility and go the extra mile to meet estimations that we helped define.

View Methodologies and process, as supporting artifacts and do not enforce them as policy. Empowerment of the solution team promotes passion, enthusiasm and commitment, which in turn leads to innovative, reliable and invaluable solutions.

So “Which methodology do we recommend?” you must be asking yourself. The answer is unfortunately the typical IT answer … “it depends”.

It is obvious that methodologies are emerging, changing and disappearing at an increasing pace, which can possibly contribute to the fact that methodologies are not cast in concrete, but evolving to suit existing environments. We as humans enjoy our comfort zone and trusted ways of doing things, which is probably the downfall of any rigid methodology, no matter how much potential it may have for the short to long-term.

We recommend that you review all methodologies available to you and choose one that suits and is capable of evolving into your ecosystem. The methodologies we encounter most often these days and therefore include in our decision matrix are Capability Maturity Model Integration (CMMI), Extreme Programming, Agile (including MSF Agile) and Scrum.

The following graph shows the decision tree we use when evaluating which methodology is suited for a solution team as a base methodology. Why base? Well as eluded to many times before the teams are empowered to customize the methodology to suit their ecosystem, building on what adds value and avoiding what adds overhead to the team.

 Figure 4 - Methodology Decision Chart

Refer to book 3 “Software Engineers on their way to Pluto”, section “Call to Action”, for an overview of what we see as the seven important artifacts that create the foundation for a successful methodology and process template. 

Although the Team Foundation Server environment is an adaptable and customisable environment, we recommend that you either start with the standard process templates or use them as a base to create your customised process template.

The rule of thumb is that you should start with a simple process, unless the project dictates a high level of governance, process reengineering and improvement and auditing.

BB&D Book 2 and 3 - Special offer until February 15, 2007

We have consolidated the knowledge, experience and thinking of our technology specialists in the books. It is a continuous effort to promote information sharing am

• .NET Enterprise Solutions - Best Practices for the Connoisseur (book 1)
• .NET Enterprise Solutions - Interoperability for the Connoisseur (book 2)
• Software Engineers on their way to Pluto (book 3), also features the TFS Lightweight Process Template.

The Book 1 (PDF), Book 2 (Printed) and Book 3 (Printed) are available as a package until February 15, at a special discounted price of R210, including VAT or $US30, plus shipment.  Order 10 or more packages and get the package for R200 or $28 per package, plus shipment.

Add your contact details to this post (will not be made public) and we will get back to you.

This special offer is part of the SA Architect architecture and technology community initiative.