A new beta of MSF
for Agile is available from Microsoft.
I read through it (more reading that I normally like to do about
process-oriented stuff), and it’s better than classic MSF.
Classic MSF was very waterfall even though it called the
waterfall a cycle. There were very rigid
phases of envisioning, planning, build, stabilize, deploy, and maintain. The new MSF does a lot to emphasize Agile
concepts that keep us more focused on the software than the process, but it
keeps a death grip on all the documents that classic MSF had.
Documents
Some documents have been renamed and shuffled around, but
here are _some_ of the documents required by the MSF Agile process:
- Vision
statement
- Persona
- Scenario
List
- Quality
of Service Requirement List
- Project
Checklist
- Threat
Model
- Scenario
Description
- Iteration
Plan
- Storyboard
- Application
Diagram
- System
Diagram
- Test
Approach
- Release
Plan
I have no doubt that there are full-time folks at Microsoft
who maintain these documents all the time, but the average software company isn’t
the mammoth that Microsoft is. Most of
the points of all these documents can be summed up by some bullet points on a
whiteboard. My team uses a wiki to keep
current information since we have stakeholders in another city, so anything
that concerns them is jotted on the wiki so anyone can view or change it. Most stuff goes on a whiteboard until it’s no
longer useful.
Documents are only useful for a time, so I believe there is
too much document overhead still in the MSF process.
Builds
MSF for Agile describes a daily build and an accepted
build. There isn’t mention of continuous
integration, and it allows many checks before a daily integration build is
done. I believe that more feedback is
desirable. Even with dependencies from
other teams, you always have a good build of those, so a build on every
check-in would give more instant feedback.
This point also stresses the need for fast builds. If your build takes hours to complete, you
have no choice but to run it daily. I
build measured in minutes (10 or less) will be run very often and build
confidence that the software is still working.
Work Items
The MSF for Agile process uses Visual Studio team system
terms, naturally. They have different
levels of work items:
- Scenario
Overview
- Quality
of Service Requirement Overview
- Task
Overview
- Bug
Overview
- Risk
Overview
All work items must be tracked permanently according to the
process. The one that jumps out as
overkill is the task work item. Tasks
are very small, and merely recording them in a tool might lengthen the duration
of the task 20% for small ones. My team
tracks at the story level and tasks out on a whiteboard when necessary. If there is a very large story with large
task within, the product manager might record the large tasks (that might need
to be called separate stories anyway), but we as developers concentrate on
creating working software.
Conclusion
MSF for Agile misses one major point:
Software teams should be self-organizing.
Each software team is different and has different
goals. The process should be customized
for each team. MSF for Agile, even if
used, can be used out of the box. I
believe the process should stress that inappropriate items be omitted. MSF for Agile still seems pretty heavy for
me, and there is a lot of tracking that doesn’t directly validate that the
software works as intended. Tracking
every work item and having every document doesn’t matter if the customer isn’t
happy. The key metric should be customer
acceptance at every level, not just the end of the release. Automated testing wasn’t stressed either, and
that is a key way to get build feedback quickly and ensure that something a
customer liked yesterday isn’t broken today by an unrelated change.
Overall, it appears that MSF for Agile is trying to embrace
real Agile, but it won’t let go of waterfall.
Right now, it’s sitting on the fence looking at both sides.