I've been taking a closer look at Team System and what this means for
day-to-day team operations. More specifically, I'm interested in
how project tasks are managed.
I
originally posted the point that Team System is too expensive and is just another Rational competitor. I now believe those two conclusions are wrong. After looking at the
integration with MS Project, I am impressed. To me, this alone is worth the
price.
MS Project is the wrong tool for running a project. To my
earlier post,
MS Project is great for developing an understanding of the scope and
also communicating intent. Trying to drive developers work flow
using MS Project turns into a full time job - usually consuming the
time of the project manager. And the project manager is the last person
on the team who should be focusing on such trivial issues (aside from
the developers that is). Team System is capable of taking an MS
Project plan and driving a set of discrete tasks to the team. If
modifications need to be made, the tasks can be pulled back into MS
Project, modified and then put back in place.
On top of that, Team System integration of tools such as MSBuild, FXCop
and Unit Testing all play to the overall theme of continuous
integration and constant monitoring of process health. To me this
combination is far more valuable in a development environment than
Rational and it's priced less. I personally don't believe
Rational is sold on the same basis as Team System, but that's another
story altogether.
My next thing to look at is how much pull-scheduling is enabled in Team System.
I've been reading
David Anderson's Agile Management site
with interest in the Lean leanings of MSF. This is great stuff as
he focuses on Lean and TOC. I especially liked his timeline where
he noted the epiphany that "specs are inventory". In production
systems, inventory (stock or WIP) have significant costs associated
with them and never age gracefully. This is a great analogy for specs
that are written too soon. It's nice to see that David's
role in Team System is becoming visible in the end product. I'm
sure there are others with the same focus, but his points are quite
solid.
To David's site and talk around maturity models, I have to say that I'm
still leary about what an "Agile Maturity Model" is going to
entail. I simply don't trust them. When you inject
standardized process requirements into creative projects, you
inevitably fall into the trap of completing tasks for the sake of the
model instead of the project. Standardized process also injects
false start/stop points in the project timeline that grossly hinders
throughput. Fortunately, both of these points fly in the face of
Lean methods and hopefully will get weeded out in the process. I
also hope that the mathematical measurements of process health are
carefully weeded out as well - using things like earned value and SPI
on anything but the critical path is just plain wrong and promotes bad
behavior.