Mike Vincent's Blog

Are You Doing Scrum?

Here’s a quick self-evaluation to see if you are doing Scrum. It’s based on Scrum as described in the Scrum Guide.

The Scrum Test (1 of 3)

Do these exist?

·         Product Owner, Development Team, and Scrum Master

·         Ordered Product Backlog

·         Sprint Backlog showing remaining work

·         Sprints of 1 month or less

The Scrum Test (2 of 3)

Are these created?

·         Sprint Backlog in Sprint Planning

·         Daily Plan in the Daily Scrum

·         Usable and working Increment each Sprint

·         Usable and working Increment each Sprint

The Scrum Test (3 of 3)

Do these happen each Sprint?

·         Stakeholders inspect the Increment

·         Sprint Retrospective

A simple measurable checklist

1.    an ordered Product Backlog

2.    Development Teams of 6+-3, self-organizing

3.    have a Product Owner who owns the backlog

4.    a Scrum Master who is responsible for process

5.    have Sprints of 1 month or less

6.    Sprints are of a fixed length

7.    a Sprint Backlog that shows Remaining Work

8.    a Sprint Backlog created at Sprint Planning

9.    working software each Sprint

10. stakeholders who inspect the software increment

11. review & Retrospective at the end of each sprint

Pass the test? If no, then you know what to work on. And if yes, then congratulations. You are on the road to continuous improvement but this is just the start. There are always new opportunities.

Branching and Merging with Scrum and Visual Studio ALM

I frequently recommend the ALM Ranger’s Branching and Merging Guidance to clients as a base of understanding when evolving a strategy that best meets the client’s source control needs. When working with agile methodologies like Scrum, the right strategy can help you raise the bar on quality and efficiency while cutting potential waste.

So, what’s the big deal on a branching and merging strategy using Scrum instead of waterfall?  The short answer is simplicity and continuous integration. Overall I stress the importance of simplicity. It is one of the principles of the Agile Manifesto;  Simplicity--the art of maximizing the amount of work not done--is essential.

Let’s start with the simplest strategy: Develop on the Mainline. For a small team and simple projects this may be all that you need.  You should Label all important builds and releases; anything you might go back to.

•       Ensures that all code is continuously integrated

•       Ensures that developers pick up each others’ changes immediately

•       Avoids “merge hell” and “integration hell” at end of the project

For more complex projects you’ll want more isolation of stable released and potentially releasable code from day-to-day development activity. The Basic Branch Plan addresses that. Main contains stable code for testing and potentially releasable increments meeting the team’s definition of done. 

The Development branch provides isolation for day-to-day development work. As code is developed, unit tested and integration tested it can be merged into Main for functional and user acceptance testing. Everyone codes and checks in to Development. Enabling continuous integration or gated check-in builds ensures that everything builds and stays integrated as it is checked in. CI builds should include some test automation like all unit tests. Nightly builds should include automated integration tests. Consider also including layer validation and code analysis.

While labels on Main is a simple way to track releases, a release branch provides isolation for code actually put into production. This helps for rapid response in the event show stopping issues/bugs are discovered. It also provides an easy audit trail if you include a snapshot of everything required to rebuild the release including component code and relevant architectural artifacts.

Additional releases can be supported by labels identifying specific release drops on a continuous release branch or by additional peer release branches from Main. Your specific operational requirements should be your guide as to which option is best.

As a general guideline, always strive for simplicity. Branching is easy while merging is hard, especially if you don’t do it often. So, check in development work frequently; at least every day. When checking in, as a best practice, you should associate your check-in with one work item. Check-ins against multiple work items make things hard to track later on and suggests not focusing on one sprint backlog item at a time.

For releases, if a hotfix is required, you can quickly create a HotFix branch from Release, make the code fix, test it, and put in to production. Always follow up with a merge back to Main and from Main to Development so your whole code base is up to date. At this point, the HotFix branch is done, it has served its purpose so turn it off by locking. Here is a Basic Branch Plan, Web Option where the HotFix branch is created only if needed.

