At Northwest Cadence, we have created a work environment that emphasizes excellence, integrity, and out-of-the-box thinking. Our customers have high expectations (rightfully so) and we wouldn’t have it any other way! Our team of outstanding people consistently rise to the occasion. They think smart, work hard, forget the box and have fun exceeding expectations, both inside and out of our company walls.

The ALM Consultant will provide project support, various deliverables, and quality solutions on Visual Studio (including Visual Studio Team System), software design, and Application Lifecycle Management. Engagements will vary and will involve providing expert training, consulting, mentoring, formulating technical strategies and policies and acting as a trusted advisor to customers and internal teams.

The ALM Consultant position requires up to 50% travel. This is a full time position and will be based in the Kirkland, Washington office.

I won’t regale you with stories of the parties or the in-hall discussions, but I do want to highlight three talks, and our role at TechEd.
With all the votes counted, Northwest Cadence did well.  In addition to speaking to great audiences, interacting with really smart people and meeting some new clients, our sessions apparently hit the mark and were rated highly by the attendees!  Three of our talks deserve special mention:

• Branching and Merging for Parallel Development, a talk by Jeff Levinson on the benefits and pitfalls or various branching strategies took 3rd place in the Developer Tools, Languages and Frameworks track.
• Practical Regulatory Compliance and Risk Management, my talk on using Team System to help software development teams achieve regulatory compliance (as well as manage risk) took 2nd place in the Developer Practices track.
• Metrics That Matter: Using Team System for Process Improvement, my talk on metrics took 4th place in the Developer Practices track.

Finally, we spoke at the preconference.  (Can I say “finally”, when it preceded all the other talks?)  Of the 15 preconferences, our talk titled Improve Your Software Development: Real World Solutions with Team System 2008 ranked 2nd just behind the excellent talk on SharePoint planning and governance.

For anyone interested in hearing or seeing these sessions, shoot me an email or leave a comment!  I’d love to share them with you!  We’re representing several of these sessions at our TechTalk: VSTS Firestarter event on the Microsoft Campus this Thursday, and we’ll be recording them.

A special thanks to those customers who generously allowed us to use your stories, and especially to those who went so far as to provide us with their data warehouse and cube.  You guys rock!  Thank you!

Click the image for a link to Tech Ed! And be sure to drop by and visit us at the Team System booth!

Northwest Cadence Further Distinguishes Itself by Earning a Microsoft Competency in Custom Development Solutions and Learning Solutions

Kirkland, WA, USA – 9 January, 2009

Northwest Cadence, www.nwcadence.com, today announced it has attained Gold Certified Partner status in the Microsoft Partner Program with a competency in Custom Development Solutions and Learning Solutions, recognizing Northwest Cadence’s expertise and impact in the technology marketplace. As a Gold Certified Partner, Northwest Cadence has demonstrated expertise with Microsoft technologies and a proven ability to meet customers’ needs. Microsoft Gold Certified Partners receive a rich set of benefits, including access, training and support, giving them a competitive advantage in the channel.

Northwest Cadence provides consulting, coaching, and training on Visual Studio Team System and Application Lifecycle Management. With careful attention to both the present and the future, Northwest Cadence provides sound solutions that can be implemented, metrics that can be measured, and knowledge-transfer to ensure sustainable success. “This Gold designation helps tell the story of who we are. We are extremely pleased to be recognized as a Microsoft Gold Certified Partner. Although this Microsoft designation is quite an achievement, we are especially proud because it represents who we strive to be, every day” said Lori Borg, President of Northwest Cadence. “At Northwest Cadence, our mission as a team is to listen and be responsive to our customers and attaining this Gold status will enable us to continue to better serve our VSTS community.”

“Customers are looking for partner companies that can bridge the gap between their business demands and technology capabilities,” said Allison Watson, corporate vice president of the Worldwide Partner Group at Microsoft Corp. “They need to trust in a company that can act as an expert adviser for their long-term strategic technology plans. Microsoft Gold Certified Partners, which have certified expertise and direct training and support from Microsoft, can build a positive customer experience with our technologies. Today, Microsoft recognizes Northwest Cadence as a new Gold Certified Partner for demonstrating its expertise in providing customer satisfaction using Microsoft products and technology.”

