Microsoft published more information today about Visual Studio 10 and .NET 4.0. Click here to read the Press Pass and here to read some additional information.

Oh, and for SA customers, some really interesting news has come out that will impact you in just a few days:

Microsoft also announced that VSTS 2010 will provide a unified VSTS Development and Database product. As a benefit to existing Software Assurance (SA) customers, those who currently own Visual Studio Team System 2008 Development Edition or Visual Studio Team System 2008 Database Edition will receive all the following products starting Oct. 1, 2008, for free:

• Visual Studio Team System 2008 Development Edition

• Visual Studio Team System 2008 Database Edition

• Visual Studio 2005 Team System for Software Developers

• Visual Studio 2005 Team System for Database Professionals

Code Camp is a grass roots event organized by software developers for software developers. I’ve attended several code camps, presented at a few, and helped organize the Boise Code Camp. In all cases it was a worthwhile and rewarding experience. Chris Kinsman is spearheading the Seattle Code Camp 4.0 coming up  November 15-16, 2008 at the DigiPen Institute in Redmond WA. I highly encourage you to attend this event, and maybe even give a presentation on whatever you’re passionate about.

For more informtion visit https://seattle.codecamp.us/

I was invited by INETA to speak at the Pacific Northwest Access Developer Group (a.ka. the Seattle Access Group). Now, Access developers are typically "teams of one", but I thought that any team developers or consultants attending the meeting would get the ALM story and features of TFS. They did.f

As it turns out, the steps to integrate Microsoft Access 2007 with TFS aren't all that difficult:

1. Install and configure TFS to allow the developers to connect
2. Install the MSSCCI provider on each developer's desktop
3. Install the Access Developer Extensions on each developer's desktop
4. Create and configure the Team Project, version control folders, and workspace(s)
5. Follow the guidance on using Access with Source Control (you can ignore the references to VSS).

Remember: you can't View, Compare, or Annotate any Access objects under source control, with the exception of code (modules, macros).

Thank you to those of you who attended my talk. You can download my presentation here.

You get to the end of your sprint and there is that are 2 incomplete stories left on the sprint backlog. Story A is judged to be 80% done, Story B was never even started. What do we do with these stories?

Options:

• Give 80% of the point value of Story A to the team for the current sprint.
• Split Story A into smaller stories and take credit for the done work, push the next work into the next sprint.
• Take both stories an re-prioritize them.
• Automatically take the stories into the next sprint, no debate.
• And many others I am sure are being practiced in companies today.

What Should Be Done

1. No credit to velocity is given for either story.
2. Re-estimate and re-prioritize the stories.

Why It Should Be Done

Story A

Story A was 80% complete. Incomplete work is not counted in the velocity because doing so allows the organization to consider work done that really isn’t.

Taking credit for unfinished work is the idea of Earned Value. Earned Value says because someone earned a salary for 3 days, the value of the final product or project went up accordingly. This is regardless of what the contributor did in those 3 days. This is obviously not a realistic notion given that Joe-Bob surfed the web for 2 of his 3 days.

Why do we re-estimate the work before putting it back into the backlog?

1. Not doing so is unrealistic. The amount of work left to do to finish the story is hopefully less than the original estimate. The work remaining to finish the story is the real effort going forward. After all, some of the work is done.
2. It is entirely possible the team has learned more about the work itself such that the estimate to finish is significantly different than the original. Remember that an estimate is always based on what is known at the time the estimate is given.

Re-estimate the story and put it back on the backlog.

Story B

Story B is simpler, but since it wasn’t even worked on why does it need to be re-estimated?

The real truth is that stories are often related, even though they are ideally independently deliverable. It is not only possible, but likely, that the team has learned more about the background of this work in the sprint that just finished. This means that a more accurate estimate is now likely.

Re-estimate the story and put it back on the backlog.

Bottom Line

No, you can’t take credit for partial work.

No, you can’t have credit for all originally estimated points in the sprint that finishes the job.

This model keeps things simple and keeps teams from gaming the numbers. Yes, I know successful teams that re-negotiate done. Yes, I know successful teams that split the story and only move part of it into the next iteration. I don’t agree that these practices are good, however. They relax the commitment made by the teams enough that the teams are basically allowed to get sloppy.

Keep it simple.

Ever notice that no matter what shenanigans Beaver would get into, June always believed everything was fine? No matter how many scotches Ward had after dinner, there was no problem, according to June. June Cleaver is the classic enabler with a bad case of denial.

So is the TFS Source Control Shelving feature.

Don’t get me wrong. Sometimes everything really is okay. Sometimes I just want to push my code into a shelf set because I have to go to my kid’s play in 5 minutes and I just want to make sure I am backed up in case the building burns down in the next 2 hours. Sometimes.

More often, Ward is shelving his code because he hasn’t checked in for 3 days and can’t be bothered to do the necessary merges before he heads home to that scotch bottle.

I would go so far as this: Frequent shelving is a smell.

Reasons you don’t need shelving include:

