Where have you been?

For those of you who do not know - I have left the MSF team and joined the Project Recovery Team at Microsoft (back in January). At some point, I'll explain what we do in Project Recovery but for now, I want to talk about VSTS. I recently posted the following information to a question regarding my experience with running a project and using VSTS. It's one thing to work inside Microsoft on projects where everyone knows how to use VS and TFS. Outside of the hallowed halls, there can be learning curve to using it. Don't let that stop you. The benefits more than outweigh the costs.

Here is my post and my recommendation on how we got started:

"I run a development team at one of the government agencies and just happen to be a former VSTSer. Getting folks up and running is not a trivial task but we held a quick 2-hour 'how-to' session when we started working with VSTS. Most of our developers were able to get going with CM just based upon this session. The trouble came when we had new folks enter the project. Each one requires a twenty minute one-on-one workspace creation/get/edit/check in explanation. I haven’t met a person yet who has experience on VSTS/TFS coming in.

Getting TFS up and running took roughly half a day but the use of multiple domains (many reports do not have the fully qualified domains in the urls) made us hold off on using the full capabilities initially. We had started development at the same time as standing up TFS which was an interesting process. You look at the work of VS differently when using TFS (get all of those slns out of the documents and settings folders). We restructured our TFS tree a couple of times to put all of the pieces in the right place. Your architects should learn to use the command line.

Build can take some effort especially for more sophisticated apps (we are composite with everything from web/Biz Talk/VSTO/C#/VB script/C++/DB Pro). I’d recommend simple scripting to augment team build. Some of these areas required a few of us to dedicate a couple weeks to get all of the respective components built. It looks easy but gets harder as you get into all of the things that VS can do. Work item migration is still in-progress as our test folks had been using another bug tracking system. Many projects start with WIs first."

Posted Wednesday, June 27, 2007 5:10 PM by RandyMiller | 1 Comments

Writing Good Scenarios

Discipline	Product Management
Role(s)	Business Analyst
Activity	Write Scenario Description

Short Description

Scenarios are used to define the services that the software will provide to the user. A scenario can be thought of as a path through the system and can be represented by use cases or collections of user stories. Most of the scenarios for a system are written at the start of the project to help scope the work and identify the most important features or services of the system to be developed. It is not uncommon, however, that new scenarios are identified or existing ones modified or deleted as the development of the system proceeds and iterations are completed and previewed by users.

Scenarios are user and product, not technology focused. They are written in the language of the user and can be as short as a couple of sentences or as long as a few pages. Each scenario must stand on its own. Scenarios can be written as a collection of steps that the user performs when interacting with the system and the resulting services that the system performs for the user. When writing scenarios, the prerequisites for a given scenario should be spelled out ahead of time. When writing a scenario, it is often best to name the scenario as something that either describes the intended result or the problem the user wants to solve.

Workproduct Inputs

Vision statement or document
Access to domain expert or end users of the proposed system
Personas of expected users of the system

Workproduct Outputs

A description of a path through the system to be developed
An initial understanding of what the end user for that path expects or needs from the system

Checklist(s)

Writing Good Scenarios, items to consider

Check	Description
□	The language of the scenario is that of the target consumer/end user of the scenario, free of technical jargon that is not related to what they will expect and experience.
□	The scenario is concise and deals with a single path through the system. Variations and alternate flows can be discussed but the scenario is not meant to be a complete documentation of the system.
□	Scenarios are used to form a basis for agreement between the software development team and the end users of the system. They should represent a clear picture to each party of what the system is expected to do, and what business limitations the system should enforce for the particular path through the system
□	You will need to define multiple scenarios to describe a single system and should start with the most important ones to the end user. Not all aspects of a system will be described in the collection of scenarios developed. For example, there may be performance or scalability requirements on the system not reflected in any scenario.
□	Scenarios are used to scope the system and help identify requirements of the system. They do not document all of the requirements for the system. Scenarios are used as an input to the requirements gathering and documentation.

Size and number of scenarios

Check	Description
□	Scenarios can be as short as a few sentences or as long as a few pages. Any prerequisites that must be satisfied for a scenario to be performed must be specified in the scenario.
□	Scenarios can be written in a narrative form, as a collection of user stories, or as a numbered set of steps. They should clearly state the purpose or end goal the user has in mind when performing a scenario.
□	Not all aspects of the system will be documented in scenarios and more scenarios may be identified as the development proceeds. You should start with the key scenarios that will define the success of the system.
□	When possible, it is best to name each scenario with the goal that the user wants to achieve when performing the scenario.

Posted Wednesday, January 03, 2007 7:32 AM by RandyMiller | 3 Comments

New MSF Class Available For Partners

Title:

Managing your teams and business process using Microsoft Solutions Framework (MSF) as a template

Abstract:

Microsoft® Solutions Framework (MSF) is a deliberate and disciplined approach to technology projects based work and organization based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft, our clients and our partner community.

This class introduces MSF concepts, provides an overview of its foundational principles, core models, and essential disciplines and then focuses on how their application contributes to the successful running of a services business.

What is Microsoft Solutions Framework (MSF)?

Creating meaningful business solutions on time and within budget requires a proven approach. Microsoft Solutions Framework provides an adaptable framework for successfully delivering information technology solutions faster, requiring fewer people, and involving less risk, while enabling higher quality results.

MSF helps teams directly address the most common causes of technology project failure in order to improve success rates, solution quality, and business impact.

Created to deal with the dynamic nature of technology projects and environments, MSF fosters the ability to adapt to continual change within the course of a project. MSF is called a framework instead of a methodology for specific reasons. As opposed to a prescriptive methodology, MSF provides a flexible and scalable framework that can be adapted to meet the needs of any project (regardless of size or complexity) to plan, build, and deploy business-driven technology solutions.

During this 2-day session, we will discuss how to apply the MSF team and process models to your partner organizations to drive better quality, efficiency and profit

The core focus areas are:

1) Building a team

