Randy Miller's Blog

Programming with Kids and Adults

RandyMiller — Tue, 10 Feb 2009 16:14:00 GMT

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?

RandyMiller — Thu, 28 Jun 2007 00:10:00 GMT

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

RandyMiller — Wed, 03 Jan 2007 15:32:00 GMT

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.

New MSF Class Available For Partners

RandyMiller — Mon, 27 Nov 2006 19:17:00 GMT

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

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

RandyMiller — Wed, 15 Nov 2006 16:02:00 GMT

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

Changes to MSF for Agile Software Development

RandyMiller — Wed, 11 Oct 2006 15:57:00 GMT

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

RandyMiller — Tue, 19 Sep 2006 15:58:00 GMT

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

RandyMiller — Wed, 23 Aug 2006 14:59:00 GMT

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

RandyMiller — Wed, 02 Aug 2006 17:50:00 GMT

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

RandyMiller — Thu, 04 May 2006 19:11:00 GMT

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

RandyMiller — Tue, 18 Apr 2006 14:24:00 GMT

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?

RandyMiller — Tue, 11 Apr 2006 17:08:00 GMT

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.

Second Generation Agile Software Development

RandyMiller — Thu, 23 Mar 2006 16:21:00 GMT

The agile software development community is at a crossroads. On one hand, we have been told to use some very simple techniques to create customer value quickly and they have worked! Interact with your customer, use the simplest thing that might possibly work, deliver value. This is all good. The processes that we have used to come to this point have names like SCRUM and XP (version 1). These processes are terrific.

However, if you have been to one of agile conferences recently (or even one of the major software development conferences), you are aware that there is an ever growing array of techniques available to agile developers to incorporate things that were missing from these agile processes such as the use of testers to test. The agile community has not stood still; it is evolving.

In fact, if you read Kent's latest XP Explained book (the green and white book), you get a slightly different view of XP than you do if you read his earlier white book. In the chapter called "The Whole XP Team" (chapter 10), he talks about the role of the Tester, Interaction Designer, and Architect among others (don't just read the first section of the chapter unless you want to get the wrong idea of what he is trying to say). Whoa! What kind of agile blasphemy is this?

The truth is, the agile community has been moving toward perhaps a more centrist (pardon the pun) position for years. Those who are involved in the community are acutely aware that architecture is required especially for larger projects. Not Big Design Up Front (BDUF) architecture but shadow architecture, one that leads and trails the actual inner workings of the project code. The fact that each role often worked as disconnected units had to be broken. For this, we needed to go to the extremes. Kent calls the early versions of XP etudes or lessons (hard lessons) in building functional teams.

The "new" XP is a second generation agile software development process. So is our own MSF for Agile Software Development (a lot of the patterns within it are based on XP). Both processes have techniques for allowing testers to test the software and architects to help with large scale refactorings. Both are directly driven by customers (more on this in a future blog) and this is a critical success factor. They both are also a little more complex than the first generation processes.

The number of people using first generation agile processes is increasing. It is also true that many companies are using a "Chinese menu" (to quote Uncle Bob Martin) approach to creating their own second generation agile processes. Some would argue about the "agileness" of these processes. The truth is, it is all about delivery. If you deliver as rapidly as possible, don't let anyone tell you to stop. It is when things are breaking down or your competition is outrunning you that you have problems.

It isn't surprising to me that many have grown comfortable with the first generation agile processes. If these work for you, continue. What is surprising is the number of people who are advocating these processes that think that a greater number of roles cannot participate and maintain the agility. The agile world is changing. Embrace change.

Quality of Service Requirements

RandyMiller — Mon, 28 Nov 2005 22:56:00 GMT

The name 'Quality of Service Requirement' was suggested as alternative to 'nonfunctional requirement' or 'quality attribute' in MSF for Agile Software Development by Sam Guckenheimer. In retrospect, I believe that it was a good idea. 'Nonfunctional requirements' always sounded to me like the way that nasty tasting cough syrup tastes. If you implement a nonfunctional requirement, does your system become nonfunctional? For all who like that name, I am just kidding....

Quality attributes have been studied extensively by the Software Engineering Institute. I first heard about the relationship between quality attributes and scenarios at SD East in Boston this year. As MSF for Agile Software Development utilizes scenarios to achieve a finer level of granularity than use cases, I am always eager to see what others are doing to improve them. I discovered the SEI work after we had adopted an internal Microsoft approach called LAAM which may or may not have been based on it. LAAM and quality attributes are surprisingly similiar.