1. Team members are checking in frequently as they make changes to code, passing tests and keeping code coverage high. Frequently means every few passing unit tests or so.
2. Team members are in the habit, nay, are required to check in the day’s work and get a clean build before they go home for the day.
3. When a team member is looking for a code review, that person has direct (as in “within voice range”) access to other team members who can perform said review. Even better, they are pairing.
   
   Note for distributed teams: Microsoft’s SharedView works great for remote pairing.

I find it best to think of the Shelving feature as SkyDrive for source code. It isn’t sufficient as a source control strategy, but can be pretty handy on occasion.

One more way that Shelving is like June Cleaver? Pretty. Not smart.

Last week, Microsoft announced that they had joined the Object Management Group. OMG is the consortium responsible for many distributed, and object-oriented specifications. One of their sets of standards defines the Unified Modeling Language (UML), and I'm sure that's the reason Microsoft joined the ranks.

Knowing what's coming in the Rosario (and beyond) versions of Visual Studio Team System, I'm glad to see this happening, as it reinforces that Microsoft is taking their modeling strategy to the mainstream.

I'm sitting through the two-day Visual Studio Extensibility (VSX) Developers Conference this week and Rico Mariani gave his roadmap to Visual Studio extensibility. Here are some highlights of the coming, "decade worth of work" ...

VS10 (the version after 2008, a.k.a. "Dev10")

• New editor with fine-grained extensibility
• Build on Microsoft Extensibility Framework (MEF) which is "COM for the managed world"
• All new features that should support multiple languages do

VS11

• VSTA (DLR) used for macros and other end-user extensibility
• Critical mass for managed extensibility models enables several common classes of add-ins to be built purely in managed code
• Common project system
• Richer, common base types and protocols for discovery, activation, and manipulation
• Asynchronous extension and visualization model and showcase examples

VS12

• Stable VSIP API's enabling a high degree of compatibility
• Extensive use of asynchronous extension and visualization model

As you know, Visual Studio 2008 and Team Foundation Server 2008 Service Pack 1 was released earlier this month. Most of SP1 was about bug fixes and performance, but it seems that the profiler team snuck in several new features as well:

• Adding support for instrumenting 64-bit managed C++ applications
• Improved instrumentation experience with pre-compiled web sites
• Shipping the 64-bit performance SDK (VSPerf.h, VSPerf.lib)
• Ability to load a previously saved filter on non-English VS installations

Here is a link to the VS2008SP1 readme and a page listing all of the SP1 downloads.

I just replaced Windows Vista Ultimate x64 on my laptop with the 64 bit version of Windows Server 2008. What prompted the change? Well, I was hoping to improve the lackluster performance of Vista. I would happily trade in the consumer goodies in Vista for better productivity. Unfortunately it seems to be an either/or proposition. But the most compelling reason for me was Hyper-V, the new virtual server from Microsoft. I do a lot of work with virtual machines, mostly to run a complete Visual Studio Team System environment in a sandbox for development and training purposes. Although Virtual PC 2007 is a good product, Hyper-V seemed to offer better performance and more flexibility with features like snapshots. Hyper-V also supports 64-bit guest operating systems, while Virtual PC 2007 can only run 32 bit OS’s.

After reading this article I was convinced that Windows Server 2008 with Hyper-V was the setup for me. So, I took the plunge. In the next blog post, I’ll go over the process of installing Windows Server 2008 as a workstation OS (also dubbed Windows “Workstation” 2008).

By the way, I run a Dell 830 laptop with an Intel Core Duo T7500 mobile CPU and 4GB RAM. If your workstation does not support hardware virtualization, then it won’t run Hyper-V. However, you can enjoy the benefits of Windows “Workstation” 2008 and still run your virts using Virtual PC 2007 SP1. Although Windows Server 2008 is not officially a supported host OS for Virtual PC, it seems to work just fine.

OK, let’s say you’re on a Scrum team that’s planning its next iteration. You pull a story to implement Feature X for the next release of Application Y. You review the specs, maybe have a conversation or two with the product owner to clarify a few details, and discuss implementation details with your team lead. Cool. Now, you design the feature, code it up, build it and tweak it until its working to your satisfaction.

Then you check it into the source control system and move on to the next feature. Done, right? Not necessarily so! Sure, you can stand in front of the users at Sprint Review and watch them salivate as you demonstrate Feature X in action. But, can they walk out of the review and begin using it right away? Most likely not. If not, is it really done?

“Code complete” is just one milestone on the yellow brick road to Emerald City, where users are happily whistling away while using your excellent Feature X in their Application Y. There is so much more to consider. What about unit testing? Integration testing? Acceptance testing? Documentation? Packaging? Deployment?

Getting an application successfully delivered involves much more than working code. Failure to take this into account, and considering “code complete” to mean the same thing as “done”, inevitably causes a development team to fall behind schedule as they scramble to deliver what was already considered done. This is a form of technical debt, a topic I’ll explore in a future post.

