Permissions and security (Must know)

In this chapter we'll examine the various permissions, services accounts needed, and various roles involved in this integration. We'll also cover the steps you'll need to perform to set each of these. Please keep in mind that depending on your unique environment, and re-use of existing accounts and groups, some of these permissions may have already been granted.

Getting ready

To begin with, we need to make sure we are set up for success. Let's look at this from a server by server view:

• Team Foundation Server: In order to perform any of the operations in this chapter you will need to belong to the Team Foundation Administrators group (alternately you could also assign the view instance-level information and edit instance-level information to Allow). You'll also need to have access to the Team Foundation Server Administration Console page (alternately, you could also use the Group Membership dialog box in Team Explorer, but the Team Foundation Administration Console page is much easier to work with for this).

Team Foundation Sever Administration Console

• Project Server: In Project Server, you'll need the Manage users and groups global permission for an instance of Project Web Access or PWA. To set these, you'll need access to the Project Server through PWA.

Project Web App

• SQL Server: To grant Project Server 2010 permissions for the reporting database, you need to be a member of the administrators' security group for the SQL Server databases for Project Server.
• SharePoint: In SharePoint, you must belong to the Farm Administrators group, the administrators group for the web application that supports Project Server, or the SharePoint Administration group. The exact group membership you will use will depend on the specifics of your deployment.

Required permissions matrix for integration with Project Server 2010. Detailed instructions on how to set these are below this reference table:

How to do it...

We'll lay the steps out here by subject to make it easy to follow and refer back to later.

• Granting Team Foundation Administrative Permissions:

  In order to configure the integration of Team Foundation Server and Project Server, you must have permissions to administer Team Foundation Server or at least a team project collection. For both configuration and synchronization, you must also grant permission to administer Project Server integration to the user who will configure the integration of the two server products. Following are the steps to show how to grant this permission:

1. Launch the Team Foundation Server Administration Console page.

Team Foundation Server Administration Console, Administer Security

Expand the server node (Application Tier), click on Team Project Collections, click on a collection, and then click on the Administer Security option.

1. In the Global Security window, click on [Collection]\Project Collection Service Accounts.
2. Under Permissions for the Administer Project Server integration, select the Allow checkbox.
3. Click on the Close option to close the Global Security window.

• Granting Project Server Permissions:

  You minimally need to grant Project Server permissions as follows:

1. Add the account of the user who will register an instance of PWA to Team Foundation Server to the administrators group
2. Either add the service account for Team Foundation Server to the administrators group, or grant that account the minimum set of Global and Category permissions as described in the previous reference table.
3. Add the accounts of any Team Foundation members who will submit status updates to Project Server to the Team Members group

• Adding an account to Project Server and assigning it to the administrators group for Project Server 2010:

1. From the PWA home page, in the Quick Launch area (from the side menu, on the left-hand side, scroll all the way down), select Server Settings.
2. From the Server Settings page, select Manage Users.
3. From the Manage Users page, select New User. This will begin the creation of a new user account. You will return here as needed by add additional administrators.
4. On the New User page, enter at least the required fields. Some things to keep in mind as you are doing this are:

1. Uncheck the checkbox for User can be assigned as a resource if the account is a service account. This would be left as default for normal users, but not for an administrator.
2. In the User Authentication field, enter the account name of the user or service account you want to use.
3. Uncheck the checkbox for Resource can be leveled if the account is an administrator or a service account. This would be left as default for normal users, but not for an administrator as noted previously.
4. Lastly, you'll need to add the account to the Administrators group, from Security Groups, select Administrators in the list and then click on Add.
   1. Click on Save.

Project Web App, New User

• Granting the minimum Global permissions to the service account for Team Foundation Server:

1. From the PWA page, in the Quick Launch area, click on the Server Settings option.
2. From the Server Settings page, click on Manage Users.
3. From the Manage Users page, click on New User.
4. From the New User page, type the required information in each field. Note the following:

Clear the checkbox for User can be assigned as a resource because the account is a service account.

For user authentication, type the account name of the service account.

To assign Global Permissions, select the Allow checkbox for each permission that you want to set, and as specified earlier in this topic.

1. Click on Save.

• Granting Category permissions to the service account:

1. From the home page for PWA, in the Quick Launch area, click on the Server Settings option.
2. From the Server Settings page, click on the Manage Categories option.
3. From the Manage Categories page, click on the New Category option.
4. From the Add or Edit Category page, type a name for the service account category. For example, type Servicing Account.
5. Under the Available Users list, click on the name of the service account for Team Foundation Server, and then click on Add.
6. Under the Projects list, click on the All current and future projects in Project Server database option.
7. Click on Save.

