Practicing .NET

Improving developer productivity and software quality

April 2007

The Microsoft Patterns & Practices team held a workshop in Redmond on March 12 & 13 covering the Web Client Software Factory (WCSF). These workshops are a great way to learn about the latest P&P offerings from the actual team doing the development. If you get a chance to attend one, I highly recommend it.

The Microsoft team has made freely available the materials from the workshop which you can use to learn more about WCSF.

Also, Glenn Block has joined the P&P team at Microsoft taking over the Product Manager role from Eugenio Pace who moved on to the Architecture Strategy team. Welcome Glenn!

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

If you're using Microsoft Team Foundation Server to manage your software projects - version control, schedules, project documents, and so on, you probably noticed that Microsoft didn't provide web-based access to TFS. This was most unfortunate given the number of non-developers such as project leads, documentation specialists, quality assurance, and other personnel who need access to the information in TFS but don't want to be forced to use Team Explorer. From my own experience, walking a non-developer through how to install Team Explorer, configure it and use it is not a straightforward task. There are many steps that can go wrong and you end up with endless calls that files can't be accessed, files are being extracted to the wrong location, and so on.

However, there was a 3rd party solution developed by devBiz Business Solutions called TeamPlain - Web Access for Team System that allowed using the browser to access all of the information in TFS. All a user needed to do was connect to the internal portal site hosting TeamPlain which handled connecting to the TFS system on the network and translating forms, reports, etc that reside in TFS into browser friendly (and nice looking) pages.

The pricing was somewhat steep particularly for smaller shops or those with limited budgets. But if web access to TFS was paramount, then TeamPlain would be a great solution. However, the clamor from teams for a web-based solution apparently got Microsoft's attention because on March 26, 2007 Microsoft acquired devBiz along with TeamPlain and is adding it to the standard TFS package.

Even better, it's now free!

An updated version (v2) of TeamPlain was under development by devBiz, and Microsoft has announced that it will be released in the Orca timeframe. But the advantage of Microsoft buying TeamPlain now is that you can freely install and use the software.

I've been using it in my projects for a while now and it's a super way to access TFS even if you use Team Explorer for day-to-day work in Visual Studio. I highly recommend giving it a look.

http://www.devbiz.com

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

A key element in Scrum is what happens at the end of a Sprint, namely the Retrospective. Now, I like many of you have sat through end-of-project "post-mortem's" many times in my career. Often, they are a sort of feel good review of the project over its life, comments are made about the good and maybe the bad, some notes are taken, everyone leaves and promptly forgets about what was said.

Not so in Scrum.

In fact, Scrum doesn't just promote an end-of-sprint Retrospective, it requires them. Remember that at the beginning of this series I said that Scrum's mantra is "inspect-and-adjust". Well, you can't adjust if you don't inspect. And if you don't adjust, you won't know what to change in a coming Sprint to make it work better. To that end, Scrum has some very specific rules about what to do in a Retrospective.

First, the Retrospective is held as a time-boxed meeting of no more than 4 hours. This occurs on the last day of the Sprint typically after an end-of-sprint review of completed items with the Product Owner. The whole team gathers minus the Product Owner (and any Chickens). This meeting is required so the Team needs to be encouraged to consider this a time when they can put their heads together and see what they can do to affect a future Sprint.

Second, there are 3 questions that are posed on a whiteboard, flipchart, etc for the group. They are:

What went really well (i.e. what do we want to continue)?
What didn't work very well (i.e. what do we can to stop)?
What do we want to change?

Similiar to the 3 question format of a Daily Scrum, the Retrospective has a similiar framework addressing the past and the future. What I do in these meetings is to write the questions on the board as columns. Then as people begin commenting on them, I start writing down their observations as the Scrum Master. You can start by "going around the room" in an orderly fashion or starting with the most vocal person first. In my experience, there are usually 1 or 2 people who are eager to get thoughts off their chest and this can initate a lively discussion. So I usually start by going to those people first. However, it's very important that each person get a chance to talk and no one is overlooked. It's perfectly fine if a team member doesn't have anything extra to add, but they do need to be encouraged to shout out anything that they can think of.

It's important as the Scrum Master to manage this meeting well and keep things moving along without rushing people. This can be a fine line. You don't want a meeting to degrade into off-topic discussions, or items which don't fit into the 3 question profile. Just as in a Daily Scrum, the meeting has a purpose and for it to be successful, it has to stay focused.

You may find also that one or more of the columns has few or possibly no entries. Although unusual, it's important that the Team with help from the Scrum Master find the items that go into the lists. As a Scrum Master, I will often mention some items I've observed myself particularly if the Team is struggling to get started, but in general the danger of a Scrum Master coming up with the list is that it turns into a typical meeting where one person does all of the talking and everyone else nods off.

The best Retrospectives are the lively ones where people feed off each other in the discussion and the Scrum Master acts as a coach keeping things moving along, writing down key points, and so on. You may find that you don't need the full 4 hours. In my experience, we've never needed that long to discuss a 30 day sprint. Once everyone is finished, the Scrum Master goes back over the list and asks if there are any final changes or observations. If not, the list is transcribed, etc into a more permanent format and provided to the Team. In our case, we use Microsoft Team Foundation Server and use that system to track retrospective documents for each Sprint. But you could send these out as email, paste them on the wall, etc. Whatever works, as long as everyone gets a copy.

Finally, the Team should be encouraged to review the list during the next Sprint. The items that shouldn't be continued should be dropped if possible, and suggested changes should be accomodated. However, if the lists are long, it's very unlikely that a Team will be able to make all the adjustments in a single Sprint. So it's important for people to make the number of changes that they think they can without undue pressure to make a major number of changes all at once. The key here is gradual improvement over time.

I've gone on about Scrum and its practices for several postings now. I think it's time to bring this to a close for now, but I'll come back to Scrum and Agile as time goes on. Hopefully, you've gotten an appreciation for how Scrum works, how flexible it is, and how significantly it can affect how your team creates software (or anything else for that matter).

If you are using Scrum, or decide to try using it, send me a note and let me know how you're progressing.

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