For more information on the meaning of “done”, check out this excellent podcast on HanselMinutes.com:

What is Done? – A Conversation with Scrum Co-Creater Ken Schwaber

Back in the 80s (way back!) Apple got a toe-hold in the PC market in part by engineering a high presence in colleges and high schools. The theory was that if you get a young person started on an Apple computer then they will want to continue using Apple computers into their adult careers, if for no other reason than they already know how to use it. This strategy actually worked reasonably well.

Microsoft has always struggled with their presence in colleges and high schools. These institutions tend to favor the JLAMP stack (Java, Linux, Apache, MySql, PHP) over the Windows platform. What mind-share Microsoft has with students seems to tend toward the "evil empire" variety.

I'm pleased to see that Microsoft has finally made a bold move to improve their visibility in the college community. My son - a college student - pointed it out to me the other day. The program, launched last February, is called DreamSpark:

DreamSpark is simple, it's all about giving students Microsoft professional-level developer and design tools at no charge so you can chase your dreams and create the next big breakthrough in technology - or just get a head start on your career.

Looking at the list of software available for free through this program, it almost makes me want to enroll in a class or two at my local university!

For more information: https://downloads.channel8.msdn.com/

A bug is a bug is a bug, right? Not so!

Most development shops treat a bug as a task. That seems reasonable - it's a bit of work that needs to be done. Unfortunately, it's not so easy. If a bug is discovered in a feature that is currently under development, and it will be fixed in the current Sprint (iteration), then the bug can and should be treated as a task. It would be considered a new Sprint Backlog Item that must be closed before the feature can be considered "Done". However, if the bug is not fixed before the feature is considered "Done" (yes this really happens), or the bug is discovered after the feature has be deemed "Done", then the bug becomes a bit of work to be scheduled into a future Sprint. In other words, the bug should be treated as a Product Backlog Item.

The rule of thumb is rather easy really. If the bug is going to be fixed in the current iteration, then treat it as a task. If not, then the bug needs to go on the product backlog and be prioritized right along with all the other Product Backlog Items.

Of course, this raises the question: What does "Done" mean exactly? Many dev teams grapple with this deceptively simple question. I'll explore this question in a future post.

While at TechEd 2008 earlier this month I attended a presentation by Colin Bird where, among other things, he presented the next generation of the Conchango Scrum For Team System process template. According to Colin, Conchango will continue to offer a free version of their scrum process template. But, they will also be offering for the first time an "enterprise" version that they will sell for a yet-to-be-determined fee. This enterprise version will contain an exciting new feature: and Electronic Scrum Board. This WPF application simulates the cork board and index cards that many scrum teams use to track the progress of their sprint. Each row represents a Product Backlog Item (also called a User Story) that describes a specific feature to be implemented, while each card represents a Sprint Backlog Item that describes a specific task. The columns on the board represent the various states for a Sprint Backlog Item.

I took this shot while sitting next to David Starr in the presentation, who also took a snap with his camera phone.

When a card is dropped onto a row the board, it is automatically linked to the corresponding Product Backlog Item, and it's State is also updated automatically. This is sooo much more convenient that the current method of updating work items, and the board methaphor makes it much easier to visualize the overall status of the sprint.

I also happened to be part of the same lunchtime discussion of Electronic Scrum Boards with Jeffrey Palermo that David blogged about. I respect Jeffrey's opinion very much, as well as Dave's reaction to Jeffrey's comments. But my take on the topic is slightly different.

As I recall, Jeffrey was not thrilled about the Electronic Scrum Board because a physical cork board works just fine. The cork board is simple and easy to use. It's highly visible to the scrum team and its stakeholders. Why go to the trouble and expense of implementing an inferior solution?

I get it. But I also beg to differ. First, let's assume that an organization has decided to use Team System work item tracking because it offers rich reporting of current and historical data, as well end-to-end traceability resulting from linking work items to changesets to builds to build verification tests. Now, if a scrum is using both work item tracking as well as a cork board, then the same information if being maintained redundantly. This being the case, it's almost certain that the work items will be out of sync with the cork board some if not all of the time.  With two conflicting views of project status, which one is authoritative? Which one do you believe?

Also, the cork board works great if the scrum team is co-located in one open space. Having all team members together in one location is ideal, but the reality is that a growing number of teams are geographically dispersed - sometimes in different parts of the world. For these teams, the cork board offers a poor solution.

Similarly, project stakeholders are often not in the same physical location as the cork board, making it difficult if not impossible for them to benefit from the information the cork board contains.

For these reasons, I believe that the Electronic Scrum board offers a superior solution. It not only shows current status, it also automatically maintains work item history. Analysis of this historical data can calibrate future estimates, enabling better sprint planning. Also, an Electronic Scrum Board offers a far more practical solution for teams that are not co-located.

Finally, I find it curious that scrum teams are in the business of creating automated solutions for others, but some of these same teams are loathe to give up their cork boards for an electronic version. Doesn't that seem just a bit ironic?