• Adding Team Foundation members to the Team Members group:

1. From the home page for PWA, in the Quick Launch area, click on Server Settings option.
2. From the Server Settings page, in the Security section, click on the Manage Groups options.
3. From the Manage Groups page, click on the Team Members option.
4. From the Add or Edit Group page, hold down the Shift key, click on the users whom you want to add from the Available Users list, and then click on Add.
5. Under Categories, verify or add My Tasks from Available Categories to Selected Categories.

• Adding the Service Account for Team Foundation Server to the Project Server Service Application for Project Server 2010:

  In order to enable status update processing by the synchronization engine for integration with Project Server 2010, you must add the service account for Team Foundation Server to the Project Server Service Application. This can be done alternatively you could use Windows PowerShell (not covered here).

  Following are the steps to add the Service Account using SharePoint Central Administration:

1. Launch the SharePoint Central Administration page for Project Server.
2. Under Application Management, choose the Manage service applications option.
3. From the Manage Service Applications page, highlight the Project Server Service Application row by clicking within the row but not the name of the application.

The ribbon will now be available.

1. In the ribbon, select the Permissions option.
2. In the Connection Permissions for Project Server Service Application dialog box, type the name of the service account, and then select Add.
3. In the middle pane, make sure that the name of the newly added service account is highlighted.
4. In the bottom pane, select the Full Control checkbox, and then select OK.

Manage Service Applications dialog box, for step 3

• Granting Permissions to PWA databases to the service account for the web application pool for Project Server 2010:

  To enable data synchronization, you need to grant permissions to the service account for the web application pool to update two SQL Server databases for each instance of PWA for Project Server 2010.

  Following are the steps to grant permissions to a database for an instance of PWA:

1. Log on to the data-tier server for Project Server.
2. Select, SQL Server Management Studio in Start | All Programs| Microsoft SQL Server 2008.
3. The Connect to Server dialog box will now open.
4. In the Server type list, select Database Engine.
5. In the Server name field, type the name of the server that hosts the databases for Project Server, and then select Connect. (If SQL Server is installed on a cluster, type the name of the cluster, not the computer name. If you have specified a named instance, type the server and instance name in the following format: DatabaseServer\InstanceName. If you have Project Server and SQL Server installed on the same machine, the localhost name that this dialog box defaults to, will work fine.)
6. The SQL Server Management Studio page opens.
7. Expand the Databases option, open the shortcut menu for the database for the instance of PWA (for example, PWA_Reporting), and then select Properties.
8. Under Select a page, select Permissions.
9. Add the service account of the web application pool for Project Server, and grant the required permissions. For example, Alter any Schema, Create Table, Delete, Execute, Insert, Select, and Update are the permissions required for the reporting database.
10. On the Publishing database (PWA_Published), grant the Select permission.
11. Repeat steps 7 through 10 for each instance of PWA that will participate in data synchronization with Team Foundation Server.

Database Properties, Permissions dialog box, for step 8

There's more...

Although we've covered most of the key parts already, there are a few other things you might want to consider. We'll cover those in the following section.

Logon permission for services

You must grant all service accounts for Project Server and SharePoint products, permission to log on to the computer on which the service is running.

Service account permissions

The service account for Team Foundation Server also runs the Team Foundation Background Job Agent Service. All TfsAdmin commands are run in this service accounts context, except for the /RegisterPWA and /UnregisterPWA options, which are run under the executing user. The Team Foundation Background Job Agent Service manages data synchronization processes. This service account requires permissions to access each instance of PWA that has been mapped and permissions to call Project Server integration services.

 

About this Except:

Portions of this excerpt were re-published by the author (me).  The full book is available for purchase here http://www.amazon.com/dp/1849688540/?tag=packtpubli-20.  Note that some content may be different (pictures, charts, etc.) as I'm trying to format this post for the web.

Configuration of initial permissions (Must know)

We'll cover the initial permission configuration required and the steps to get you through configuring these for Team Foundation Server Extensions for Project Server in this recipe. These are not all the permissions in setting the complete system up, but just the ones required to begin configuration. It is possible that in a large enterprise installation, you will need to separate the requests to get them set by several individuals. This should help with facilitating that.

Getting ready

In the previous recipe we installed the integration. Now we'll build off of that as we configure the integration. Please take a moment to review the work we've done previously before we begin.

