Between October 1, 2008 and December 31, 2008, active Gold and Certified CDS or ISV competency partners may purchase Visual Studio Team System 2008 Team Suite with MSDN Premium subscription at a 66% discount off retail price.

The offer is limited to one coupon redemption per company and no more than 35 copies of Team Suite per redemption.

Check out the details on the Microsoft Partner site and follow the contact information to get your exact pricing information from Microsoft.

Give Team Suite a whirl and unleash the full power of Visual Studio Team System.

Roles & Responsibilities

The figure below shows who is responsible for transitioning items between states in a perfect world.

This figure very succinctly states the following:

1. A user, analyst, developer or tester can file a bug report.
2. A project manager must assign the bug report to someone to investigate. The person they will assign it to is an analyst.
3. An analyst can determine if the investigation is complete. They can also close a bug for the reasons noted in the previous section.
4. A project manager assigns the bug to a developer (or not if the bug is being fixed in a later release).
5. A developer will set the bug to Active when they start working on it.
6. A developer determines when the bug is fixed.
7. Depending on the release process, either a Release Manager or QA Manager will note when the bug is ready for testing (and assign it to a tester). This is because there may be a configuration management (i.e. branching structure) which the code fix needs to be promoted through so that the testers can actually get it in a good build.
8. A tester will note that the bug is being tested.
9. A tester will note that the bug fix has been verified. If the bug has not been fixed, a tester can also re-assign the bug to a developer.
10. A release manager will determine which release the bug fix will be deployed in and prepare the appropriate documentation.
11. Upon successful release, the project manager will close the bug.

Reports

So, you have this great bug tracking process now and you know what information you can get from each step. How do you get it easily? What reports are most important? Where do you cut down on waste?

Waste

Let’s start with looking at a report showing waste and determine how it might be eliminated. The next figure shows a chart of the average flow time for bugs in a system using the above process.

This chart is based on the following data:

Note that I have included only working hours – no weekends or after hours. While this would normally be an average of these values, I wanted to demonstrate how time is determined. Still, if this were an average, you would note that the average time to fix bugs and deploy them is 67.5 hours or almost three days on average. Where can you reduce the amount of time wasted?

Note

In Lean, batching is considered a bad process. The reason for this is that when you batch it means that someone is waiting to receive all of the times that make up that batch and therefore time is wasted. However, in software development, and specifically when dealing with change and release configuration management there really is no other way because fixes almost always must go in together. Promoting them one at a time would take more time than it would save and is also a major configuration headache.

Looking at the chart and table, the actual time spent working on the bug is 15.25 hours (the hours spent investigating, fixing and testing). The time wasted is 50.25 hours (the hours spent waiting while the bug was waiting to be investigated, between the investigation being completed and the bug being assigned, between the bug being assigned and the bug being worked, between the bug being fixed and it being tested and finally between the time the bug was tested until the time the bug was deployed). Again, going back to the principle of waste in Lean theory, the 50.25 hours is complete waste. Now having said that, let’s take a reality check since not all of Lean can apply to software development. Where can you reasonably shave hours?

The first thing to do is to understand why an item may be in a given state for an extended period of time. Let’s look at a hypothetical process and see what may happen in some of these states where waste is occurring.

The next post in this series will cover the hypothetical process. We’ll also start covering different scenarios and organization size when dealing with issues because this is NOT a one-size fits all process.

Windows shell extension for source control, powershell integration, team collaboration tools (messaging, workspace templates, check in history, view shelvesets and pending changes, distribution of custom components).

This power tools release is huge and for some features it has been a long wait but I am so glad it is here.  Check out Brian Harry’s blog for some screen shots and a more detailed breakdown of all the new features.

Steven Borg of Northwest Cadence (Microsoft Team System MVP) took a road trip to Portland to speak to a very interested audience about the new features of Team Build 2008, an inherent and powerful part of Visual Studio Team System 2008. 

There were a total of 68 students from 35 different companies in the Portland area.  Feedback from the attendees on what they believe was most valuable:

• “How build automation with Team Build can replace or enhance our current in-house development   system”
• “Step by step demo of MS Build and overview of ways VSTS can help my organization”
• “Using Team Build for automated deployment”
• “Learning what Build can do for us”
• “Tasks that check in to TFS can be traced in the build.  This really simplifies debugging”
• “High level oversight so as to better see the big picture”
• “References to best practices when using TFS”
• “The integration of work items and code check ins.  Setting up continuous integration”
• “Customizing the Team Build project file”
• “Implementing database scripts in build reporting”