As one of the requirements for attaining Gold Certified Partner status, Northwest Cadence had to declare a Microsoft Competency. Microsoft Competencies are designed to help differentiate a partner’s capabilities with specific Microsoft technologies to customers looking for a particular type of solution. Each Competency has a unique set of requirements and benefits, formulated to accurately represent the specific skills and services that partners bring to the technology industry. Within select Competencies, there are Specializations that focus on specific solution areas that recognize deeper expertise within that Competency. Serving as a specialized path to earning those Competencies, Specializations give direct access to the tools and resources that support that specific area of focus.

The Custom Development Solutions Competency is designed for technology partners providing custom-built solutions for clients that require value-added capabilities to optimize business opportunities.

“Our developer partners enable us to deliver high-quality solutions and applications to our customers,” said Nick Abbott, group manager in the .NET Developer Product Marketing Group at Microsoft Corp. “As the demand for applications built on the Microsoft platform continues to grow, there are more opportunities for providers of custom-developed applications than ever. The Custom Development Solutions Competency provides partners with a way to showcase their expertise delivering custom-built solutions to customers, to enhance partners’ revenue opportunities and positioning them for growth.”

Microsoft partners with the Learning Solutions Competency specialize in delivering high-quality training and full-service learning solutions to help customers maximize their investment in Microsoft technologies. Earning this competency identifies partner members of Microsoft’s premier commercial training and delivery channel, making it easier for partners to expand their scope of services and market potential. Microsoft Gold Certified Partners with the Learning Solutions Competency deliver a comprehensive range of information technology and developer training services, including skills assessment, technical training, student mentoring, and Microsoft Certified Professional exam preparation.

The Microsoft Partner Program was launched in October 2003 and represents Microsoft’s ongoing commitment to the success of partners worldwide. The program offers a single, integrated partnering framework that recognizes partner expertise, rewards the total impact that partners have in the technology marketplace, and delivers more value to help partners’ businesses be successful.

Northwest Cadence specializes in Visual Studio Team System and Application Lifecycle Management. Deeply committed to the VSTS and ALM space, Northwest Cadence is committed to ensuring its clients have an exclusive advantage based on the company’s product expertise and ability to bring it all together. Northwest Cadence is involved in the current and future Microsoft product development of VSTS and employs a team of consultants and trainers who are designated as Microsoft VSTS MVP’s, VSTS Advisory Council Members, and Certified Trainers. Northwest Cadence is proud to be a part of Microsoft’s respected VSTS Inner Circle program.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

For more information, press only:

Lori Borg, Northwest Cadence, (206) 947-0967, Lori.Borg@nwcadence.com

Steve Borg knows, for now – the 5th year in a row, Steve has been awarded this prestigious award from Microsoft. This award is given annually to outstanding members of Microsoft’s technical community and it is based on contributions made during the previous year. In order to receive this award, the nominee undergoes a rigorous review process. A panel that includes MVP team members and product group teams, evaluates each nominee’s technical expertise, community contributions, and commitment to the MVP code of conduct. This panel considers the quality, quantity, and level of impact of the MVP’s contributions and presents the award based on their findings. Not only has Steve undergone this rigorous review for the past five years, but did you know – he was in the very first group of MVP’s for VSTS announced the day VSTS was released!

Steve is part of this amazing group of individuals who are considered exceptional technical leaders in the community. And indeed, this is an elite group for there are only 3,500 MVP’s worldwide. Northwest Cadence is very fortunate to have Steve as part of our team. Congratulations!

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.

Let’s look at each of the states so we understand what the state represents. And if this looks like the start of a new methodology, well, it is and it isn’t. It is because I’m going to detail out of this series of posts how to handle numerous items and there is a lot of methodology and process displayed here. But it isn’t because much of this is just common sense. Also, note that you do not need to implement every step. This process that I’m describing here can be scaled based on your needs.

The states and their descriptions are these:

Proposed

This state indicates that a reported bug has been received. It does not indicate that any action has been taken with regard to working on the reported bug.

The key item to note is the reason which in this case tells us what group filed the bug. This is important because as has already been noted, it costs more to fix a bug the later it is found in the process. This allows you to note where the bugs are found and determine where certain weaknesses lie.

Under Investigation

This state provides status to the end user to indicate that the bug report is currently being triaged.

The state transition provides us one very useful piece of information – the time it takes from the bug being received until someone starts working on it. This is the first of the areas where we find waste.

This state requires some work though – no free rides here. Several things need to happen:

1. A duplicate bug must be checked for. If a duplicate is found, then this bug needs to be closed and linked to the original bug report.

2. Find the test case that relates to the functionality at issue.