2) Definition and adoption of the MSF process (delivery) model

3) How to properly manage risks

4) Organizational Maturity overview

5) Tools and processes to help drive better profits and reuse

Agenda:

Day 1:

1) MSF Overview

2) MSF Process Model Overview and its application

3) MSF Team Model and its application

Day 2:

4) Risk Management

5) Organizational Maturity Model (Carnegie Melon SEI)

6) Tying it all together

Class Duration: 2 Days - (9am to 5pm) each day

Target Audience: Microsoft Partner Community

Prerequisites: NONE

Registration: http://www.msreadiness.com/IL_abstract.asp?eid=5014632

Dates:

Date/Time	City/State	Partner Price
Dec 11 - 12, 2006 9:00AM-5:00PM	Irving, Texas	$150.00
Jan 17 - 18, 2007 9:00AM-5:00PM	Orlando, Florida	$150.00
Mar 6 - 7, 2007 9:00AM-5:00PM	Irvine, California	$150.00
Mar 19 - 20, 2007 9:00AM-5:00PM	Atlanta (Alpharetta), Georgia	$150.00
Apr 16 - 17, 2007 9:00AM-5:00PM	Chicago, Illinois	$150.00
May 1 - 2, 2007 9:00AM-5:00PM	Denver, Colorado	$150.00
May 14 - 15, 2007 9:00AM-5:00PM	Waltham, Massachusetts	$150.00
Jun 4 - 5, 2007 9:00AM-5:00PM	Bloomington, Minnesota	$150.00

Posted Monday, November 27, 2006 11:17 AM by RandyMiller | 1 Comments

MSF for Agile Software Development and MSF for CMMI Process Improvement Version 4.1 Available

Yesterday, we released brand new versions of MSF for Agile Software Development and MSF for CMMI Process Improvement. These new versions create the first commercial agile and CMMI-based software development processes with support for database unit tests and refactoring. The release of these processes coincided with the release of our tooling support for these practices, Visual Studio Team Edition for Database Professionals. These new versions also contain several bug fixes and clarifications.

If you are using the Visual Studio Team Foundation Server, here are the instructions to update the MSF versions.

Instructions

If you want to view the guidance

1. Download and extract the contents of the zip file to your local machine. (select Use folder names).

2. In the extracted files, review the Readme.

3. To view the content, open \Process Guidance\ProcessGuidance.html.

If you want to update the guidance in a process template

1. Download and extract the contents of the zip file to your local machine.

