(This is a continuation of Behind the Scenes with the TeamPulse Team Part 1 and Part 2)

Wow.. lots to talk about… here is the 3rd post in the series describing some of the things we do on the TeamPulse team.

Sprint Reviews

At the end of each 2 week iteration the teams host a number of sprint reviews. In reality, there were two sprint reviews each sprint – one in Bulgaria and one in Winnipeg. The teams invited everyone they could to these meetings. It is really important for us to directly engage other product teams within Telerik as almost every team is a user of TeamPulse and their feedback is absolutely critical to our process. The team tried to have all reviews in person as Skype and GoToMeeting just didn’t have high enough bandwidth for this type of interaction – during sprint reviews you really need to take into account people’s facial expressions, body language, and level of engagement – and this can only be done in person.

Each team would invite as many people as they could to the meeting. In Bulgaria, team leaders and executive were invited. In Winnipeg, leaders from Imaginet were invited. During the review meeting the facilitator (usually Steve or Robert in Winnipeg and Yordan or Vesna in Bulgaria) would start by reviewing what they intended to do and what they actually accomplished during the sprint. Next, the team went on to review each story delivered in the sprint and have a discussion with all invited about what was delivered, what could be changed, what could be added and if the feature provided enough value.

All of the changes and feedback were captured as new stories and fed back into the product backlog to be prioritized with the whole and used in the next round of sprint planning.

Just as a side note, when Steve facilitates, he really likes to use Prezi - http://prezi.com/ - Prezi is an alternative to simply putting together a flat/boring PowerPoint presentation, allowing the presentation to be very fluid and engaging.

Sprint Retrospectives

Sprint retrospectives happen at the end of every sprint. Each of the teams gets together in person to look at what they’re doing from the following perspectives.

• What the team should keep doing
• What the team should be doing more of
• What the team should start doing
• What the team should stop doing
• What the team should be doing less of

These, of course, are turned directly into actions that the team will work on for the next iteration. The entire goal of retrospectives is to reduce waste and be more product and are an extremely important part of the process. After the retrospective, each team posted the result to our own internal product portal for the rest of the organization to see. We’re very transparent.

One thing that was stressed with all teams was that the retrospective wasn’t just about “reflection” it was about “action” – meaning, the results of the retrospective should always drive action in hopes to increase productivity and reduce waste.

How We Used Microsoft Team Foundation Server

TeamPulse doesn’t replace Microsoft Team Foundation Server on our team. TFS is still the core of all of our automated builds, automated testing, source control and code/work item tracking. In this section, I’ll dive into more details about how the TeamPulse team uses TFS.

TFS Work Items

Yes, we synchronize TeamPulse data with TFS work items. We do synchronize a new set every iteration – and keep the data synchronized over time. TeamPulse remains our master for many many good reasons. Why do we synchronize with TFS in the first place? Primarily because our Devs are already in Visual Studio and giving them the information they need within the tool they use is critical. Second, it’s important for us to associate checked in code with Work Items so that we maintain traceability between our code and the work that is driving it. Actually, this topic is really a core discussion around why we developed TeamPulse in the first place. Generally speaking, TeamPulse acts as our requirements and planning sandbox. We like to get stuff into TFS “just in time” – meaning, just before we begin implementation. We view TFS as being an engineering platform primarily – and that’s exactly how we use it. TeamPulse acts as our repository for “work in progress” – and gives us a very flexible environment for capturing and evolving our stories, bugs, etc. When we’re ready to move into implementation, we move only what is our focus into TFS (stories, bugs, issues, risks) where we can begin our implementation. Why do we need a planning sandbox for TFS? Well, first of all – TFS work items are pretty heavy for some of our needs. We really like how quickly we can stub out stories, prioritize work, plan iterations (embracing iteration dates and capacity), the best practice analyzer, the triage workflows, and even the ability to quickly delete items (something not easily done in TFS). We’re WAY more productive working with work items in TeamPulse than we are in TFS. Once the information is in TFS, we actually usually always go back to TeamPulse to update it (with the exception of the work item state that gets changed in TFS during checkin association in a lot of cases).

