The most often seen example on the Internet today is arguably the inclusion of Google Maps or Windows Live Maps in a website. Instead of implementing mapping functionality, turn it over to Google or Microsoft via a specially crafted URL that returns back the needed information. Where in the "old days" this would have been attempted with binary components such as ActiveX or byte-code components such as Java applets, the web is increasingly moving to more dynamic contact such as AJAX to support these features. This makes it more browser-agnostic and easier to deploy in corporate intranets where there can be vigorous security systems in place.

As an example, one of the interesting ways to include Windows Live in your site is to make us of Windows Live ID to manage authentication of your users. This requires the end-users to have (or create) a Windows Live ID to work, but it makes it possibly to implement seamless logins without creating a lot of authentication, user account management services on the back end. Microsoft has even created a helpful SDK that provides samples and illustrations on integrating Windows Live ID into a site.

Live Search is also another area that is going to be very useful to sites that need a Search capability but don't have the time or resources to create a search database of their site (or buy an appliance such as those from Google that will do this automatically). Instead, the developer embeds some HTML and Jscript into the page to access Live Search and Microsoft takes it from there. They limit this to 10,000 hits/day and so it isn't going to spawn some Google look-a-likes out there, but it is useful to many medium-size corporate web sites that won't have huge numbers of search hits.

I highly recommend taking a stroll through the large and growing collection of services from Microsoft Windows Live. You can find more here.

Since we use Scrum heavily as our process, the ability to integrate 3rd party templates into TFS to ensure it conforms with Scrum was also hugely helpful. Again, the tool serves us, not the other way around as is often the case with groupware products. My only complaint is that TFS still isn't making it easy to perform upgrades of templates when they need to change. Even now, you have to export all of the data to something like Excel and then re-import it back into the new template. This is ok for small projects, but not when they grow to include thousands of work items and gigabytes of source code. Hopefully this is an area that Microsoft will spend more effort on in the next version of TFS.

http://msdn2.microsoft.com/en-us/vstudio/products/aa700830.aspx

Wrong.

In my own case, we have outsourced some non-core business functions to outside company's, some staff have elected to move to other lower-cost jurisdictions, and yet there are staff here at the main office. Together they form the Team of people around a project. Since for us this is the way we run the business, the challenge is to find ways to adapt to the various aspects of Scrum.

The first consideration is whether the Daily Scrum is still meaningful if some or all of the Team members are distributed.

The short answer is Yes, and quite possibly even more meaningful since people are distributed. The Daily Scrum functions as a point of coming together as a Team to ensure everyone knows what is going on in the Sprint. It's quick and as I mentioned earlier has a particular structure. However, the essence of the Daily Scrum is its focus on communication. The aspects of the Daily Scrum such as the standup, the dedicated time, and so on serve to keep the meeting on track and regular so it's effective. They are important but only as support aids for the purpose of the Daily Scrum - ensuring everyone knows what is going on day-to-day. For a distributed team, getting everyone together for a stand-up is not possible obviously. The challenge then becomes how to accomodate the lack of physical proximity with the need for regular, effective communication.

A solution I've found effective is the use of teleconferencing. We use WebEx as our meeting software since it's web based, and supports the need for video and audio access by a group of people. So to support the Daily Scrum, I setup a recurring meeting that meets at the scheduled time for the Daily Scrum. An email was sent out to the Team that included the call-in number and access codes. This also gave people the ability to call-in who were offsite and away from their usual work location. In our case, sure enough at the dedicated time, people start appearing in the conference call and we get started once everyone "arrives". 15 minutes later we're done. The communication among team members has happened, people know what's going on, what happened yesterday and likely events for today. They also know where the burndown of the Sprint stands.

Can you retain the standup aspect to a Daily Scrum with a WebEx call. Clearly not. But the standup aspect helps keep the meeting to 15 minutes since people get tired of standing. A well-running Team that understands and has internalized the meaning of the Daily Scrum is usually anxious to get going with talking about their status in a brief manner so everyone can speak and be heard. I've rarely found a Daily Scrum running past 15 minutes, and typicall they finish much faster than that. People walk away from the WebEx call with the information they need, and the Team continues working effectively in the Sprint. That's the essence of the Daily Scrum.

This extends to planning and review sessions with the Product Owner. In our case, we use WebEx to do the review of a finished Sprint by showing the software via a projector on a wall in our conference room. We also use Microsoft Team Foundation Server along with a Scrum template that manages our PBIs and SBIs. So after the demo review of the Sprint, we continue with planning the next sprint by reviewing together on-screen the backlog. Editing of the backlog can happen during the meeting if the PO provides additional detail during the discussion that we want to capture. Everyone is on the phone who is away from the main office and can view the on-screen interactions as they happen.