Also, it might be handy at this point to review the summary for steps we will be following in this recipe and in other recipes:

Entire configuration workflow

 

To initially configure the permissions required, you will need to assign administrative permissions of Team Foundation Server and an instance of Project Web App (PWA) to a user who will be responsible for the configuration of these products. You will use the Team Foundation Server Administration Console page for most of the Team Foundation Server permissions, and the Project Security dialog box or Manage Users / Manage Groups web pages for PWA. Please note these are the minimum configurations you'll need to perform for permissions, your installation may need more depending on your specific site requirements.

How to do it...

We'll lay the steps out in the following section by subject to make it easy to follow and refer back to later.

Firstly, we will be setting initial permissions.

You should perform the following modifications in given order:

1. Adding user to Team Foundation Administrators group:

   Account(s): This is the account(s) that will be used to configure the integration of the Team Foundation Server. If this is the same user who installed Team Foundation Server, then this task would already be done during that product's installation and configuration.

   1. Open the Team Foundation Server Administration Console page from the Start menu of the Team Foundation Server.
   2. Navigate to the Group Membership dialog (Team Foundation Server Administration Console | Application Tier | Group Membership) to add this account to the Team Foundation Administrators group.

   This user will be using the command-line tool TFSAdmin, this will be installed by Visual Studio 2012 during its installation.

2. Setting the Administer Project Server integration permission to Allow the account:

   Account(s): These are the accounts of the project managers or other users who will manage the mapping of enterprise projects.

   1. Open the Team Foundation Server Administration Console page from the Start menu of the Team Foundation Server.
   2. Navigate to Team Foundation Server Administration Console | Team Project Collections | Administer Security dialog box to add the account to set the Administer Project Server permission to allow the user or group.

   This is a project collection level permission.

3. Granting the Manage Security global permission to each instance of PWA that you will register with Team Foundation Server:

   Account(s): This is the account(s) of user who will configure the integration of Team Foundation Server and Project Server or the one who registers the instances of PWA with Team Foundation Server service account for Team Foundation Server.

   1. Open the PWA Site in Internet Explorer at http://tfspsdemo/PWA/default.aspx.
   2. Navigate to Project Web App | Edit User | Selected User | Global Permissions Section | Manage Security.

   Every service account for Project Server and SharePoint Products must be granted interactive logon permissions for the computer on which the service is running. This is not a usual permission for services so it bears special mentioning. You will need to repeat this on every PWA instance.

4. Granting Full Control permissions to invoke the Project Server Service Application:

   Account(s): This is the service account for Team Foundation Server.

   We will use SharePoint Central Administration using the following steps:

   1. Run the SharePoint Central Administration page from the Start menu.
   2. In the Application Management section, click on the Manage Service Applications option (many service applications will be listed here normally).
   3. From the Manage Service Applications page, select the row for Project Server Service Application by clicking within the row but not right on the name of the application, that is, don't double click on it. If you do, no big deal, you just need to go back to the previous step and try it again.

   The ribbon should then become available.

   1. In the ribbon you should see a Permissions icon, click on the Permissions icon now.
   2. Within the Connection Permissions for Project Server Service Application dialog box, enter the name of the service account you will be using for this service, and then click on Add. You can go back and change this later if you need to.
   3. In the middle pane, ensure that the name of the service account that you just added is still highlighted, if not please highlight it now.
   4. From the bottom pane, select the Full Control checkbox then click on OK.

SharePoint central administration, Service Application permissions

