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?

I am a simple man. All I ever wanted was drag and drop for source control. That folder chooser dialog was a bear. Now we will get it with Visual Studio 2008 SP1. Thank goodness. From the web site:

• Simplified the user experience through cleaner "Add to Source Control" dialogs, drag and drop support to the Source Control Explorer and a much easier to use "Workspace" dialog for working folder mappings.
• Version control now automatically supports non-solution controlled files.
• Various changes to the Source Control Explorer such as a new checkin date/time display column, local path hyperlink support and en editable source location field.

I am not a big fan of installing a beta SP on may dev laptop, but I gotta tell ya, I did it for that feature alone.

Some of us here in the Treasure Valley have decided to start a Boise chapter of the Agile Project Leadership Network. This is a group of people passionate about Agile and sharing experiences and best practices with each other.

From the APLN website:

APLN was founded in 2004 by a group of people who are active in writing about, practicing, and evangelizing the movement towards fast, flexible, customer value driven approaches to leading projects of many types. Although this organization is separate from the Agile Alliance, our intention is to work closely with that group within the software community, but also work with people and companies outside of software and IT to help them become better Project Leaders.

I have been party to the APLN discussion at the annual Agile conferences and have found great value in the stories presented there. If you are interested in becoming part of the discussion, jump in to the Google Group.

I've seen Test Driven Development work, so why not adjust it slightly and have the attendees (who own the requirements after all) drive the presentation? Today, at the in-between conference (a.k.a. Microsoft Community Summit 2008), I did just that. I had the attendees drive my four hour presentation. I did this in the Open Space room, and it not only fit with the theme of that room, but it worked great!

As the attendees arrived, I handed them 3-5 3x5 cards - the cool ones from 3M that you can sort, stack, and stick to surfaces.

Here are the topics (backlog items) that they came up with:

• How do you customize work item types?
• (What) team size to justify the usage of Team System?
• What's new and improved in VSTS 2008 vs. VSTS 2005?
• Continuous Integration (x 3)
• What performance degradation (can occur) from extensive branching?
• Integration with external tools (e.g. Mercury Quality Center, Doors)
• TDD
• Multiple builds running at the same time
• How to limit CI build to only trigger when for certain check-ins (by location)
• Best practices
• How to customize Code Analysis
• What makes VSTS more beneficial than VS Professional?
• What is Team Foundation Server?

And my personal favorite:

• I'm here to see if you're a good presenter because my company is thinking of bringing you in for a day to teach the team.

For those of you who attended my talk, here's a link to my notes and my worst practices presentation.

In many Agile development processes, there exists the idea of THE BACKLOG. This is particularly true in Scrum, the methodology that originated the idea. The recipe from Scrum is a Product Backlog which contains all the requirements or features desired in the software being created.

The backlog items are organized in priority order, determined by the Product Owner (PO). The PO can use any criteria to prioritize the backlog items. Priorities may be driven by risk, return on investment, or client demand. No matter what technique is used, this prioritization is crucial to the use and effectiveness of the backlog.

This all works quite well in a  situation of a single team creating a single product. It even works well when we scale up a bit and have one team working on several products. It just becomes necessary for the two product owners to strike a bargain on how to share team capacity.

It turns out that scaling to even bigger scenarios with an Enterprise Backlog and many teams working from it presents some new challenges. In this model you manage all work in the enterprise in a single backlog. This immediately draws into question what the "real" backlog is. Backlog managers may be interested in a view of the backlog that shows the prioritized list of items for a particular system, a team, a product, a release, or some other grouping.It becomes quickly apparent there are many ways to "see" the backlog.

Which Backlog View Wins?

Obviously, a PO is primarily interested in the view that shows the backlog for a particular product. For a release manager, coordinating the overall release of a product suite, the view of items to be included across many products in a big release is the perfect view. If you are a project manager, interested in a theme of work that will affect many products (think the Smart Art feature in Office 2007), you are looking for the theme view. We can think of this problem as dimensions in a multidimensional cube if it helps you BI types.

With all these views of the backlog going on, and each one of theme prioritized from 1-n, which one is the actual backlog?

• Theme View
• System View
• Release Cycle View
• Scrum Team View
• Product View

The easy answer is, "They are all important, depending on who you are and what you are interested in." It is true, though, that two of these view are closer to reality than all the others. While most of these views represent what we hope will get done, 2 of them are just a bit closer to what will get done, or has been done.

The Scrum Team View

This view aggregates the work items into a collection that actually represents what the team will be doing. This is the backlog the team will use in Sprint planning as they plan an iteration of work. If you are a theme owner and your work items aren't showing up in the Scrum Team View, you're in trouble.

The Release Cycle View

This view (and an associated burndown chart) helps us see the reality of features that are scheduled for release and those that have been completed. This view represents the absolute reality of what we can tell the clients will be in the next release.

Just Get Them

The real truth is that all of the views really are important. The real challenge is in deriving the views in the first place. If you are trying to work with an Enterprise Backlog and haven't got a good model for segmenting it, you may soon find it unwieldy. Find the right view to help you interact with the requirements and make sure your backlog items provide the data needed to see it. Just remember the 2 views that live closer to where the rubber meets the road.