For packaged software planning for Service Packs and Hot Fixes might be more appropriate by creating the branches along with the release branch as detailed in the ALM Rangers guidance.

Don’t try to “boil the ocean” by having too many things going on at once. How does this show up in source control? Feature branches are a typical smell. Typically feature branches are an indication that product backlog items haven’t been decomposed sufficiently to produce working increments of functionality in a single sprint. Occasionally there may be times when you need the isolation of a branch within a sprint; so do it if you need to but frequently merge other development activity to keep changes small and more easily managed when you integrate back. Good decomposition of PBI’s and SBI’s minimizes the need for feature isolation. Get it in one sprint.

And, don’t create test branches. You need good test environments, either physical or virtualized where you can deploy new builds at least daily for functional and user acceptance testing but branching for test is extra work and complexity. Labels provide everything you need.

For multiple Scrum teams integrating work continuously is really important, in order to avoid “merge hell,” but requires some hard work. You should try to all work from the same Development branch. It will require extra work frequently getting latest and merging changes from other teams. This realistically works when there is some functional separation in PBI’s that each team works on and good scrum of scrums interaction. There probably will come a time when you need separate team branches. That implies even more hard work for frequent merging and scrum of scrums communication. Continuous integration is a must do. Don’t defer team integration until the end of a sprint.

Here are some architectural considerations to compliment an agile source control strategy:

• Keeping Your Application Releasable

•  Continuous Integration

  • Continuous Delivery Strategies

  • Hide new functionality until it is finished

  • Make all changes incrementally as a series

  • Use branch by abstraction for large-scale changes

  • Use components to decouple parts of application

• You benefit by having deployable code for functional testing throughout the sprint

Abstraction Layers

• Improves your architecture, avoids brittle implementations

• May require refactoring of existing code

  • then you can more easily implement constantly improving technology

• Create new implementation

  • Update abstraction layer to delegate to new implementation

  • Remove old implementation

• Do you use Interface-driven Programming?

  • Objects should depend on interfaces not concrete types

    • Don’t write your class to use AzureStoragePersonRepository

    • Write the class to code against IPersonRepository

Dependencies

• Build-time and run-time

• Components – you control the code

  • May be frequently updated

  • Need to avoid “Dependency Hell”

  • Dividing your codebase into Components

    • Not necessarily the same as N-Tier

    • Pipelining components

• Libraries – you don’t control the code

  • Usually less frequently updated

Architectural benefits

• Loosely coupled, well-encapsulated, collaborating components is good design

• More efficient collaboration and feedback when working on large systems

• Avoids the use of complex branching strategies

• Minimizes serious problems in integrating large applications

Continuous Integration

• Why is this important?

  • Your code always builds

  • Automated tests validate quality

  • You can deploy working software

• Everybody checks in to Mainline at least once a day

• If you are not merging into Mainline at least every day you are not doing continuous integration

Keeping your branching structure clean and simple sounds easy but involves work and attention to detail. Detail in right sizing PBI’s and SBI’s, and detail in frequent check-in and merging. Combined with some architectural best practices you’ll benefit with continuously integrated, high quality potentially shippable code.

10 Years of Community with INETA

INETA is turning 10 this year, on February 12 to be specific. This is a great time to reflect on how INETA and our .NET Community have grown. In addition to founding and running several user groups in Orange County, California I had the honor of serving INETA for several years, first as Membership Mentor for California, then as Treasurer and finally as Vice President.

Here’s a little history:

INETA is a worldwide support organization for user groups. INETA North America’s main objective is to provide a body of resources and support for starting and successfully running user groups focused on Microsoft’s .NET technologies.

INETA was founded February 12, 2002. The original board members were Bill Evjen, Brian Loesgen, Keith Franklin and Keith Pleas. Initially there were about 40 user groups, however within the next four years INETA grew to about 500 groups with 170,000 members. Today, INETA has more than 1,500 user groups representing more than 1,500,000 developers worldwide.