2. If required, customize process guidance using instructions available at http://msdn2.microsoft.com/en-us/library/aa730855(VS.80).aspx.

3. Download the process template you want to update guidance on from your TFS server to your local machine.

4. Replace “Windows SharePoint Services” folder in the process template you downloaded from TFS with the one you obtained from the web download.

5. Upload the updated process template back to TFS.

6. When you create a new project using this updated process template, the portal will show the updated guidance.

If you want to replace the guidance already on the SharePoint server

1. Download and extract the contents of the zip file to your local machine.

2. Go to the home page of your project portal.

3. Click Documents and Lists, and then "Document Libraries" in the left menu.

4. Replace all files and folders in the following Document Libraries on SharePoint site from their corresponding folders under "Windows SharePoint Services" folder in the process guidance you downloaded.

1. Project Management

2. Requirements

3. Security

4. Test

5. For the "Process Guidance" Document Library, replace the following files and folders with the new content

1. Folder – Supporting Files along with all the subfolders and files

2. File – ProcessGuidance.html

3. File – version.txt

Posted Wednesday, November 15, 2006 8:02 AM by RandyMiller | 4 Comments

Changes to MSF for Agile Software Development

A common question that I get is "What has changed in the latest version of MSF for Agile Software Development?" There are two reasons that this question is asked. First, people want to know why they should update their projects and secondly, they want to know what files have changed. This blog entry will attempt to answer both questions.

To start, we have tried to clarify a number of the concepts that were being misconstrued by poor wording or organization of the content. These concepts include the role of the Project Manager in iteration planning (they are a facilitator) and the use of Test Driven Development (earlier versions slated this as optional).

As for which files have change, the answer is all of them have. However, only a dozen or so have changed in a meaningful way. The rest have the new copyright and release information. Choose from the list below based upon you needs. I recommend adding files for the Plan an Iteration Collaboration. Check out the files from your project portal and replace them with these new ones.

Plan an Iteration Collaboration

architect.htm (clarified collaboration on plan an iteration workstream)

architect_plananiteration.htm (new file - clarified collaboration on plan an iteration workstream)

architect_showall.htm (clarified collaboration on plan an iteration workstream)

businessanalyst.htm (clarified collaboration on plan an iteration workstream)

businessanalyst_plananiteration.htm (new file - clarified collaboration on plan an iteration workstream)

businessanalyst_showall.htm (clarified collaboration on plan an iteration workstream)

developer.htm (clarified collaboration on plan an iteration workstream)

developer_plananiteration.htm (new file - clarified collaboration on plan an iteration workstream)

developer_showall.htm (clarified collaboration on plan an iteration workstream)

dividequalityofservicerequirementsintotasks.htm (clarified how the division gets done)

dividescenariosintotasks.htm (clarified how the division gets done)

plananiteration.htm (new collaborations)

tester.htm (clarified collaboration on plan an iteration workstream)

tester_plananiteration.htm (new file - clarified collaboration on plan an iteration workstream)

tester_showall.htm (clarified collaboration on plan an iteration workstream)

workstreamsindex.htm

Test Driven Development

fixabug.htm

Broken Link Fixes

brainstormqualityofservicerequirements.htm (fixed broken link to ‘howto’)

brainstormscenarios.htm (fixed broken link to ‘howto’)

buildaproduct.htm (fixed broken link to ‘Team Build’)

closeabug.htm (removed extraneous links)

createorupdateunittest.htm (add link to TDD information)

developlefestylesnapshot.htm (fixed broken link to ‘howto’)

fixabuild.htm (fixed broken link to team build)

mitigatearisk.htm (removed link to MSF home page)

qualityofservicerequirementlist.htm (fixed broken link to actual work products)

reviewobjectives.htm (fixed broken link to scenario list)

scenariolist.htm (fixed broken link to actual work products)

selectandrunatestcase.htm (added link to test case management)

startabuild.htm (fixed a broken link to help system)

testaqualityofservicerequirement.htm (added link to test case management)

testascenario.htm (added link to test case management)

Added Queries

cycles_dailybuild.htm (added queries for this area)

cycles_iteration.htm (added queries for this area)

projectmanager_guideiteration.htm (added queries for this area)