Agile is all about adapting to local experiences and observations. In today's business climate, distributed teams are common and are only going to increase with the relentless drive for efficiency. Scrum is a process that adapts very well to this type of environment with a little help from modern technology.

Until now.

I particularly liked the performance improvements from its new Ajax-style interface, bulk editing of work items (wow, was this needed!), a revamped work item interface, and a better way of showing reports (in separate windows). But this just scratches the surface of all of the changes.

Installation (and upgrading from v1.0) was a snap. The only glitch we discovered is that the default installation path is so long, it can interfere with the ability to interact with Source Control. Basically, the path is too long (beyond 256), and it croaks. Hopefully Microsoft will remedy this by defaulting to a smaller path at installation. We had to un-install and re-install the PowerTool to a smaller path to resolve the issue.

All in all it's an outstanding release and nice to see Microsoft is actively supporting TeamPlain moving forward. A web-based interface to TFS has been sorely lacking from Microsoft and a surprising oversight on their part up to now. But the wait's been worth it.

You know, the control that has work a certain way because it always has. Or because the customer wants it to work that way. Or because the big boss wants it to work that way. Whatever. The point is that sometimes you have to roll your own.

What better way to proceed with this than to be given specific guidance from Microsoft in the form of controls that you can use now. While the control itself may not be everything you need, you can certainly learn a lot of by studying its implementation with a mind to what the P&P believes are ASP.NET best practices. This answers the often-asked-question "What would Microsoft do here?".

Worth a look if you're contemplating creating your own controls for your ASP.NET application.

Go here.

Time for bigger plates.

As a developer, and occasional database architect, this is a fascinating area of progress both from being able to embed query-like mechanisms in code to the idea that such a thing is actually possible. But beyond the mechanics of using something LINQ, what really got me thinking was how this and other like technologies are beginning to move developers up the abstraction chain ever higher and higher.

Years ago, when the language 'C' dominated Windows development, the notion of bundling blocks of code and data together seemed fanciful. It seemed on the one hand easier to understand, and on the other hand more cumbersome than just writing functions and declaring data when and where you needed it. All of a sudden being a really good 'C' language expert able to write super compact code was far less important than being able to "see" objects in an application. The ability to abstract was beginning to be more important than the ability to implement.

This got us just so far before the notion of dealing with objects became common and expected. As machine performance increased over the last several years, the worries about speed of code have continually receded to the point where in the majority of business applications that don't need to scale to tens of thousands of simultaneous users are much less of a concern to businesses than the speed at which those applications are created.

The ability to work with ever greater abstractions, whatever they may be, and whatever evolutionary state that they may be in, will be undoubtably key to the future of software development in .NET. Sometimes when my mind wanders, I do a thought experiment and try to envision the software developer of 2100. What do they use as their programming language? Do they even use programming languages? How large are their abstractions? How many of the performance and algorithmic problems we deal with are still issues then?

Granted, the answers to these questions are unknowable, to me at least. But I think that it's fair to say that over the coming years and decades the types of technology abstractions we'll deal with will continue to grow and evolve. Many will evolve to dead ends. Some will evolve to become workhorses of development. A very few select ones will be revolutionary. Which ones will be those, no one can tell at this point. But as software developers, in .NET especially, the pace of change is relentless.

No one ever said it was easy to be a programmer, er.., software engineer.

For comparison, the August 2007 Netcraft survey, which looks at server deployments on all net traffic rather than only Fortune 1000 companies, also stated significant gains for IIS. However Apache still ranks as first on the Netcraft report, which shows Apache at ~48 percent and IIS at 38 percent.

Microsoft hasn't even gotten warmed up.

Well, yes. The future of .NET is evolving even as I write this. All of the disparate technologies that we focus on right now when reading MSDN, blogs out of the Microsoft developers, and articles written by developers, will be merged into .NET fully as .NET 3.x evolves.

Take a look at the diagram posted by Scott Hanselman.

Is that a doosy, or what? Almost makes you nauseous just looking at it. Especially if you're back up the food chain in the .NET 1.x or .NET 2.x area. Almost makes you feel out of date.

The thing that jumped out at me was the DLR - Dynamic Languages Runtime. This is a new area that Microsoft has pursued to allow dynamically typed languages like Python, Ruby, and JScript more fully play within the .NET universe. As this unfolds, it will be merged more fully into .NET in a new (marketing) term called CoreCLR. A parallel .NET technology called Silverlight will appear and will supplant much of what is done with ASP.NET today.

