How can the United States (and other countries) stay technically literate?

Thanks to plastic bricks from Denmark, kids in the United States (and all around the world are learning to program at age 8). I had the priviledge of coaching a young team of NC kids (9 to 11 years old) to win the NC State Championship in FLL in three years. The Microbots were a dedicated group of kids, none of whom knew how to program when they started FLL. One of these kids quit football to dedicate himself to programming. I tell folks about this program all of the time. If you have a child, aged 8 to 13, and you don't think that he/she will be a pro-football player (wow - the odds are 1:a gizillion) when he or she grows up, get them on the leading edge of technology (oh and he/she can play with plastic bricks too).

OK - so you have an older kid? There is a corresponding program for high school kids. Microsoft has graciously sponsored Team Awkward Turtle, a high school team from Southwest Wake County in NC (five local high schools and the home schoolers too). Check out this robot! High school kids built and programmed this! I spend a certain amount of my time training the next generation to be great!

I recently showed pictures of the team to a researcher from China. He said that they didn't have anything like this happening in their high schools. I say this not to bust on China. I am so sure that it is just a matter of time before they are doing this too. My point is, your sons and daughters will be competing with these kids (from all over the world).

I love watching football and look forward to spending my Monday nights watching the stars but I will feel much better about the world at large if more people were doing this on their weekends like I am.

What is Shadow Architecture?

Shadow Architecture is method of communicating architecture to others on your agile team. The idea is that components and classes cast "shadows". These shadows are simplified views of the code base. UML is a type of shadow. We can look at a UML model of a piece of code and we can say some things about the code but we know that it isn't "the code". Sometimes though, when we want to teach a new team member where things can be found in our ever growing code base, we draw a quick UML diagram. Anyone see BDUF in this example? No, good.

Another example of where "shadows" come in handy is when we are making an architectural change during an iteration. We draw out what we want the architecture for our code base to look like at the beginning of an iteration (or during it) and refactor the code accordingly. Multiple developers can work on these architectural changes simultaneously since they are all on the same page. But they can't unless they really are on the same page and a "shadow" gives us a place to start from. Of course, constant communication during these refactorings is also a must. You might redraw the architecture when you encounter problems or learn more. Common sense, right?

So we call the first example, the one where we have an existing code base and describe it using a modeling language, a trailing shadow. Trailing shadows are used to communicate what exists in our code. The second example is a leading shadow. We use leading shadows to talk about what we want the code base to look like. Both shadows are descriptions of the code base and should be generated (by hand or machine) in no more than a couple of minutes. Certainly not BDUF.

OK - so here is the most important part. At the beginning of an iteration, we can talk about refactoring the code base architecturally to allow us to add additional functionality (remember Ward's definition). We would quickly provide a leading shadow and get to work, adding the new functionity! As the sun sets on the iteration, the leading shadow should be gone and all that remains is the trailing shadow. Definitely not BDUF if every architectural change that you make spans the scope of an iteration.

To give credit where it is due, I collaborated with Bill Gross (of VSTS Architect) on Shadow Architecture. I believe that he came up with the name. MSF v.4 had this concept (perhaps convoluted as that much of the process seems to have been in retrospect). I also have to give cudos on this to Scott Ambler because it is definitely an extension of Agile Modeling.

Agile Architecture

Programming with Kids and Adults

It has been five years since I joined Microsoft and started writing MSF. There are a couple of milestones that this anniversary brings that I would like to share with you. First, the MSF book is not published and you have a right to ask why. Second, the robotics team that I have been mentoring (all 11-13 year olds) won the NC State championship and will advance to the National one. All of these kids can program extremely well as they have been working on building and programming robots for three years straight. Third, I continue to see the same negative patterns in (recovery) projects and I have been wondering if there is a way to process some of these patterns out of existence.

Some of you may not be aware that I have been working with two robotics team, one younger and one older. As I was working with the older Robotics team (high school kids), I happened to see a problem that I frequently encounter on projects. We were trying to test the robot in a museum on a simulated ice floor. The code for the drive control system was being finished on the way to the museum which is similar to the way many adult projects are done. When we got to the museum, we couldn't download the code to the robot.

Now, it turns out that we had fried the drive controller by static electricity from the simulated ice floor so it didn't matter. But as I thought about the current project that I was working on, it occurred to me that it had the same problem. One fellow who was working on it was out for the week and had no realistic backup. He had changed some of the code and it wasn't working as intended. We hadn't found the problem until he had left for vacation. It was an honest mistake (and one where he will have a pair from now on). But the delay cost the project.

A stitch in time saves nine.

I look back on the original manuscript for the MSF book and I don't like it. The whole introduction about second generation agile processes needs to go. My thinking was clearly flawed (some would say on several aspects :-)).

We are rewriting a piece of one project that I am working on because we now know more about this area than we originally did. The area works but it isn't elegant and certain bugs are unfixable. We have learned by doing once and then doing right.

But sometimes, like good wines, things have to age.

What has this got to do with programming kids, the MSF book, my projects, and my anniversary? I suspect that all have been influenced by stitches in time and aging. But sorting out the things to age and the things to rush is always the hard part. I suspect that we should always strive to do something and then evaluate how well we did. That is far better than waiting until we get it 100% right.

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."

Writing Good Scenarios

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

Size and number of scenarios

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:

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

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

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.

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.

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.

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!

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.

How to Change the Process Guidance on an Existing Team Project?

It is pretty easy to change the process guidance for a new project but a common question that I get is "how do I change the guidance on an existing team project?" I want to start by scoping this post. I am just talking about the html pages or process guidance that exist in the team project. This blog does not describe how to change the work item definitions or reports.

To start, in the Team Explorer, bring up the context menu on the team project that you wish to change. From the menu, choose "Show Project Portal...". When the Project Portal comes up in a web browser, click the "Process Guidance" link on left hand side, in the "Quick Launch" view. When the process guidance comes up, remove "ProcessGuidance.htm" from the URL. In other words, bring up the URL http://ServerName/sites/ProjectName/Supporting%20Files/ in the browser where ServerName is your server name and ProjectName is the name of the Team Project that you want change.

You should get a sharepoint view of the "Supporting Files" directory. In order to change the existing files, you must first check them out. Check out the files that you wish to change and upload the changes. You may want to check them back in so that they don't get overwritten. That's it! If you have the necessary permissions on the Team Portal, you can make the changes. These changes are also visible from the Team Explorer. When adding new files, you may need to leave VisualStudio and reeneter it to see the updates in the Team Explorer.