1. Granting SQL Server database permissions:

   Account(s): This is the service account for the web application pool for Project Server 2010 (you can find this by opening Application Pools in IIS Manager | Connections).

   Since the following commands can take some time, there is also a handy PowerShell script you can use which is at the end of the Summary section.

   We will grant permissions to PWA databases to the service account for the web application pool for Project Server 2010

   To enable data synchronization, you need to grant permissions to the service account for the web application pool to update two SQL Server databases for each instance of PWA for Project Server 2010.

   To grant permissions to a database for an instance of PWA:

   1. Log on to the data-tier server for Project Server.
   2. Select SQL Server Management Studio from Start | All Programs | Microsoft SQL Server 2008.
   3. The Connect to Server dialog box will now open.
   4. In the Server type list, select Database Engine.
   5. In Server name, type the name of the server that hosts the databases for Project Server, and then select Connect. (If SQL Server is installed on a cluster, type the name of the cluster, not the computer's name. If you have specified a named instance, type the server and instance name in the following format: DatabaseServer\InstanceName. If you have Project Server and SQL Server installed on the same machine, the localhost name that this dialog box defaults to will work fine.)

   SQL Server Management Studio opens.

   1. Expand the Databases option, open the shortcut menu for the database for the instance of PWA (for example, PWA_Reporting), and then select Properties.
   2. Under the Select a page list, select Permissions.
   3. Add the service account of the web application pool for Project Server, and grant the required permissions. For example, the following permissions for the reporting database are required: Alter any Schema, Create Table, Delete, Execute, Insert, Select, and Update.
   4. On the publishing database (PWA_Published), grant the Select permission.
   5. Repeat steps 7 through 9 for each instance of PWA that will participate in data synchronization with Team Foundation Server.

Database Properties, Permissions dialog box

 

1. Adding account(s) to the Team Members group of PWA:

   Account(s): These are the Team Foundation Server team members who will submit status updates to Project Server from a client of Team Foundation.

   1. Open the PWA site.
   2. In the PWA SharePoint site, add team members to the Team Members group for the PWA, or you must grant them the following minimum set of project permissions, namely, Open Project and View Project Site.
2. Granting permissions to contribute to the team project in Team Foundation Server:

   Account(s): These are the users of Project Professional who will publish plans to Team Foundation.

   1. Open the Team Foundation Server Administration Console from the Start Menu.
   2. In Team Foundation Server Administration Console, Grant View Project-level information permissions in Team Foundation, or assign them as members of the Reader group for the team project.

There's more...

Although we've covered most of the key parts already, there are a few other things you might want to consider. We'll cover those in the following section.

If some of the steps given here are not detailed enough for you, not to worry. We cover many of the same ones in the recipe, Permissions and Security.

 

About this Except:

 

Portions of this excerpt were re-published by the author (me).  The full book is available for purchase here http://www.amazon.com/dp/1849688540/?tag=packtpubli-20.  Note that some content may be different (pictures, charts, etc.) as I'm trying to format this post for the web.

Installing integration (Must know)

We'll be installing the Team Foundation Server Extensions for Project Server in this section.

Getting ready

In the previous recipe we prepared the information we needed to ensure a successful integration. Now we'll build off of that as we install and configure the integration. Please take a moment to review the checklist before we begin. Our first decision point is whether or not this will be a test or production instance. While installation process is the same in either case, the configuration has some variations to consider.

Installation overview

How to do it...

The steps to install Team Foundation Server Extensions for Project Server are fairly simple. The server steps are as follows:

1. Insert the Team Foundation Server 2012 DVD / ISO in the drive, navigate to the Project Server Extensions folder, and launch the tfs_projectServerExtensions.exe to begin.

1. In the license terms' dialog box, accept the license terms, and then select continue.
2. When the next screen appears select Install Now.
3. On the last screen, select Close. You are now done with the installation.

An indication that you didn't remove the old Team Foundation Server 2010 Integration prior to attempting to upgrade to the 2012 edition will appear on the screen. You'll need to remove it with the Programs and Features dialog box in control panel to continue as shown in the following screenshot:

A successful installation will be indicated with the following dialog box:

Success!

Installing the client side is just as simple, the following are the steps:

1. Remove Visual Studio 2010 from the client machine.
2. Locate the Visual Studio 2012 installation media and install Visual Studio 2012 on the client machine, following the instructions as prompted.

As discussed in the previous recipe, there are a number of prerequisites and client software that need to be installed. On each machine that will be used by a project manager to synchronize data between enterprise project plans and team projects, you will need to install both Visual Studio 2012 and Microsoft Visual Studio Team Explorer. In reality, the only reason you need Visual Studio is the add-in list. However, as far as this book is concerned, the only way to get the Visual Studio 2012 add-in list is to install a copy of Visual Studio 2012.

There's more...

Although we have covered most of the key parts already, there are a few other things you might want to consider. We'll cover those in the following sections.

Extension versions must match

A common scenario now is upgrading the Team Foundation Server versions to Team Foundation Server 2012. If this is your situation, you should uninstall the extensions from Project Server and then install the latest version of the Team Foundation Server Extensions for Project Server on all the servers where it was previously installed. The general order of operations in this case would be:

1. Uninstall Team Foundation Server 2010 and any extensions. Don't worry, all the configuration data is stored in TFS's database which the Upgrade process will detect.
2. Install/upgrade to Team Foundation Sever 2012 as per the installation guide.
3. Install/upgrade the Team Foundation Server Extensions as described in the previous recipe.

64-bit machines now required

Visual Studio Team Foundation Server 2012 now requires a 64-bit machine, as do the Team Foundation Server Extensions for Project Server.

No remapping needed

Some good news for upgraders, you will not need to unregister any previously mapped components prior to upgrading.

No additional Client Access License (CAL) needed

More good news, although you need to install Visual Studio 2012 to get the add-in list for Microsoft Project Professional, Microsoft tells us that we will not need a CAL to interface with the integration itself.

Note for upgraders from TFS2010

It has been reported that the installation procedure for Team Foundation Server 2012 may switch the service account from a specified domain account to network service. If this occurs, you will need to switch it back to the account you noted in earlier sections while preparing for the installation. Alternatively you can reset the project server permissions based on this new account. This can be done using the TFS administration console.

 

 

About this Except:

 

Portions of this excerpt were re-published by the author (me).  The full book is available for purchase here http://www.amazon.com/dp/1849688540/?tag=packtpubli-20.  Note that some content may be different (pictures, charts, etc.) as I'm trying to format this post for the web.

 

Planning for a successful integration (Must know)

We will examine what's needed to ensure that your integration is successful. We'll cover the prerequisites and the planning needed to begin, scenarios for test or production environments, and different types of synchronization that are possible.

Getting ready

Using Team Foundation Server Extensions for Project Server, project managers can make Project Server to access real time project status and resource availability of teams who work in Team Foundation Server. Following the successful configuration of the two server products, the synchronization engine maintains scheduling data and resource usage in the mapped Project Server enterprise project plan and Team Foundation Server team project.

How to do it...

There are a few pieces of information we need to collect and a few configuration tasks we'll need to make sure have been completed properly.

Here is an installation and configuration requirement checklist to make sure that we are ready to begin:

 

Now that the common pre-configuration items are out of the way, we can move on with the planning.

How it works...

At the core of this integration are the work items in Team Foundation Server which synchronize with the Tasks in Microsoft Project plans in Project Server. Using this integration, project managers and software development teams can use whichever tools that work best for them, and share information transparently.

The integration and all products involved in it are scalable from installations of a few users to several thousands. You can easily scale this integration out by using multiple Project Web Access servers mapped to a multi server, that is, TFS deployment. We'll cover the specifics of the integration in a later section, but this is a good spot for an overview diagram.  

There's more...

We have a few final points to keep in mind, and some valuable tips to make your installations go smoothly. This will not be a complicated integration if we follow the given advice.

A time saver for your test installations

We all know it can take a serious amount of time to build your own testing and demonstration virtual machines. This is especially tough when you are just going to use it for a test installation or a pitch to technical management. Although the following VM link provided by Microsoft is one revision older than the one discussed here, it is much quicker to upgrade this one than to do a fresh installation. For more information, see the following page on the Microsoft website:

http://go.microsoft.com/fwlink/?LinkID=196413

You weren't planning a test environment? Now would also be a good time to plan a test system in your deployment schedule. It will not only help you to have an environment to test out configuration changes but will also be a good safety measure to ensure all your mapping is correct before you deploy to a production environment.

Active Directory – Highly recommended for production installations

Active Directory is technically not required, however it is highly recommended that you deploy Active Directory in your network. It will help with synchronization of the user accounts, groups, and services within Team Foundation Server and Project Server. Otherwise you'll be doing this manually between the two environments. If you haven't deployed Active Directory yet, but are planning to deploy it, now would be a good time to begin that.

SharePoint Authentication Mode

We mentioned this in the previous checklist, but it bears repeating here. The authentication that is assigned to the SharePoint web application for the instance of PWA must be set to Classic Mode Authentication. You will not be able to register the instance of PWA if the authentication is set to Claims Based Authentication.

Backup

A server based product cannot be mentioned completely without a discussion of backup. Do not begin any production installation or upgrade of any product mentioned here without involving a prior backup of all systems. Special attention should be paid to the backup of the Team Foundation Server system. If done improperly, the backup will put your TFS installation into an unusable state after a restore operation, and the worse part will be you won't know this until you start using it again. Please review Microsoft's current recommendation about using marked transactions in your backup strategy Understanding Backing Up Team Foundation Server
document is available at:

http://msdn.microsoft.com/en-us/library/ms253151.aspx

 

 

About this Except:

Portions of this excerpt were re-published by the author(me).  The full book is available for purchase here http://www.amazon.com/dp/1849688540/?tag=packtpubli-20.  Note that some content may be different (pictures, charts, etc) as I'm trying to format this post for the web.

Just got back from the 2012 Microsoft MVP Global Summit in WA.  While the Windows 8 Consumer Preview got most of the media attention, as an MVP in ALM my attention was on what Microsoft was doing with Team Foundation Server 11 and Visual Studio 11.  Some of what we learned on future direction was covered under strict NDA, but we are allowed “released” info, which in this case is the VS 11 / TFS 11 beta.  So as always, your mileage may vary a little since I’m basing this off the beta.

Overview

There is a lot to be excited about for all the roles in an organization in the new releases.  Developers and Testers will be especially pleased, but I wanted to cover some the new items that Project Managers and Product Owners will be particularly excited about.  Though certainly a developer centric toolset, Microsoft is starting to realize that getting world class software products out the door requires more than just well equipped developers, and they want Visual Studio to be at the core of it.

First the Upgrade

A quick note here on the Upgrade.  I upgraded one of my combination TFS2010/VS2010 virtual machines right in the Summit (figured I could get some help that way if anything popped up ).  My only surprise here was I needed to fully uninstall TFS before continuing.  This is one of the reasons you always need to have a solid machine and DB backup before attempting this.  I would have figured the upgrade wizard could have handled this, and a roll-back if it failed, but its just something to keep in mind.  If you are working on a scaled out TFS installation, you will need to touch each server.  I’d never recommend running out and upgrading a production TFS instance on a beta release but it is encouraging that Microsoft will be supporting that upgrade path right through to RTM release though.    I’ll cover more details of the upgrade process in another post.

Deeper into Agile

One encouraging theme I picked up on while at Microsoft was an definite embracing of Agile and Scrum specifically.  Anyone who has used TFS for any length of time knows you can configure it for almost any process, however who wants to spend the time doing this for each team you work with.  If you are one of the many organizations jumping on the Agile/Scrum bandwagon (if you aren’t you should ask why) you’ll be very happy with this release.  The Visual Studio team has put out upgraded Scrum, Agile, and CMMI Process Templates (final names not decided, but in beta its Microsoft Visual Studio Scrum 2.0 – Preview 3, for the new Scrum one and MSF for Agile Software Development 6.0 – Preview 3).  If you are starting out with a new Team Project you’ll get to dive right into the new stuff, but as in the last release, if you are working with a 2010 project you’ll need to do some import / export work in the Process Template Editor.  The good news is though you can continue with your existing template until you are ready. I’ll cover the template upgrade process in a later post.

Sprints, Backlog Management, Burndowns, Task Boards and Teams

These sets of features should get you excited if you run software development projects.  Sure we had some of these in TFS2010, but you had to work with a combination of Work Item configuration and some spreadsheets (Iteration Backlog, Product Planning) that were shipped originally with the old Agile template and had some serious bugs in them. 

Now all of this functionality is in the core product and fully accessible from the new Team Web Access web site and Visual Studio, with drag and drop support.  What this means is if you are starting out a new Team and Team Project this wont take you hours of work like it used to.  I’ll add some screen shots of these here shortly.  If you were already using the Agile or Scrum template and customized your User Story work item you may have some adjustments to make with the new template.  Same situation if you went wild with States.  The new Template really only supports 3 of them, you’ll  need to map to these.

The Task Board is a brand new item.  If anyone has looked at VersionOne’s task board, then this one will look real familiar.  Basically it is an electronic Story Board or Kanban board for instant status on where your User Stories and supporting Tasks are at.

Also new are the support of product teams.  This allows the proper status of the Tasks as they may relate to multiple product teams.  Again this is something we can configure right in Team Web Access.

Storyboarding

Another new tool on the horizon is the Storyboarding Power Point plug in.  This item warrants its own post, but in summary it will allow an analyst (i.e. a non-programmer) to put together an animated collection of proposed product screens quickly to avoid the dreaded “that’s not what I wanted” statement.

I’ll be adding to this post as I get more screen shots and the rest of my notes together from the MVP summit.

It would be great if every self-organizing team just jumped right in and did just that, but some do need a little help.  Most new groups will traverse through the standard storming – forming – norming stages, and its mainly during the first two you’ll need to help the most.  The biggest challenge for any of us who have lead traditional teams face in facilitating a self-organizing team learning how to facilitate without dropping into traditional management behaviors.

My first realization to this came one morning at a Daily Scrum when listening to the team members report their status to one another.   It was obvious to everyone in the room that there was an extreme imbalance in the workload and a few members User Stories were falling behind.  They were struggling.  At the end of the Scrum I expected one or more of them to offer assistance to the struggling members.  I was wrong. I don’t know why, but I expected these formally very independent people to suddenly step up and help one another out simply because the rules and principles of Scrum had been laid out for them.  The people hadn't changed because the process did. 

Coming to the rapid conclusion that they just didn’t know how to start helping one another, and fighting the urge to drop into delegating PM mode, I stayed in the facilitating Scrum Master role, bringing up the Burn Down and Capacity charts instead and asked questions.  Very pointed questions on what they thought the numbers meant

Leading the team to correct realization on their own rather than telling them what to do, helped them take the first leap.  It seems like a simple step, but for this group it was the turning point for coming to grips with a key responsibility of a self-organizing team. 

So what specifically can you do to help your Agile team to the “right” conclusions? Here are a few tips I’ve put together from my experiences:

• Highlight issues by bringing them up for discussion.  Encourage team members to vocalize the solution on their own rather than you pointing it out.
• Get impediments out of the way.  Make sure you aren't one of them.  Facilitate communications but avoid being a go-between if at all possible.
• You are not the Admin, do not become one.  Insist that all artifacts be created by the Team.  It encourages ownership and responsibility.
• When everything is right, it will seem like you do nothing at all.  Once the Team gets some experience and success behind them you should do very little other than truly facilitating .

So we are in the final go/no-go hour for a product release, and its not looking good.  My team had been charged with testing the product for last 3 day.  The development team was busy playing wack-a-mole with several P1 and P2 bugs that continued to regress.  Our QA team had no involvement at the beginning of this cycle, nor visibility to any hard requirements (I know, not a good start).  A particularly nasty P1 that appears to be in the framework of the product, is on its 4th try through the regression testing cycle.  This is one that the developer was sure he had it “this” time.  My confidence of course was not there, and I recommended this release be pulled.

The client of course was not happy and called an emergency meeting to get a handle on what was happening.  We were now going over the exact contents of what was supposed to be in this latest release, feature by feature.  Seeing the impending revelation creeping upon him the developer finally revealed there may be something “a little extra” in this code.  Something completely off the requirements list, project plan, and of course did not go through the fairly rigorous code review this client normally does.  We were unwitting victims of a classic Gold Plating gone wrong situation and nearly done in by the Midas Touch of unchecked development without matching requirements.  No malice of intent but the results were the same.

How this situation was resolved isn’t important, but how we could have prevented it is.  A simple, solid, Requirements Traceability Matrix combined with some training on early recognition of Gold Plating signs was on my list of recommendations.  I’ve often seen the costs of Gold Plating represented by actual extra work and schedule overruns.  This was the clearest case I’ve seen to date were it directly caused a quality issue of this magnitude.  A good lesson for us all.

While I’m sure we’d all rather avoid defects in our software all together, in a sufficiently complex application bugs (or regressions as we also call them) are as inevitable as death and taxes.  As an old mentor used to tell me, if you aren’t failing some of the time, you aren’t trying hard enough. The trick of course is catching them before the risk they present is fully realized, i.e. in front of the end user in a production environment.  Finding and remediating bugs falls under Project Quality Management in PMBOK (Project Management Body of Knowledge, Chapter 8).

So as long as you have them, you might as well get your moneys worth out of them.  Here’s how.  A “bug” in your software system represents a defect that needs to be remediated in some way, as effectively as you can, and without breaking anything else in the system.  So how do we achieve that ?  Well we need to find them early first with good testing in a well managed development cycle, but that's the subject of another future post.  Once we have located them we need to properly assess them.  At a minimum you want to know:

1. What the defect is and what it impacts in the system.  This begins with a thorough description of the problem observed.  We are looking for a well written observation here, more than just a “its broken” but shorter than your system specification.  A paragraph should be about right.
2. How do you reproduce it.  If the developer cant reproduce it, likely it will get closed as a “non reproducible” bug and will be a complete waste of time for everyone involved.  Be as exact as possible with clear steps and any particular data needed.
3. Screen Shot or Video.  Window 7 has the built in Snipping Tool, but there are a lot of them out there.  The idea is a visible representation of what you just described.  Full motion video is even better for complicated issues. Microsoft has Expression Encoder 4 available for free , but there are many out there.
4. Priority and Impact.   I’m a big fan of two level assessment of defects.  The first level, Priority should indicate how bad the problem on a numerical scale.  P1 meaning there is no way you can go forward without releasing it, down to P4, an inconvenience.  Impact should indicate what the financial or effort based impact of this error is (I-1 to I-4).  Will it take 5 weeks to fix or do we just need to comment out a line.  Often the original tester will not be able to assess the Impact, but this should be done by the person triaging the defects.  In a project management capacity this really represents Qualitative and Quantitative Risk Assessment.  More on this two level system concept in a future post.
5. How did we fix it.  This is a critical step.  After a resolution is developed and verified, you need to detail it right in the defect document.  While we don’t need the source code here, you should link or reference the change set that fixed it.  Also, always be on the lookout for a best practice or new design pattern that worked well in approaching this defect or one that didn’t.  This is about building up your knowledgebase.

One last parting thought on defects.  While there are hundreds of theories and best practices on Software Quality Assurance and reducing bugs (and certainly worthwhile).  I like to remind people of a famous quote from Thomas Edison on the thousands of failed attempts to create the light bulb: “I have not failed. I've just found 10,000 ways that won't work.”  As long as we keep that in mind and learn from the mistakes we make during the creation process, we can indeed extract value from them rather than just writing them off as just being a costly byproduct.

I’ve gotten a lot of questions from people lately on what a project charter is, and what elements they should include in one to create a good one.  Created under the Initiating Process Group under PMBOK (Project Management Body of Knowledge), it is the one of the first steps performed once you have the initial concept for a project nailed down.  I’m going to cover the basics here of what it is, key features, and just as important, what it is NOT.

The “official” definition is a document that formally authorizes a project or phase of a project (for larger ones) and captures the initial requirements that satisfies the stakeholder expectations.  This can also be an iterative document that further defines or validates the decisions made in previous phases.  Items that are used to build the charter include:

• Statement of work
• The Business Case
• Enterprise Environmental Factors  (corporate culture, government regulations, infrastructure, stakeholder risk tolerances, etc.)
• Organizational Process Assets (standard processes, templates, historical info, financial data, etc.)
• The Contract (may not have one if you are an internal team)

The main thing you want to keep in mind while building the Project Charter is that it is not a replacement or extension of the contract.  You need to things in plain business speak as much as possible.  We will undoubtedly be pulling items from the contract, but it needs to readable and tell a fluent but brief story that clearly conveys the business value.  You will also want to cover any significant risks, and  the costs of course.  The goal we are aiming for is authorization to proceed with project as described.

One question I from internal project teams working within a larger company is what to do about a contract.  Most of the time it wont exist and getting one signed isn’t going to happen.  The PMBOK doesn’t really cover that situation except for the obvious, if it isn’t there you can’t use it.  I would suggest that you could refer to your groups charter (if you have a long standing and well written one) at this point and make specific references to it in your Project Charter.

Lastly you need to consider a signature section.  For projects with an external group I consider it a must.  For internal groups you need to let your company culture be your guide.  If your company requires signatures on PO’s and other internal agreements they you’ll want to make sure that you are gathering them on the Project Charter as well.  If not, a simple acknowledgement of receipt (i.e. email) by all authorizing parties may suffice.

This has to be one of the most heated debates I’ve ever seen play out in recent memory.  Recently someone asked this question on a LinkedIn PMP only discussion (later deleted by LinkedIn) group.   This is sort of one of those Red vs. Blue questions and  your ability and experience tends to shape your opinion in this area. 

In a perfectly executed large 250+ resource project following the PMBOK (Project Management Body of Knowledge) processes you should be able to rely solely on the science, process, and SME’s (Subject Matter Experts) while you concentrate on the business of Project Management.  Actually you’d be foolish to think your individual technical contribution would even put a dent in the plan in a truly large scale multi-year project.  Lately however, these ideal situations and projects are less the norm and more the exception as organizations are more likely to be concentrating on the smaller, rapid ROI projects in the portfolio.

More often than not some balance needs to be struck.  Either you can’t completely rely on your SME’s, your teams knowledge ends up light in an area you are strong in, or the project is just too small and fast moving for you not to be a little more “hands-on”.  In these cases as a PM your ability to jump in along side your team (as long as you aren’t losing sight of your primary role as PM) could only be an asset. 

Also if you are Crashing or Fast Tracking  (schedule compression techniques) a project, and requiring your team work into a holiday weekend, you’d better be prepared to put in some work product yourself or risk being compared to the Pointy Haired Boss ;-).

So do I think we’ve settled the debate here ?  Not by a long shot.  However if we can generate some lively and useful discussion (especially among our stakeholders) than it is worthy of engaging.