INETA has five worldwide regions (Asia-Pacific, Europe, Latin America, Middle East-Africa, and North America), each with its own board of directors. INETA was created by volunteers and continues to be run almost exclusively by volunteers. Each region is responsible for the planning and implementation of its programs and services. The regional leads also talk and meet regularly to coordinate high level issues across all regions.

The first word in INETA is International but initially INETA’s focus was on the United States and Canada. However, in our second year we expanded to Europe with the assistance of Christian Nagel, then to Asia Pacific with Mitch Denny taking the lead and Jose Berrios in Latin America. At present Joe Guadagno is President of INETA NorAm, Jose Berrios continues as President INETA LatAm, Damir Tomic is President INETA Europe, Sanjay Shetty is President INETA Asia Pacific and Daron Yöndem is President INETA Middle East and Africa. For each region, the mission is the same – a worldwide support organization for user groups. Each region focuses on the unique needs of its user groups.

INETA is committed to providing valuable resources to user group leaders around the world. The focus is on providing support for all user group related needs, while providing valuable third party resources for technical information needs. With so many .NET experts involved in INETA, members get a front row seat to the .NET revolution as it continues to unfold. The INETA community model further provides members with an opportunity to be a contributing member of this revolution.

INETA North America resources available to member user group leaders include:

• Community Speaker Program
• INETA Live
• Support for community activities such as code camps
• INETA Community and User Group Leader Offers
• INETA Newsletters
• Swag
• Support and suggestions on how to set up and successfully run a user group
• Networking
• Sponsorship (this stuff doesn’t come for free)

Typical member groups in INETA Noram come in all sizes. From groups with thousands of members and meeting with attendance in the hundreds to groups with a handful of members per meeting, INETA provides support without differentiation. Members of typical user groups come from all kinds of backgrounds including independent consultants and corporate developers, people with lots of experience with .NET and those just getting into it.

INETA programs and activities are focused on building and sustaining user group participation and membership. They include a TechEd presence, support for local user group membership growth activities, newsletters, promotion of industry events, and partnering with the Developer Evangelists from the local Microsoft office.

INETA continues to build a strong community around .NET. This can be seen in the continued growth in membership and user groups, as well as success of events that bring people together such as Code Camps. Through a continued close relationship with Microsoft user group members to have access to product teams, special discounts and offers, and early education about upcoming products. 

Visual Studio Connections Las Vegas Oct 31 - Nov 3

If you are planning to attend Visual Studio Connections and want to download my Scrum presentation material in advance, here are the links. Hope to see you in Las Vegas.

Scrum Fundamentals - Do It Right
Top 10 Dysfunctions With Scrum - Don’t Shoot the Messenger!
The Scrum Product Owner – Big Responsibilities
Herding Pigs – Managing Self-Organizing Teams

This weekend at SoCal Code Camp Los Angeles was my final warm-up for Visual Studio Connections. A big thanks for all who attended and especially to those who offered constructive feedback.  Overall the LA Code Camp was a big success.

SoCal Code Camp – Los Angeles October 15 & 16 2011

SoCal Code Camp Los Angeles is coming soon at the USC campus. As of today there are 61 sessions; I expect over 100 by the time I have to do scheduling. This year we should have more large audience rooms available.

I’m doing four sessions with a big focus on Scrum as a final warm-up for my Scrum/Agile track at DevConnections:

Scrum Fundamentals - Do It Right
Top 10 Dysfunctions With Scrum - Don’t Shoot the Messenger!
The Scrum Product Owner – Big Responsibilities
Herding Pigs – Managing Self-Organizing Teams

Please RSVP if you plan to attend. It really helps us with the event planning. Hope to see you there.

Microsoft ALM Summit is coming November 14 - 18

Microsoft ALM Summit

