Practicing .NET

Improving developer productivity and software quality

March 2007

The Microsoft Patterns & Practices group is busy updating the highly successful Smart Client Software Factory (SCSF) that was released in July 2006. Afterwards, the team moved on to the Web client version of the toolkit called the Web Client Software Factory (WCSF). However, they're back now evolving the SCSF to support new features including integration with the Windows Presentation Framework, Microsoft Vista, Visual Studio 2005 SP1 and SQL Compact Edition.

If you are doing anything with desktop-based .NET applications (even one that you wouldn't call a Smart Client), do yourself and your team a favor and get a free copy of SCSF. You can find it here at CodePlex which is the P&P team's area for hosting these projects. There is a wealth of samples, tutorials, etc that you can refer to when getting started with SCSF.

This is one of those rare software offerings that provides a team with a sound and well thought out architectural model for developing applications. Instead of worrying about how various parts of your object model, UI, database layer, etc will "talk" to each other, SCSF provides subsystems that will help with this. Parts of SCSF also help by generating code to ease the creation of new forms, business objects and so on. Particularly if you want an architecture which offers a pluggable component model whereby you can add or remove functionality at the assembly level, SCSF is definitely the ticket.

I was fortunate to be asked to participate on the Advisory Board of SCSF for V1 and Microsoft has asked me to participate again for V2. You can track the progress of the team in V2 by bookmarking Blaine Wastell's blog (the PM of SCSF).

Let me know if you've been using SCSF and what your experiences have been.

Posted by Mark M. Baker at 04:09 PM  Permalink |

The Microsoft Patterns & Practices team held a workshop on the newly released Web Client Software Factory (WCSF) toolkit on March 12-13 in Redmond WA. The WCSF is the web client version of the Smart Client Software Factory (SCSF) that was released in early 2006. I was fortunate to be involved with Microsoft as a member of the Advisory Board that reviewed the software as it went from conception to release. Suffice it to say, Microsoft hit another home run with this handy addition to the tools available for web developers.

It brings a much needed architectural model to the back end of a web site while leveraging the best of ASP.NET and 3rd party vendors on the client side. You can learn more about the WCSF by going to the CodePlex site. There is a wealth of tutorials, programmer's guides, samples and other materials to assist you in getting started with this toolkit.

Watch the WCSF site for more notices on the March workshop (and future ones). Microsoft often releases the videos of these workshops for those who couldn't attend.

Posted by Mark M. Baker at 12:03 PM  Permalink |

In Scrum, Velocity is the term applied to how much work (or weighted points of work) is completed during a given Sprint. The Velocity metric can be used to evaluate a variety of items including whether the team is selected an appropriate amount of work for a Sprint, how much work to select for a future Sprint, and as a way of comparing increases in productivity in a team over time.

However, the Velocity number itself has no special meaning outside the team. That is, if my team has a Velocity of 12 and yours has a Velocity of 20, that doesn't mean you are roughly 50% more productive than me. The weights we assign to the same item might differ so the total number of points itself is not important as a measure of comparison.

But it can be exceedingly useful for a team that is using Scrum and trying to decide how much work to select for a Sprint. Say a team initially selects 20 points of work for the upcoming Sprint. They begin work and things go well initially. Later on, problems occur for a variety of reasons and items in the Sprint don't get completed properly. At the end of the Sprint, the Team reviews the Sprint and sees that only 15 points of work was actually completed. We would say that their Velocity is roughly 15 points at this time.

During the planning meeting for the next Sprint, the Team could use this information to guage how much work to select. They could decide that the problems that occurred were one-of-a-kind and elect to do 20 points of work again. The smarter team would realize that things happen during a Sprint and they may very well happen again - people get sick, technology doesn't work out as expected, things take longer than expected and so on. So they may decide to take 15 or 16 points of work for the next Sprint.

Of course, the work performed in each Sprint differs and the same Team might be able to do 15 points of work one time, 18 points another time, and 16 points after that. As time proceeds, a weighted average of the last 3-5 Sprints can be created to drive the decision as to how much work to select.

Velocity also has the nice benefit of allowing the Product Owner to devise a rough Release Plan for the project. That is, if there are 200 points worth of work in the backlog, and the team can do 20 points of work each Sprint, then it's roughly 10 Sprint's before they will be ready. This information can be used to generate a rough estimate of an end date assuming everything on the backlog will be completed. This is very different than a Team that attempts to work out all of the details up front in a Waterfall model project and drive the end date from the sum of all of the little estimates for tasks. They would inevitably leave out items or overestimate their ability to accomplish particular tasks. The end date then slips as the project proceeds and they end up as most projects do - late, less than desired quality and with an exhausted Team.

Understanding what Velocity is and how it can help a Team and the Product Owner understand how fast work is getting done and when a product may be ready for release is a key part of Scrum. It's not a magic bullet however. A Team that performs work that wasn't on the backlog, moves partially completed work from one Sprint to another without accounting for the weight of that work, and so on will end up with a misleading Velocity.

Next time, I'll finish up with some thoughts around Sprint Retrospectives and why they are an important part of Scrum.

Posted by Mark M. Baker at 06:35 PM  Permalink |