Staring at the diagram, I was left with the impression of sort of skipping some of the current generation of .NET UI technology in .NET 3.0. That is, a developer is faced with the constant question of "Do I take the time to learn technology X now, or wait for technology Y?". Particularly when large numbers of users in the field still use Windows 2000 & XP, and will likely do so for a time to come.

Don't get me wrong, I'm excited that .NET is evolving and competing head-to-head with technologies like Ruby (and Rails), and Java. But the middle of that diagram looks like a lot of R&D going on.

Interesting? Yes. Fun to play with? Definitely. But worth waiting and watching.

If you miss today's talk, Brad Abrams, GPM for the UI Framework and Services team is giving a talk on the Island on August 30, at 3:00 p.m. Brad will be discussing ASP.NET AJAX and Silverlight. If you're new to Second Life and want more info before signing up, check out www.visualstudioisland.com. Also if it's dark out when you get to the island, you can always Crtl-Shift-Y to force the sun to noon. For more online Silverlight training check out Dr. Dobb's Sparkleball tutorial.

As for Real Life training, Tim Sneath has posted a healthy list of Silverlight and WPF training courses happening in RL all around the globe. The courses are being held throughout August and September by Microsoft partners, including Wintellect, Dunn Training, Developmentor, and others.

0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, and Infinity (the latter is an innovation of my Team for humor-sake).

A 0 is typically a task which is essentially done and is expected to be no work. These tend to be pretty rare, but they can occur. For my teams, we had to drop the 1/2 point weight since our tracking application (TeamPlain) doesn't yet support decimal numbers as weights for items. But if you are using another system, or just plain old index cards, you surely can use 1/2 point weights.

When the Team meets to assign weights to backlog items, especially initially, it can be a challenge to decide what is a 3 or a 5 or an 8, for example. My 3 might be your 5 and someone else's 8. So one tactic I use as a ScrumMaster for new projects is to have everyone vote on their weights for a set of items we're looking at rather than each one. We then write down on the board the weights they applied to each item and compare. Very often there is a pattern of how low-high weights were distributed even if the numbers chosen were different. A discussion then ensues among the team members about the numbers. Very quickly a consensus builds about what numbers seem to make sense for each task and what a "3" means, or a "5".

Now, it's entirely possible that one team's "3" is another team's "5". But that is just fine. In my case, this has happened. A team that tends to assign more points to an item than another team often has a higher velocity overall but that doesn't mean that they get more work done - it's simply the rate at which their weighted points of work get done; since they have higher points to items, their velocity is higher.

However, afterwards, I ask the team to do 2 things. First, I ask them to review their numbers and see if something they marked as a "2" is really twice as large as something they marked as a "1". This continues through the set of items they've weighted. Sometimes it highlights that an item they weighted is out of synch with the weights for other items and they make an adjustment.

Once this is finished, we then review the weights and look at the scale. I don't typically like weights where the median seems to be hovering on the high side around 8 or 13. It doesn't provide enough granularity above that point since the larger numbers are assumed to handle more squishy, undefined tasks, not just bigger tasks. So if I see this happening, I will slide the numbers down a notch or two, and review with the team. This resets the scale so that they are using an 8 or 13 for a larger task although what is larger can be different team-to-team as I mentioned earlier.

This process has resulted in a much smoother initiation of team's into the Scrum practice of weighting items. We also end up with better consistency across Sprints since the team can double-check that their weights for new items are similiar to older tasks which were the same or similiar in nature. If a team assigns a "3" to the task of creating a form, for example, and a couple of sprints later assigns a similiar form creation task as a "5", I will probe to see why. Sometimes this happens because the team discovered that their initial "3" was too small to account for the typical work to create, test and document a form. Often it can be because the team forgot their earlier number and the new "5" is weighting slippage that is occurring.

Part of the role of the ScrumMaster is to watch for and correct these problems that can creep into a Sprint. But ultimately it's up to the team to internalize the effort of creating weights and what they mean to that team. It's a joy to step back from a planning process and see the team moving so quickly through the process of estimating that they are thinking out loud with each other, adjusting estimates based on discussions, and concluding the planning session with agreement around the set of items and number of weighted points. Even in our larger efforts, I'm seeing planning sessions drop from 3-4 hours to 1/2 an hour depending on how well constructed the Product Backlog is, and the preparation of the Product Owner(s).

But that is a topic for another post.