projectmanager_plananiteration.htm (added queries for this area)

projectmanager_showall.htm (added queries for this area)

tracks_build.htm (added queries for this area)

Additions to the glossary

glossary.htm

New Mindsets

mindsets.htm

principles.htm

teammodel.htm

Posted Wednesday, October 11, 2006 8:57 AM by RandyMiller | 1 Comments

Filed under: MSF for Agile Software Development Errata, MSF for Agile Software Development

New Version of MSF Available

There are newer versions (August 2006) of the MSF process guidance available for download. There has been a few issues with unzipping the CMMI process guidance. Take a look at Rob's post on this subject. Remember that if you want to replace the guidance on an existing project, you need to checkout the existing guidance from the project portal.

We will be moving the MSFWinBuild site from GotDotNet to CodePlex in the near future. When we move the site, we will also make the process guidance source available on it as we currently do on MSDN. We will update them with major releases simultaneously. However, we are considering smaller releases and community feedback through this forum.

Posted Tuesday, September 19, 2006 8:58 AM by RandyMiller | 0 Comments

Filed under: MSF for CMMI Process Improvement, MSF for Agile Software Development

MSFWinBuild and Patterns and Practices

Many of you have been looking for an updated version of MSFWinBuild. Sanjeev and his team have taken what Rakesh previously built, refined it, and packaged it up nicely. Take a look at our GotDotNet site and download the latest executable (under the Releases link on the left hand side). We still have the source code for this xml to html compiler available so feel free to join this community and contribute to the site.

Many of you may not have heard of the news. MSF and Patterns and Practices are now part of the same team. To see many of the folks who I am now working with, check out the Patterns and Practices individual blogs. The way that I see it, MSF has just gotten a whole lot bigger. Some of these folks were instrumental in helping me out with MSF for Agile Software Development.

Speaking of MSF, I have changed roles slightly. I am now working with our customers to get feedback for the next couple of releases. If you see something that you would like, please give me a shout. I am always looking for feedback.

Posted Wednesday, August 23, 2006 7:59 AM by RandyMiller | 1 Comments

Filed under: MSF for CMMI Process Improvement, MSF for Agile Software Development

Writing Scenarios: Part 1 Identification

I get many questions about writing scenarios, but writing scenarios in general is a four-step process: identifying the scenarios, prioritizing & estimating scenarios, authoring scenario narratives, and decomposing scenarios into tasks. This blog entry looks at the first of these categories of questions, identifying scenarios. We start by identifying our scenarios to ensure we create scenarios in an agile way. As we traverse all four parts of this subject, you will see how agile scenarios can be.

There are actually many ways to brainstorm scenarios. A simple way is to gather your customers in a room and brainstorm with them. However, there is a more methodical approach, which starts by having the customers define the goals of the system similar to the way that we define these goals in use case modeling [Miller 2001].

A scenario is a single path of customer execution through the system. We ideally want to create very thin paths that we can augment as we go through each iteration. There are the “sunny day” scenarios, which provide the shortest paths to success. For example, in an online DVD rental system, the goals might be as shown in Figure 1.

Figure 1: The Scenario List

Each of these is potentially a scenario of the system. There are also exception scenarios where we look at things that affect these success scenarios. For example, we might have the maximum number of videos rented by a customer, and thus we might prohibit them from renting any more before returning videos.

When we are brainstorming scenarios, we don’t actually write the scenario narratives. Instead, we only use the names of the scenarios as placeholders to remind us that there is functionality to implement. We call these names scenario entries in the scenario list. A scenario entry is usually of the form, “goal : path” and might contain some notes on the differentiating factors or the thing that differentiates this scenario from the others. Usually the differentiating factors are clear from just reading the scenario name.

In the course of prioritizing & estimating our scenarios (described in Part 2), we may find that some of our scenarios are too big for a single iteration. To deal with this, we split these scenarios into smaller scenarios. These new scenarios should always provide customer value. For example, we might find that the sunny day scenario for “Rent DVD” is too big. In looking at this scenario, we can divide it into several smaller, customer-valued scenarios (as shown in Figure 2).

Figure 2: The brainstormed scenario list

