(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.
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 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.
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.
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.
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).
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.
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:
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.
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….
Microsoft Regional Director, MVP Microsoft ALM, and
Executive VP of Agile Project Management at Telerik
Joel Semeniuk is a Microsoft Regional Director and MVP Microsoft ALM. You can follow him on twitter @JoelSemeniuk.