Agile Project Management in Visual Studio ALM V.Next

When we first started designing Team Foundation Server, one of our mantras was “Your process, our process or no process”.  What we meant by this was that TFS can play an important role in helping you automate your development process.  Many teams already have a well establish process and aren’t particularly interested in changing it.  TFS can be configured to fit with your process – whatever it is.  Many teams don’t have a well established process and would like to adopt some “best practices” and then evolve them – TFS can do that to, and we provide 3 process templates today you can adopt (Agile, Scrum and CMMI).  And some teams are less structured and pretty skeptical of the “P-word”.  They just want some good tools to help them get their job done and TFS can help there too.

In parallel to the evolution of TFS, the world of software development process has matured a great deal.  There’s way more energy and debate around process now than there was 10 years ago – and there are some emerging and established “winners”.  It’s clear that the Agile family of development practices have become very well established now.  Some of the practices that were highly touted in the early days of Agile (like pair programming) have drifted into niche practices and some (like unit testing) have become table stakes that almost every high performing development team has adopted.

We did some work in 2005 (unit testing, for example), 2008 (continuous integration) and 2010 (Agile workbooks, Scrum template, etc) that enabled teams to use TFS to automate their Agile practices.  However, we resisted building very tuned experiences because we were hanging a bit too tightly to process independence (remember – Your process, our process or no process.

As we began our planning for V.Next, it was clear that Agile had become mainstream (I have survey data that says 35% of development teams practice "Agile”).  And new processes are in the offing – Lean continues to gain momentum.  And, in fact, I see lots of people trying to combine the best of Lean and Agile together.  With the growing adoption of a well defined set of processes/practices, we decided that it was time for TFS to invest more in experiences optimized for those practices.  We still hold on to Your process, our process or no process but now we will build tooling optimized for well established practices.

One of the areas we chose to focus on was Scrum based tooling.  I have survey data that says about 84% of teams that say they practice Agile, practice Scrum as part of that.  That makes Scrum the most adopted Agile practice.  Here’s a chart that shows the adoption of methodologies by Agile teams:

Ironically, at the same time we were discussing this, we were deciding to adopt Scrum for our own feature team level development.  We use more of a Microsoft practice for rolling that up through the organization.  This was serendipitous because it would provide us a great opportunity to dogfood the tools and ensure we were building something our customers would love.

Very early we decided to focus on a web based experience for our Agile project management tooling.  A browser based solution makes the experience widely available to everyone on the team.  At the same time, we felt projecting some of this directly into the Visual Studio and Eclipse development environments was also important.

We broke down the basic Scrum project management cycle into the 3 highest priority activities:

• Backlog management – collecting the list user stories (requirements) and prioritizing them.  The backlog is one of the central theories in Scrum.
• Sprint planning – choosing a set of user stories to implement in a sprint based on their estimated cost (story points) and the team’s capacity (velocity).
• Daily stand-up – reviewing the newly completed work, work in progress and newly started work along with any impediments.

We also considered a few other things (like retrospectives, etc) but, after discussing it with many customers and Scrum professionals, concluded that the 3 I listed above were the key areas where new tooling would help the most and that other things could work fine with tooling we already have.

For each of these experiences, we wanted to create a solution that was incredibly easy to use and low overhead – work the way I do and stay out of my way.  We also recognized that if we were going to rely on our web experience this deeply we were going to have some significant work to do.  We wanted to modernize the overall look and feel – we adopted the “Metro” style from Zune/Windows Phone.  We also needed to really work on performance.  Web access, in 2010, relied too heavily on server round trips for user interactions.  We wanted an experience that not only used Java Script to keep the vast majority of processing local, we wanted to make most places where server round trips are necessary (like saving a work item) asynchronous.

As we started to adopt Scrum ourselves and design our Scrum solution, it quickly became clear that we were going to need to introduce the concept of “Team”.  Each of our feature teams have their own backlogs, sprints, etc.  We needed a way to identify the teams, easily select them, define properties for them, report on them, etc.  As such, for V.Next, team has evolved into one of our central elements of our web UI.  You select what project and what team you are working on and then much of the data in the UI is filtered to show you exactly what is relevant for you.

Extracted From : http://blogs.msdn.com/b/bharry/archive/2011/06/14/agile-project-management-in-visual-studio-alm-v-next.aspx