Perhaps a simpler scenario than the “Rent DVD” scenario is to rent a single DVD. In this scenario, we search for a DVD by name and add it to our cart. Subsequent scenarios might allow renting multiple DVDs, add search options, and increment the number of DVDs rented with the appropriate new billing.

Posted Wednesday, August 02, 2006 10:50 AM by RandyMiller | 4 Comments

The Latest in MSF News

There are so many advances on the MSF front that I wanted to take some time and document all that is happening. First, for those of you who have never seen MSF for Agile Software Development, there is a recorded webinar available.

MSDN Webcast: An Introduction to Visual Studio Team System and the Microsoft Solutions Framework (Level 200)

There is a bit of registration information to wade through but after you "register", there is a recorded version available. This webinar has about 30 minutes of slides and an equal amount of demo. Download it and skip to the end to see the demo. Then go back and hear the slides. It turned out quite nicely except that I ran out of time!

On the MSFWinBuild front, we have all of the pieces finally ready! There is a GotDotNet site where we have put out an initial preview. Download the latest source from the MSF for Agile Software Development site and try out the compiler. The compiler is still in alpha mode but check it out!

For those of you who want to see live MSF presentations, check out the upcoming Microsoft TechEd (Boston), Architecture and Design World (Chicago), and SD Best Practices (Boston). I will also be at the Agile Conference in Minneapolis. We will be giving out very detailed MSF information at the TechEd presentation so I hope to see you there. I will be providing more information on Shadow Architecture at Architecture and Design World as well as a tutorial on creating Secure Architectures. At SD Best Practices, I will talk about Second Generation Agile Software Development Processes and several other topics.

The work around MSF is truly exciting! We have been planning our next release and are welcoming a tighter relationship with the Patterns and Practices folks. PNP has always been a fantastic contributor to MSF. With adoption of Agile Software Development Processes on the rise, expect to see even greater improvements to VSTS and MSF in the near future!

Posted Thursday, May 04, 2006 12:11 PM by RandyMiller | 3 Comments

Errata: Divide Scenarios into Tasks

Activity: Divide Scenarios into Tasks

Project Manager

Plan an Iteration

Task

Participating Roles

Responsible:

Project Manager

Consult:

Architect

Developer

Tester

Overview

Entry Criteria

Dependencies:

The scheduled scenario description is written and storyboarded if necessary.

Sub-Activities


1	Gather the Team	Gather the architects, developers, and testers who will be working on or impacted by this scenario. The project manager facilitates this brief meeting or email discussion and records the tasks.
2	Identify Architecture and Development Tasks	Begin where the scenario differs from previously implemented scenarios and follow the control path through the system. Consider user visible features, changes to the underlying infrastructure or data structures and items that have architectural impact. Identify how system components are affected when implementing the planned scenario. Ensure that the architecture will be able to handle the scenario. If architectural changes are necessary, create the roadmap and tasks for refactoring the architecture to the new state. Split the scenario if necessary. Create a new development task for each major area of the system impacted by the scenario. For each task, describe the new or changed functionality. Keep the tasks broad enough to allow design to emerge but focused enough that a single person could complete them in one to three days. Group low level changes that are logically related into higher level tasks. Further divide high level changes and additions into lower level tasks if they are broad. Review the set of tasks to ensure that they adequately address the scenario.
3	Choose Architecture and Development Tasks	Architects and developers choose their own tasks. Check to make sure all architecture and development tasks are chosen.
4	Reassign Scenario to a Developer	Reassign the scenario to one of the developers who owns development tasks for that scenario. This developer’s job is to test the end-to-end integration of the development tasks.
5	Create Test Tasks	Update the test approach document for the iteration, filling in the test data and other sections. Create a set of tasks to create the necessary test cases to achieve the goal of the iteration. Determine which tests can be automated and added to the iteration tests. The iteration tests run after the build verification tests.
6	Choose the Test Tasks	Allow the testers to choose their test tasks. Check to make sure all test tasks are chosen.

Exit Criteria

	The initial iteration plan contains tasks describing all work necessary to fulfill all the scenarios scheduled for the iteration.
	All tasks created during the brief meeting are chosen.

Posted Tuesday, April 18, 2006 7:24 AM by RandyMiller | 2 Comments

Filed under: MSF for Agile Software Development Errata