Geeks With Blogs
Chris Falter .NET Design and Best Practices

I am reading Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer, the group product planner for Microsoft's Visual Studio Team System.  I am finding the book very helpful and thought-provoking, so I want to share my thoughts as I work through the book.  This essay contains my thoughts on the first chapter.

The standard models of software project management--in particular, the "waterfall" methodology at the root of the Software Development Lifecycle (SDLC)--are based on the management approaches of other engineering disciplines, such as civil engineering.  Consider the project management forces in play when you are building a bridge:

  • Well-Understood Design - You can build a new bridge that is virtually identical with an existing bridge.  The design elements of a bridge, the milestones the project will cross, and the features that must be included (move a certain volume of traffic safely) contain no surprises.
  • Low Variance in Estimates - Hundreds of similar bridges have been built previously, so it is not difficult to estimate cost and effort with great accuracy.
  • Little Ability to Provide Incremental Value - A half-finished bridge is of no use to anyone!

Guckenheimer refers to SDLC methodology as a "work-down" approach.  After you have completed your design, you draw up the task list, estimate the effort, and draft a work plan.  Managing the effort (especially the critical path) is based on this up-front work plan--hence the use of the term "work-down."

The problem with the work-down approach is that most software projects face quite different forces than the typical bridge building project:

  • Design issues are not often solved prior to building the system.  The new system is not identical to any other system--at least any system whose project plan and resource expenditures are known.  If an almost identical system were available, the customer would probably buy it off the shelf.
  • System requirements are incomplete, at best.  As users start to interact with the system and discover its capabilities, they will generate new ideas for features.  Thus the development team will face a demand for shifting requirements.  Of course, if the requirements change, you can throw the original estimation of cost and effort out the window.  On the other hand, if the project team resists shifting requirements due to its up-front investment in an extensive design phase and work estimation (you have heard of "scope creep," right?), the team is at risk of delivering a system with lots of features that offer little value to the customer.
  • The up-front estimation of time and effort may be very imprecise due to poorly understood design challenges and customer requirements.

The Agile development movement is a response to these difficulties in the traditional work-down approach.  The Agile approach is a "value-up" approach; it seeks to provide increasing value, incrementally, as a system is being built.  Essentially, an agile approach targets (in collaboration with the customer) a specific set of valued features in a project iteration.  This iteration should not have a long duration; in the Scrum methodology, for example, the team's iteration is a one-month "sprint."  This short duration minimizes the risks involved with a traditional software project, since the customer is (presumably) obtaining the highest value features first, and the design/coding tasks being estimated are an easier-to-understand portion of an ever-evolving system.

Guckenheimer provides a table of differences between work-down and value-up approaches that I summarize here:

Work-Down vs. Value-Up Methodologies

Work-Down (Traditional) Approach

Value-Up (Agile) Approach
Planning and Change Management Invest heavily in up-front planning to get it right, then monitor the project against the plan.  Be vigilant to guard against change. Change is inevitable, so embrace it.  Do just enough planning to understand risks and manage the next project iteration.
Progress Measurement Task completion Customer-approved deliverables.  Be skeptical of interim mileposts that do not deliver value to the customer.
Definition of Quality Conformance to requirements.  To reduce risk, invest heavily in getting the right requirements up-front. Value to the customer.  Since the customer may not understand what value a system can deliver before it is built, deliver incrementally and do not seek comprehensive requirements up-front.
Intermediate Work Products Models, requirements documents, etc., help decompose the effort into tasks that can be estimated.  Therefore their completion provides useful milestones in measuring project progress. You want just enough models and documents to maximize the flow of work towards completing deliverables that a customer values.  Intermediate work products have no other value and are not counted as deliverables.
Evaluation of Project Team Compare individuals' work output against the project plan.  Individuals that are struggling (like Wally in the Dilbert cartoons) are motivated to obfuscate and shift blame. Team members are motivated when the value of their work is measured by their team's deliverables.  Transparency (all team members can see the overall team's performance) is highly valued.

Visual Studio Team System (VSTS) facilitates Agile project management by providing a work item list that is visible to all team members.  The status of any item is tracked by the status of the latest tests (such as FIT scenarios) linked to requirements, and by the system build version(s) against which a test suite is run.  Often project plans are hard to manage because updates and tracking (like source code check-ins) are manual operations; VSTS eases the burden by providing automated updates to work items via check-in changesets and automated build verification tests (BVTs).

VSTS work item tracking can also answer questions about quality concerns and project run rates.  For example:

Project Management Question VSTS Feature That Provides an Answer
Are there any components that are poorly designed?  Check the bug count for the various assemblies. 
Are there any components that are inadequately tested? Check the code churn metric and the code coverage percentage in the automated tests
Can we deliver the projected functionality on time? Don't rely on code check-in metrics only; instead, make sure that the bug backlog for desired features is decreasing.  If the open bug count is not decreasing over time (or worse, is increasing), you're likely not going to deliver on plan, even if the team believes the project is 95% finished.

Our organization has not been fully aware of how VSTS can facilitate agile software development; maybe it's time to start finding out.

Posted on Wednesday, February 13, 2008 3:22 PM Agile Methodologies | Back to top

Comments on this post: Agile Software Development: A "Value-Up" Approach

# re: Agile Software Development: A "Value-Up" Approach
Requesting Gravatar...
Comment entered at 11:16 PM EST.
Left by Chris on Jul 02, 2008 3:15 PM

# re: Agile Software Development: A "Value-Up" Approach
Requesting Gravatar...
Comment entered at 11:17 PM on 7/2/2008
Left by Chris on Jul 02, 2008 3:16 PM

Your comment:
 (will show your gravatar)

Copyright © Chris Falter | Powered by: