With the Microsoft announcement of Visual Studio Team System at Tech·Ed, a dream of mine is coming true. You see, I’m sort of an odd duck here at Microsoft. Although I’ve been in the
As a tester, I’ve always understood the theoretical value of advanced developer practices, like unit testing, code coverage, static analysis, memory and performance profiling. At the same time, I never understood how anyone had the patience to learn the obscure tools that you needed to follow the right practices.
As a project manager, I was always miffed that the only decent data we could get was about bugs. Driving a project from bug data alone is like driving a car with your eyes closed, but turning the wheel every time you hit something. You really want to see the right indicators that you are on course, not just feel the bumps when you stray off it. Here too, I always understood the value of metrics like code coverage and project velocity, but I never understood how anyone could realistically collect all that stuff.
As an analyst, I fell in love with modeling. I think visually, and I found graphical models compelling ways to document and communicate. But the models always got out of date as soon as it came time to implement anything. And the models just didn’t handle the key concerns of developers, testers and operations.
And in all these cases, I was miffed by how hard it was to connect the dots for the whole team. I loved the idea in Scrum (one of the agile processes) of a “single product backlog”—one place where you could see all the work—but the tools people could actually use would fragment the work every which way. What do these requirements have to do with those tasks, and the model elements here, and the tests over there? And where’s the source code in that mix?
From a historical perspective, I think IT turned the corner when it stopped trying to automate manual processes and instead asked the question, “With automation, how can we re-engineer our core business processes?” That’s when IT started to deliver real business value.
They say the cobbler’s children go shoeless. That’s true for IT, too. While we’ve been busy automating other business processes, we’ve largely neglected our own. Virtually all tools targeted to IT professionals and teams seem to still be automating the old manual processes. Those processes were high overhead before automation and they’re high overhead still. How many times have you gone to a one-hour project meeting where the first ninety minutes were an argument about whose numbers were right?
Now, with Visual Studio Team System, we are seriously asking, “With automation, how can we re-engineer our core IT processes? How can we remove the overhead from following good process? How can we make all these different roles individually more productive while integrating them as a high-performance team?”
We don’t have all the answers yet, but we’re taking a huge leap forward. When I joined Microsoft from Rational Software a year ago, the Application Life-Cycle Tools market was experiencing another spasm of consolidation, as it had seven years earlier. Customers were seeing more re-labeling of the same old bottles. On the other hand, Microsoft did not join the acquisition fray. Instead, we talked to our customers about their issues and brainstormed about innovative solutions. I’ve had the privilege to meet with hundreds of customers and partners in the last year and ask how we can do it better. We’re starting to show what we’ve learned, but we certainly haven’t stopped asking.
Please join the conversation by signing up for the newsgroups and participating in blog discussions that you will find on our developer center in the “community” section. If you’re a casual reader, we’ll also distill some of the highlights in this column for you every couple weeks-. And if you didn’t make it to Tech·Ed, you’ll be able to see some of the highlights on this site.
I look forward to “meeting” you soon.
Group Product Planner
Visual Studio Team System