At the end of the presentation, there were several prizes up for grabs; however, two attendees were especially lucky as the recipients of Vista Ultimate and a Microsoft Zune Digital Player.  But I think it is safe to say, all attendees were winners as they were energized by the dynamic speakers and enlightened as to the abundance of Team Build’s bells and whistles.

Thus I was pleased to see that Scott Ambler, one of the agile luminaries, wrote on article highlighting the difficulties of requirement specification on agile projects.  Of specific interest was his absolutely wonderful quote on the first page:

Although “agile in the small” methodologies such as Scrum and Extreme Programming (XP) have done much to show us how to improve our approach, too many people have thrown out the requirements management baby with the bureaucracy bathwater ater putting too much faith in the overly simplistic strategies of those processes.

Jeff Levinson, our ALM Practice Lead has written about this problem and others in several blog posts, most noticably in his post on the problems of Requirements Engineering tools.  It’s also a very frequent discussion over the water cooler here at Northwest Cadence.  Expect to see more on requirements management discussions coming here over the next few months.

Metrics that Matter: Reporting with Team Foundation Server

Am I crazy to think that making informed decisions in regards to your software development process is a good idea? Of course not, and that is why the crown jewel of TFS is the data warehouse that silently gathers metrics behind the scenes. In this session, I will take you into the depths of reporting with TFS and open your eyes to the power of metrics. Using both Excel and Reporting Services, you will see how to create reports that provide traceability and transparency into your software development process.

Check out the schedule to see the updated session times.

If you would like to see anything specific in regards to reporting with TFS, comment and let me know!

Fixed, unverified

This state indicates the bug has been fixed according to the developer.

This means that the developer has fixed the code, checked it in and associated it with the appropriate bug work item. They have run the test case provided by the analyst in the Under Investigation state. In addition, the time between the bug being in the Active state and the Fixed, unverified state is the time it took the developer to fix the bug. In other words, we now have an approximation of the developer effort to fix the bug. It doesn’t provide an exact time but it provides an overall throughput time.

Ready for Testing

This state indicates the bug has been assigned to a tester but the testing has not yet started.

There are a number of reasons for this state. The first is that your branching model is such that a tester does not have access immediately after the code has been finished (i.e. you are waiting to promote code to the QA branch). The second is that there is simply other work going on and that the tester just can’t get to it right now. The transition between Fixed, unverified and Ready for Testing should be made by a Test Manager to acknowledge that the bug has been assigned to a tester (or to the testing group in general) and that it is on the right code branch for testing. The transition to this state does not provide any other meaningful information.

In Testing

This state indicates that the bug is actively being tested.

The other important information provided by this state is the amount of time between the bug being ready for testing and when the testing started. This again shows waste.

Fixed, verified

This state indicates that the bug has been fixed according to independent testers.

The time between this state and the In Testing state provides the amount of time spent testing this bug and is considered work time.

Note: For those familiar with Lean theory, this work would be classified as waste. The reason is because work should never pass a station with defects – it means the process for building the code needs to be fixed. However, as I have mentioned before, I believe this is mostly impractical in software development.

Scheduled for Deployment

This state simply indicates that the fix is scheduled to be released.

An important piece of information to capture at this state is the release that the fix is being deployed in. This helps create a Release Notes document to provide the user explaining the changes in the upcoming release.

Closed

The bug is closed after the release that it is included in has been deployed.

The time between the bug report being Proposed and the bug being Closed provides the entire throughput for the bug being fixed. This information is a good metric of whether or not your process is improving (if reducing the amount of time to accept and fix bugs is one of your goals). While removing individual pieces of waste is important, you have to keep your eye on the overall goal.

A note about UAT

You may be wondering about the lack of inclusion of User Acceptance testing steps to track users’ acceptance of the bug. There are two reasons why this isn’t included. The first is, does it provide you any additional information? Sure, it lets you know the users accepted it, but you can do that as part of the QA process. Second, by doing UAT separately it means that you have to have separate UAT environments from QA which many organizations can’t afford. Is the cost worth it? This may be something you need to take into account as you think through your process.

This finished the process and description of each step in the process. The next post in this series will cover Roles & Responsibilities and Reports and how to track improvements in the process.

Let me get this straight: the guy’s name is Borg and it’s at Microsoft and you want people to voluntarily show up? No thanks I’ll just wait for them to show up at my house and assimilate me (just kidding).

Although I get that a lot with my last name, I thought this was very well written!

By the way, if you’re down in the Portland area, sign up for the Team Build presentation on November 5th, 2008.  You should also check out PADNUG, if you have an interest in all things .NET!