Builds and Test Sites

We have a pretty elaborate (yet simple compared to others I’ve seen) automated build/staging environment. Some of the builds are triggered via checkin. Some are triggered manually. It’s important that we have something to run at the end of our builds and that’s why the builds deploy the solution to test sites that we can hit immediately after the build, complete with sample data. Here is a rundown of our builds:

• Continuous integration build: Triggered by code checkins – ensures code builds and integrates with everything.  Runs unit tests – immediate feedback if you broke tests. Use the build monitor tray tool to be notified immediately of builds breakages

• Installer builds: Generates installers off of current code base for testing

• Review build: Builds and deploys “review” site

• Ready for test build: Builds and deploys the “ready for test” site

• Hosted Trial build: Builds and deploys test site for the hosted trial

• Early Access build: Builds and deploys early access site mentioned above

• Branch builds build: Prior to release we’ll branch and have builds set up for this branch

• QA builds build: Builds for running QA managed automated tests

• Code coverage build: Work in progress but will run nightly once we get it done

We have a number of staging sites we work with as well that are closely tied to our builds.

• “Early Access” site: On demand build/deploy that deploys a site with the latest code base
• “Ready For Test” site: Produced by an automated build/deploy triggered by developers once a story is reviewed and marked as ready for test.  This is the site that QA spends all of their time in We had issues sometimes where items would be marked ready for test but developers would forget to kick off a ready for test build so testers would waste time looking to test code that wasn’t there.  This was a good opportunity to reduce waste so we put in a process that after a story is reviewed we mark the review date in the TFS item.  The next ready for test build looks for these and moves these items to ready for test state.  This way the build pulls the items into that state and things are in sync. Note that all stories must be tested by a developer peer before it gets to QA.  This gives a chance to get another set of eyes on a feature as well as spread the knowledge around.
• “Review” site: Automated build/deploy triggered by developers once they want their story peer reviewed (see note above)
• Dog food: Production site where the latest done code can be used live

Source Control and Branching

We use TFS as our source control repository. We don’t, however, promote branching ;-) (oops.. I said that out loud!). Branching, on the TeamPulse team, is an exception, not a rule. Code that is checked into a branch is still NOT considered “done” until its merged/integrated/validated into the trunk – this means that we consider all branched code “work in progress” – and, if you know anything about what we preach – we don’t like work in progress… we like “done done”. With that said, we have done some branching on the following conditions:

1. We are working on a feature that is high risk that might not get done on time for the end of iteration or release so we would like the option to make a call and leave it out in case things go bad. An example of this would be the last minute performance fixes we did just before releasing
2. We're feature complete for the release and would like to start coding new features on the next release all the while needing to be able to fix bugs in what we're about to ship - so we create a release branch that won't get polluted with new dev.

This means we do not branch by feature. We do not branch by team. We do not branch by developer. We do not branch by release. We do not branch by sprint (that almost sounds like a Dr. Suez rhyme). We like our code together as much as possible. When we do branch, it’s important to the team to get it merged into the main trunk as quickly as possible.

The VSX Team – is not our team

You might have noticed in the screen shot showing our teams that VSX is listed as a Team. The VSX Team is the installer team – and they are a very important and very talented shared resource of Telerik. The VSX Team is not part of the core TeamPulse team, however, we do track the work that we request from them as high level stories (epics) – the VSX Team then tracks the details of this work in their own TeamPulse project (no there is no rollup and yes, we know this is not optimal – and we have some big plans on supporting cross project work tracking and rollup. I promise, this is a fairly important issue for us and since we’re our most demanding customers, we’re going to address this as soon as we can)

I’m really going to try to wrap this up on the next post I promise….

Joel Semeniuk

Microsoft Regional Director, MVP Microsoft ALM, and
Executive VP of Agile Project Management at Telerik

@JoelSemeniuk