The ALM Summit is again coming up soon and again will be held on the Microsoft campus in Redmond. Keith Pleas and his company, Guided Design, do a great job of organizing and running this event. This year there will be two tracks: ALM Leadership and Agile Developer. The main conference is November 15 – 17 with Pre-Conference sessions on Monday November 14 and Post Conference sessions on Friday November 18.

I’ll be working with Richard Hundhausen on Accentient’s Pre Conference all-day workshop Implementing Scrum. The workshop is all about managing the implementation of Scrum. Whether you are new to Scrum and want to learn how to get started, are doing Scrum but need to sharpen your focus and deal with some ScrumButs, or just need to integrate Scrum with your ALM tools then this workshop is for you. We’ll be taking a pragmatic Scrum practitioner’s perspective. You’ll have plenty of time for questions and discussion with your hosts and peers.

Here’s what the ALM Summit schedule looks like:

Day 1 (November 14th) - Pre-conference Workshops

Day 2 (November 15th) - Best Practices

Day 3 (November 16th) - People and Culture

Day 4 (November 17th) - Technologies and their Impact

Day 5 (November 18th) - Post-conference Workshops

Hope you can make it to the ALM Summit and please consider our Implementing Scrum PreCon session.

SoCal Code Camp – San Diego June 25 & 26 2011

SoCal Code Camp San Diego is coming soon at UCSD. As of today there are 110 sessions, with more to come. I’m doing four sessions with a big focus on Scrum:

Scrum Fundamentals - Do It Right
Herding Pigs – Managing Self-Organizing Teams
Top 10 Dysfunctions With Scrum - Don’t Shoot the Messenger!
The Scrum Product Owner – Big Responsibilities

Please RSVP if you plan to attend. It really helps us with the event planning. Hope to see you there.

Using MSDeploy to Automate Web Deployment for Test and Production with Visual Studio ALM 2010 Team Build

Leverage MSDeploy.exe to Automatically Deploy Builds Where We Need Them

In an earlier posting Building a Custom Build Workflow with Deployment I showed how you can extend Team Build workflow to do a simple deployment to a user acceptance test (UAT) location. Here I'll discuss improving that example with the powerful capabilities of MSDeploy.exe. You can download the PowerPoint slide deck and Word document from my code camp and user group presentation for an overview and details of the MSDeploy.exe command line reference.

MSDeploy.exe is the engine behind Microsoft's Web Deployment tool. It assists in deployment, migration  and synchronization of web applications and sites from one location to another. The locations can be local or remote, requiring a remote agent service. IIS must already be installed on the source and destination computers. MSDeploy has numerous features that let you, with a great degree of precision, include those components that you want to process and exclude those that you do not.

• Synchronize
  • Coordinates source and destination
  • Locally or remotely
  • High degree of precision including dependencies
• Package
  • package and archiveDir let you snapshot into .zip of archive directory
  • Parameterization and manifest let you customize
• Deploy
  • Implement or test with whatif
  • Computer to computer directly or use packages
  • Features for troubleshooting

MSDeploy.exe Command Line