3. The analyst needs to determine what the correct functionality is supposed to be. If it works correctly (as designed) then what the user is actually reporting is a change request and a change request needs to be created. This bug can be closed and linked to the change request.

4. The bug needs to be reproduced. If it can’t be then it is closed.

5. If the bug can be reproduced, then the test case needs to be modified (or created).

What does this information provide us?

If the bug is a duplicate it means at least one thing and maybe two. First it means that this bug occurs in a commonly used piece of code and is therefore a cause for concern. Secondly, depending on the lag time between the original bug report being filed and the duplicate bug being filed may indicate that the bugs aren’t being fixed in a reasonable period of time.

If you cannot find the associated test case(s) then there is another issue. First, why was no test case created? Was it because this is in a less frequently used part of the system? If so, that may be acceptable (maybe it isn’t part of the normal path and so minimal testing was done on it), but it means that this part of the system is being used and additional test cases may need to be created to proactively identify any additional, related bugs. If you do find the test case, what about the test case missed the bug? Is there a gap in the test case? Are all paths not tested? Can you go back and review the code coverage report to see if there is a path through the code that was missed? These questions and their answers will help you proactively identify other areas in this particular area of code so you can take mitigating steps.

What if the functionality is as designed? The user is then requesting a change to the functionality – maybe. They may not understand how the functionality is supposed to work. But what does this tell you? Were the users trained in the correct use of the application? Is there online help for the application and is it effective? If the users haven’t been trained and you receive a high number of these items then maybe it’s time for a training class. If they have been trained and there is online help, then maybe the help isn’t effective or effectively integrated into the application. This may indicate that changes in those areas are needed – but only if you know what to look for.

If the bug can’t be reproduced, it must be closed. However, it must not drop off of the radar. When duplicate bugs are found you need to remember to check the closed bugs as well. If you find a number of non-reproducible bugs being duplicated, it may be time to activate the bug and try to have the developers spend some time investigating the situation.

Finally, if the bug is validated, that isn’t good enough. There needs to be a test case which shows what the correct behavior of the system is supposed to be so that the developers know when they are done fixing the bug and they have a way to verify that fix. If there is an existing test case and it is incorrect, then you need to look back at the requirements to determine if the test case was incorrect or whether the requirements were incorrect and make the appropriate changes (each of these points to a different area that needs to be looked at for improvement).

Investigation Complete

This state indicates that the bug report has been verified and is now an actual bug. And again, it provides a solid indication to the end user of the status of their bug report.

The transition from Under Investigation to Investigation Complete provides the first piece of information on work performed in order to fix the bug (after all, you can’t fix the bug until you have verified it).

At this point the assignment of work can commence. However, there may be a high number of work items to assign so it may be up to a Change Control Board (CCB) to accept and validate work for a release. If that is the case then the list of Investigation Complete items will make up part of the agenda. This however can present problems. See the section entitled “Waste” later in this chapter for the problems related to this and some ideas on how to fix them.

Assigned

This state is an indicator that the bug has been assigned to a developer for work.

This is called a buffer state. The transition between Investigation Complete and Assigned is basically unimportant. What is important is that this transition says is that you are planning to fix the bug. Now, what it doesn’t tell you is what release you are planning on fixing it in. Using TFS you can simply re-assign the bug to an appropriate future iteration. The assigned state also tells users that no one has started working on the bug yet. Additionally this state provides feedback to the CCB about what work is scheduled to be done but hasn’t started yet so the CCB doesn’t accept more bugs than can be reasonably fixed.

Active

This state indicates that the bug is actually being fixed. No bug must ever move to this state without having an accompanying test case.

This state isn’t as important as the transition to this state. The time between the bug being assigned and the bug being active is lag time and is therefore waste.

One of the activities that should be performed during this phase is the creation of a unit test to verify the existence of the bug in code. This will help create a large library of unit tests which target previous bugs which makes regression tests easier to run.

In this part I’ve started to describe what happens in each state and what information you can gather from each state. In the next post I will round out the steps in this particular process and then I’ll move on to discussing the benefits of the metrics. Note that this process covers virtually every type of metric you may need (there are a few it doesn’t cover but I’ll talk about that in the next post). Note also that you can pick and choose which states you want. For example, if you’re reasonably confident that you don’t have bugs sitting around for a long period of time, then maybe the early buffer states aren’t needed. Or if you aren’t sure where the problem is occurring, use broad categories and introduce additional steps to pinpoint a problem as needed.

Stay tuned for the next post!