One of the most common questions I get asked is “does the TeamPulse Team use TeamPulse?” My answer is always “Of Course!!!” – The TeamPulse team is the biggest, most passionate, and most demanding customer of the TeamPulse product! We wouldn’t have it any other way.
I thought I would take some time to detail some behind the scenes facts about the TeamPulse team; how we work, how we’re structured, and how we use TeamPulse.
Just like a lot of teams in the real world, the TeamPulse team is distributed across geographies and time zones. Our entire team (Sales, Marketing, Development & Test) is distributed across four geographic locations (Winnipeg, Boston, Sofia, and Cairo)
Our release had 7 iterations (Sprints) of 2 weeks each
The team worked very hard to be “done done” by the end of every sprint. This meant that every 2 weeks the team literally had a completely shippable product – including functionality, documentation and installer.
Note: All of the screenshots in this post are taken directly from our “dogfood” server – the instance of TeamPulse we use to manage our own project. Nothing has been modified or doctored in any way. More information about what I mean by “dogfood” later in this series (part 2).
As you may have guessed, every sprint started out with a Sprint planning session. In fact, we had two sessions only because we had two primary development teams (Bulgaria and Winnipeg). Each Sprint planning session lasted about 90minutes to 2hours. Prior to the sprint planning session the teams selected the areas of the application they were to work on during the sprint – with guidance and facilitation of the Product Owner. During the planning session each team would be aligned with the goals for the iteration, review the stories, conduct group estimation (using planning poker), decompose the stories into work (TeamPulse tasks), and produce the initial sprint plan. The team also worked to provide the initial set of acceptance criteria for each story – something they began to rely upon as a way of defining what “done” meant for the story. Of course, prior to, during, and after the sprint planning meeting there was a huge amount of discussion to find out what made sense for both teams… questions such as "Guys, what make the most sense" and "Hey, wouldn't it be better if the Bulgarian team does this" would be asked continually.
Here is an example of how the team decomposed stories into tasks – using the “Bugs by Severity” story assigned to iteration 6 of the release. Notice how all tasks are being captured.. from help text, to testing and documentation. By the end of the sprint we wanted to have this report “done done!!” When the team works on the work – there is very little hand off.. teams work together to get all of the tasks complete, regardless of their “role” on the project.
Each of our sprints had capacity – a maximum amount we would schedule into the sprint. Our capacity was measured in how many story points we can deliver in a 2 week period. The team use story points rather than “perfect days” during estimation – as story points are arbitrary and focus on sizing rather than time estimation, which would quickly erode into a “point” system anyway.
We used our own reports to help us understand what this capacity is to help us predict what we can deliver in future iterations.
Here is the exact report we use to help us predict our team capacity:
As you can see, the team got much more efficient during over the course of the release – the biggest reason was due to how the team ran its retrospectives which would gradually interject learning and efficiencies into the development process.
Likely the most important aspect of a team is how they work together on a day to day basis. Here are some of the details of the day to day activities of the team.
Days start out like every day on a Scrum team – with daily scrums. Due to the fact that we have a distributed team meant we actually had one scrum in Winnipeg (in the morning Winnipeg time) and one scrum in Bulgaria (in the morning Bulgaria time). Every day a member of each team was “elected” to participate in a scrum of scrums between the two teams to help synchronize. These would take place in the morning Winnipeg time and the end of the day Bulgarian time
Here is how the Winnipeg team chooses who gets to participate in the Scrum of Scrum:
That’s right.. those are nerf darts from a nerf dart gun. The person furthest away from the center “wins” – and gets to participate in the scrum of scrums. If you won the day before, you get a reshot – so, it’s still possible for them to win two days in a row.
The story board and task boards became very important aspects to the team – representing a real-time representation of the status of our work.
You’ll notice a few things. First, we do have some extra states for our stories. Of course, we tweaked the states as went along. In addition, these states map to TFS Work Item states we synchronize with. The second thing you may have notices is that we typically group our boards by “Team”. As I mentioned above, we have a few sub-teams that we track on TeamPulse, and we were the first to use the new Team features of our product to help manage our own work. Our teams are very simple and look like this:
Note: I’d also like to point out that basic team support was added to TeamPulse early in the release, and as soon as was – we released that version to our dogfood server so we can start using it right away! More about our dogfood server in part 2 of this blog series.
We also tracked our daily activity in burndown charts. These came in during retrospectives as well, as we can take a look at the pattern of the burn down to help us understand how our team worked. For example, here is a task burndown chart we used in Iteration 6 to track our progress. This particular burndown shows the team finishing slightly ahead of schedule – which was not uncommon for the TeamPulse team:
Notice we used “By Task Count” for the burndown mode… the reason for this is simple – we don’t track actual time spent at the task level. Usage of the task burndown chart was also something the team adapted to halfway through the release. Again, as soon as this report was created, it was released to our dogfood server and the team immediately started to use it.
The MyPerspective™ view is also heavily used by the TeamPulse team. Each team member relies on it to give them a view of their world – including work they are currently committed to, work coming up, and best practices that they may have broken. When I asked them about this screen’s usage.. almost everyone I talked to said they use this screen daily. Here is a real screenshot of one of the team member’s MyPerspective™
A few important things to note. First, we don’t overly pre-plan assignments– meaning, you won’t see much in our “work not started” section of the MyPerspective™. We try to “pull” in the work – or at least allocate the work to team members “just in time” as much as possible. In addition, you’ll also see that team members work hard at keeping their broken best practices at zero.
Real-Time Collaboration is a must for our distributed team. We really like collocated teams and value high bandwidth communication and each of our geographies have very well equipped team rooms – however, we really rely upon real-time collaboration tools to help connect our teams together. Tools such as Microsoft Skype and GoToMeeting are critical to how we collaborate daily. Of course, we still use email – most of us agree that we likely still use it too much – but sometimes it’s often necessary especially when teams are 7 time zones apart. Scrum of Scrums, planning sessions, and all important design discussions are always done in the highest bandwidth we can achieve. No exceptions.
Speaking of email, here is another example of how we incorporated features hot off the build machine into our processes – notification emails. Notification emails were a very common request from TeamPulse customers – the day they were applied the build that supported notifications to our dogfood server was the day we realized how handy these were. In fact, the Product Owner of TeamPulse was skeptical at first of the value of this feature, but after a few iterations of use and feature fine tuning, he turned around and realized that notification emails can be quite handy.
Every developer on the TeamPulse team sends a progress video as they implement the feature. We use Jing by TechSmith to capture the videos (http://www.techsmith.com/jing.html - it’s a free tool). What we really like about Jing is that it is quick to capture and more importantly, quick to publish – specifically to a secured location on Screencast.com (again, free). Right after publishing, Jing gives us a short URL that we can quickly paste in an email. These are SUPER addictive. We all get very excited when we see emails that have a subject line that starts with “Progress video” – in fact, I have a special rule in Outlook for these. Progress videos may contain an explanation of the feature and it often goes into demonstrating some of the code or designs behind the feature as well.
We love progress videos because they are SUPER easy to produce (compared to crafting a lengthy email no one will read), they are SUPER high bandwidth, and they take 5 or less minutes to produce. Consuming them is just as enjoyable, and the entire team has the ability to immediately send feedback on work in progress. At the end of every week, we accumulate all of the links to the progress videos and publish them to all of Telerik on our internal portal and newsgroups. When we stop seeing progress videos regularly, we know that something bad is going on ;-)
In part 2, I’ll talk about how we use the backlog, how we write user stories, our dog food servers, and our “pair programming” model.
Subscribe to be the first to get our expert-written articles and tutorials for developers!