The Msdeploy.exe command-line executable file that implements Web Deploy functionality contains many powerful features. A Web Deploy verb specifies the action to be taken, such as synchronization (sync. The -source and -dest arguments define the source and destination of the data to be deployed. Typically, a source or destination is a Web site or Web server. A variety of predefined source and destination object types are available in the form of providers. Providers let you access and synchronize Web sites and Web servers, metabase and ApplicationHost.config configuration information, archived Web sites and Web servers, file and directory paths, and other IIS-related data. For more information about providers, see Web Deploy Providers.

Principal elements are a verb (also called an operation), a source, an optional destination, and optional operation settings

msdeploy.exe -verb:<verbName>
    -source:<provider>[=<pathToProviderObject>
            [,<providerSetting>=<providerSettingValue>]]   
        [-dest:<provider>[=<pathToProviderObject>
            [,<providerSetting>=<providerSettingValue>]]]
        [-<MSDeployOperationSetting> ...]

Verbs are delete, dump, getDependencies, getSystemInfo, and sync

Web Deploy has additional arguments that let you refine the meaning of providers and their sources and destinations. Operation settings modify how the command runs. Rules modify the behavior of operations. Link extensions let you pull together data in ways that would not otherwise be possible. These features combine to enable you to implement custom Web deployment scenarios with maximum power and flexibility.

Using MSDeploy.exe in Team Build

If your destination is remote, you’ll need the Web Deploy remote service installed and running on the remote machine. Best practice is to check for dependencies before a sync operation with getDependencies and resolve conflicts and unsupported components. Backup the destination as appropriate, then create your command and test it. Note: use whatif first and check the output.

msdeploy -verb:sync -source: ,computerName= -dest: -whatif >msDeploySync.log

After you have verified it is doing what you want, you can run without the whatif. When it tests successfully you’re ready to move to implementing your deployment in Team Build workflow.

You can refer to my pervious post for creating a custom build and navigating the build workflow. In the "Try Compile, Test, and Associate Changesets and Work Items" activity, I expand the Finally block and added a new activity at the end called "If DropBuild Successful". Here I'm expanding the activity:

Note the condition. When it resolves to true, the Then block will execute. I've added an activity of type Sequence called "DeployUAT" that contains our actual deployment functionality. Since we only want to deploy to our UAT manually, I have added an Invoke for Reason activity and named it "InvokeOnlyForManual". You should see the dropdown for Reason set to 'Manual" in the properties.

I have scoped new variables and arguments to the "DeployUAT" activity. These allow us to define where our UAT site is located and what it's name is. Click on the Variables and Arguments tabs at the bottom of the designer.

While on the Arguments tab, open Metadata. Here I have defined a new category that will show up in the build process dialog. I have named this category "Deployment" and it displays our 2 new parameters with their default values.

Now to move on to the actual  work of deployment. In my previous post example we had to do several individual steps in order to perform a clean deployment. With the power of msdeploy, we can do it all with one activity that I have named InvokeSyncWebsite. 

Save your XAML file and check it in to source control. You now have your custom template ready for use. Below you can see our Deployment category that we added to the template process. The default values can be over-ridden when the process is manually called.

This example should get you started using msdeploy for deployment to your builds. There are many more considerations you may have to make for your particular implementations including, security, domain and firewall boundaries. We have just scratched the surface of msdeploy's capabilities.

Download Custom Process Template MSDeploy_

INETA Component Code Challenge

Win a full scholarship trip to Microsoft's TechEd 2011 in Atlanta.

INETA is hosting the Component Code Challenge, a contest with our component partners to showcase great .NET applications making effective use of reusable components to solve a problem.

The Rules:

Any .NET Application (WinForms, ASP.NET, WPF, Silverlight, Windows Phone 7, etc.) built in the last year (since 1/1/2010) using at least 1 component from at least 1 approved vendor. Then make a 3 - 5 minute Camtasia video showing your entry and describing what component(s) you used and why your application is cool. Our judges will review the submissions and the best two will win a scholarship to Tech·Ed 2011, May 16-19 in Atlanta GA including air fare, hotel, and conference pass.

The Judging:

Entries will be judged on four criteria:

1. Effective use of a component to solve a problem/display data
2. Innovative use of components
3. Impact using components (i.e. reduction in lines of code written, increased productivity, etc.)
4. Most creative use of a component.

Timeline:

Hurry! The submission deadline is March 15, 2011 at Midnight Eastern Standard Time.

More information, can be found on the INETA Component Code Challenge page.

SoCal Code Camp – Cal State Fullerton January 29 & 30 2011

SoCal Code Camp Fullerton VI is coming soon. As of today there are 87 sessions, we’ll be well over 100 when it’s time for me to put the schedule together. I’m doing three sessions   this time:

·         Automating Web Deployment for Test and Production with Visual Studio ALM 2010 Team Build.

·         Herding Pigs – Managing Self-Organizing Teams

·         A Lap Around Microsoft Test Manager

Please RSVP if you plan to attend. It really helps us with the event planning. Hope to see you there.

Microsoft ALM Summit November 16-18

I’m finally getting around to sharing my thoughts on the Microsoft ALM Summit last month on the Microsoft campus in Redmond. Keith Pleas and his company, Guided Design, did a great job of organizing and running this event. In my opinion this was a “right size” event with a single track across the three days meaning you had the opportunity to attend everything and the venue was great.  I also really enjoyed the opportunity to get together with friends and make new acquaintances including conference attendees, presenters, ALM MVP’s, Professional Scrum Developer Trainers, and the Microsoft ALM product team.  In addition to each day’s presentations, the evening networking events were great.

Day 1 (November 16th) - Agile Acceleration

Day 2 (November 17th) - Collaborative Development

Day 3 (November 18th) - Engaging the Whole Team

The next ALM Summit will take place the week of November 14-18, 2011 in Redmond.

LA Code Camp, Oct 23 & 24, 2010

SoCal Rock & Roll Code Camp Los Angeles is coming October 23 and 24, 2010 at the University of Southern California campus. We have two action packed days of sessions, Saturday Geek Dinner, Sunday Geek Lunch, and raffle prizes plus a great opportunity to network. RSVP at SoCalCodeCamp.com and while you are at it, why not consider presenting a session.

Building a Custom Build Workflow with Deployment

Exploring Team Build based on Workflow 4.0 in Visual Studio 2010 ALM

With Visual Studio 2010 Application Lifecycle Management, Team Build is based on Workflow 4.0. Workflow provides an improved build experience and allows you to customize the workflow to suit your specific automation needs. Out of the "box" the default build workflow does not include deployment. Here I will show you how to add a simple deployment to a user acceptance test (UAT) location.

To begin, in the Team Explorer for your subject team project right click on Builds and select New Build Definition. Give the new build definition a name and supply the necessary information for the other tab pages. For Process, we are deriving our new process template from the default template. I'll give you a link to my custom process template at the end of this post and you can optionally specify that if you choose to.

Your new process template will be saved on the TFS server. I'm using the default storage location. Double-click on the file name to check it out from source control and open it. The file will open in the Workflow XAML designer. Be patient as it takes a while for everything to load.

The workflow will open in compressed or collapsed mode. I have opened the "Run on Agent" activity here. We will focus on the "Try Compile, Test, and Associate Changesets and Work Items" activity since that is where we want to add our deployment. If you are new to workflow based builds, spend some time exploring the tools and the template process workflow in order to understand what happens when and under what conditions.

In the "Try Compile, Test, and Associate Changesets and Work Items" activity, expand the Finally block. I have added a new activity at the end called "If DropBuild Successful". Expand the activity.

Note the condition. When it resolves to true, the Then block will execute. I've added an activity of type Sequence called "DeployUAT" that contains our actual deployment functionality. Since we only want to deploy to our UAT manually, I have added an Invoke for Reason activity and named it "InvokeOnlyForManual". You should see the dropdown for Reason set to 'Manual" in the properties.

I have scoped new variables and arguments to the "DeployUAT" activity. These allow us to define where our UAT site is located and what it's name is. Click on the Variables and Arguments tabs at the bottom of the designer.

While on the Arguments tab, open Metadata. Here I have defined a new category that will show up in the build process dialog. I have named this category "Deployment" and it displays our 2 new parameters with their default values.

Now to move on to the actual  work of deployment. First we need to stop the UAT web site. I do this in an InvokeProcess activity I have named "InvokeStopWebsite" that calls appcmd.exe and passes the argument "String.Format("stop site {0}", UATWebsiteName)" to stop the site as a VB expression.

Next, I need to delete existing content from the UAT site. I do this with an InvokeProcess activity that I named "InvokeDeleteWebsiteFiles" where I call cmd.exe and pass the argument "/c del *.* /s /q" to delete all files. Be careful when testing destructive operations during development to be sure you are executing against the intended target.

I then copy our newly built content to the UAT site with another InvokeProcess activity I named "InvokeCopyWebsiteFilesFrom".  Again I call cmd.exe and pass the argument "/c xcopy ""{0}/_PublishedWebsites/Tailspin.web"" {1} /s /e, BuildDetail.DropLocation, UATDirectory)" to xcopy the files from the drop location to our UAT site.

Finally, I restart the UAT web site with the InvokeProcess activity named "InvokeStartWebsite". I call appcmd.exe and pass the argument "String.Format("start site {0}", UATWebsiteName)" to start the site.

That concludes our simple deployment customization. Save your XAML file and check it in to source control. You now have your custom template ready for use. Below you can see our Deployment category that we added to the template process. The default values can be over-ridden when the process is manually called.

This custom example should get you started on adding deployment to your builds. There are many more considerations you may have to make for your particular implementations. Considerations include, security and crossing firewall boundaries. You may need a much higher degree of sophistication and may need to consider coding custom activities. Here's a summary in increasing order of complexity.

Download Custom Process Template 1

Urban Turtle - Check it out

Accentient, who I work with to provide ALM training and consulting, is pleased to announce that they are officially a friend of the Urban Turtle.

Accentient is both an Urban Turtle “Select Partner”, which is a highly recognized and trusted organization that can provide you with various services to make you successful with Scrum TFS and Urban Turtle as well as a Professional Scrum Developer (PSD) Select Partner who has demonstrated unique value in delivering the PSD course.

Urban Turtle is an intuitive Scrum tool for TFS built to simplify your software development cycles. It was built by experienced Scrum coaches and practitioners, Urban Turtle helps you deliver kick-ass software sustainably, every iteration. It provides you a fast, intuitive tool to plan. manage and track your Scrum work.

Check out the YouTube video, get the 30 day trial (you'll want the full version before your trial is up) and start sprinting.

SoCal Rock & Roll Code Camp San Diego

Coming up Saturday and Sunday June 26 and 27 is the SoCal Code Camp at UCSD in San Diego. Look forward to two full action packed days and don’t forget the geek dinner on Saturday evening. I’ll be doing three sessions:

1.    Scrum Fundamentals

Scrum is an increasingly popular agile framework for managing software development. Can Scrum help you deliver successful projects? You first have to understand the fundamentals of Scrum. This session will pragmatically explore using Scrum. We'll talk about what how to get started adopting Scrum, what kinds of organizational commitments are needed and how Scrum works with Team System.

Scrum is incredibly simple on the surface but touches profoundly on people, process and technology. What should you expect if you do it right, and what if you don't? Join our discussion and see if Scrum may be right for you. It all starts with understanding the Scrum Fundamentals.

2.    Exploring Team Build based on Workflow 4.0 in Visual Studio 2010 ALM

With Visual Studio 2010 Application Lifecycle Management, Team Build is based on Workflow 4.0. In this session we’ll explore what Workflow adds to make a better build experience and show you how you can customize the workflow to suit your specific automation needs.

3.    Herding Pigs – Managing Self-Organizing Teams

In the Agile world of Scrum, the people who build software, the development teams, are referred to as pigs because they are committed while the others are referred to as chickens because they are only involved. One of the guidelines of Scrum is that teams should be self-organizing. So, how do you manage self-organizing teams? That’s what this session is all about. We want our teams to be highly productive, to grow professionally, to enjoy their work and be in it for the long haul. All while being good organizational citizens and driving on the proper side of the road. We’ll cover a little management theory on motivation and maintaining a positive, healthy work environment and show you how to put it to work. Get ready to re-factor how you herd pigs.