Nonfunctional requirements, quality attributes, and quality of service requirements are names for the constraints on functional requirements such as performance, security, and platform. There are certainly many more types of quality of service requirements than these but these three are the most common. The important aspect of a quality of service requirement is that it does not describe functionality but instead constrains other functionality, the presentation of that functionality, the implementation of that functionality, or its environment. Since there are many different types of qualities of service, the format varies. For example, we can just list the platforms that we must support (the most important being Microsoft Windows, of course) if all of our functionality is available on each of the platforms.

Life gets tricky when you start getting specific. For example, we can't ask for our system to be 'fast'. 'Fast' is poorly defined and probably in the eye of the beholder. I remember a requirement in one of the requirements documents that I received as a developer asking for the system to be 25% faster. This may have been achievable but it would have been a complete waste of time. For most systems, 20% of the functionality is used 80% of the time. Therefore, optimizing the other 80% of the functionality may yield diminishing returns. In describing quality of service requirements such as performance, we should target specific areas.

For those quality of service requirements that need to target an area, we use the following format: context, stimulus, response. For example, consider the quality of service requirement,

"During a catalog search, return the search results in under 3 seconds.”

"During a catalog search" is the context, "return the search results" is the stimulus, and "in under 3 seconds" is the response. For any targeted quality of service requirement, you can use this format. The context and stimulus should appear in a scenario for any externally visible quality of service requirement.

Quality of service requirements have the greatest impact on the architecture. A good architecture will facilitate easier delivery of quality of service requirements. But then a good architecture is important for so many reasons.

The Power of Integration

RandyMiller — Sun, 10 Jul 2005 20:42:00 GMT

I was fortunate enough to attend TechEd Europe this summer and attend (instead of presenting) a session on MSF presented by Rafal Lukawiecki. Rafal described the changes that we have made between the old (3.0) and new versions of this framework for building processes. His session was very entertaining and won ”Best in Show”.

One of his many interesting assertions was, “Integration is a marketing term for ‘we ain’t gonna ship on time.’” It’s always interesting to hear a European use colloquial American English as part of their presentation. He was, of course, referring to the waterfall approach where components are created in isolation and brought together to create the contorted (improperly integrated), old dog. This is, as Rafal asserted, an unnatural act, as nature grows the dog from a baby puppy instead. The logical conclusion is that iterative development is the more natural way to build software.

There are many analogies that follow from this idea. However, I felt that it was time to turn this blog from overview topics like competition and project size to more detailed topics in MSF for Agile Software Development. Since integration is the topic of the day, I thought that this would be a great place to start.

Integration is not often discussed in most software development processes. This is a shame since the amount of effort involved can be trivial on many projects, and enormous on others. Some factors that increase the cost of integration include project size (large projects are costlier), embedded systems where the hardware is changing out from under them, and systems created by multiple teams or parties. But even if integration is easy on your project, it should not be taken lightly.

Here’s a question for the testers in the audience. How many times have you received what is supposed to be working functionality only to find that it doesn’t work at all? Hopefully, this is a rare occurrence but even if the answer is once, it is one too many times. I certainly don’t doubt the best intensions of the developers that gave you the system, but it may not have been anyone’s job to test that the integration produced the behavior of the scenario from end to end.

To ensure that this does not happen, we assign the scenario work item to a developer when it is scheduled for the current iteration in the iteration plan (known as the sprint backlog in Scrum). This developer is probably one of the developers with development tasks that need to be completed to implement the scenario. As soon as they can see the entire scenario working in an accepted build, they may now reassign the scenario to a tester. If an automated test case can be created to test the scenario, the automated test case is attached to the scenario. In this way, there is no confusion about whether the pieces of the scenario have been completely integrated.

Assignment to test is also a sign that the scenario (or quality of service requirement) is integrated and ready to be tested. The tester assigned the scenario lets the other testers who have test tasks for that scenario know that the new build is ready to be tested. Once all of the tests have run unblocked (and bugs created if necessary), the scenario can be closed.

One of the things that the Remaining Work report shows is whether this process is running smoothly. A widening gap in the Remaining Work report for scenarios indicates that either test is being overrun by new functionality or that too many tests are blocked. This should be an indication to the project manager that a bug allotment iteration may be needed.

Another area that the cost of integration influences is the length of the iterations. While two week iterations may be fine for small teams with minor integration costs, longer iterations may be needed for teams that incur higher integration costs. Six to eight week iterations are the norm for larger projects that may utilize teams of teams, or have larger scenarios.

All of this shows a philosophy that we have espoused all along. Understanding the dynamics of your project, including details such as integration, will help you become more efficient in building software. But these details are useless without a context-based, or configurable, software development process. MSF for Agile Software Development is such a process.