Agile Methodologies

Agile Software Development: A "Value-Up" Approach

Chris Falter — Wed, 13 Feb 2008 21:22:43 GMT

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.

Why You Should Consider Using FIT

Chris Falter — Tue, 05 Feb 2008 22:12:48 GMT

I was looking for ways to improve our development process when I stumbled across the Framework for Integrated Testing (FIT). The rest of this post is the body of an email I recently sent to my manager.

The goal of the Customer update is to migrate all their customizations to a new framework in a reliable and quick manner. The major risks I have been able to identify are as follows:

Developers won’t be able to identify all the behaviors that need to migrate.
- Requirements are scattered.
- Code is not organized optimally. Much business and workflow logic is scattered throughout the UI layer, in particular. Many customizations in domain logic are located in poor locations in the domain class hierarchy; the root domain object seems to have become a catch-all location for just about anything.
Manual regression testing will become a bottleneck. It is already a serious bottleneck for other projects.
Poor code organization will be perpetuated into the new source code base. As a result, the project will proceed more slowly (due to high bug rate and unnecessary complexity), and subsequent evolution of the code will be hampered as well.
Lack of an automated testing framework will impede any efforts to refactor code. Since this project by definition requires an extensive reworking of our source code, this risk is quite serious.

Note to readers: I'm sure many of you have faced these kinds of challenges on one or more projects. Read on to discover a framework that can help you can meet the challenges!

While unit testing would go a long way toward addressing the third and fourth risks, it would not help us address the first 2 risks. We can ask business analysts (BAs) to help developers identify migration requirements, but we don’t have a repository for storing these requirements. Even if we implement such a repository, a developer must still translate requirements (in whatever form they exist) into unit tests, which introduces the possibility of error. Finally, the unit tests are not visible to the BAs, so they cannot rely on them for regression testing.

The Framework for Integrated Testing (FIT) seems to address all four of these risks quite adeptly. Before I proceed, I should explain that FIT allows a non-developer to write requirements in tabular form. FIT provides 3 types of test fixtures that can be used in a table:

A ColumnFixture is useful for business rules, as it is used to declare a set of inputs and expected output(s). For example, you could use a column fixture to declare that a dwelling in a particular location built in 1996 should have a BCEGS of 99, but if it is built in 2004 it should have a BCEGS of 4. As the Customer systems are replete with custom rules (such as underwriter referral rules), the ColumnFixture should prove very helpful.
A RowFixture is ensures that data are being stored and retrieved correctly from a data repository. While I see no need to test the data layer’s reliability with respect to standard data such as dwelling address (it has proven quite reliable for other projects), the RowFixture could help us with data that are unique to Customer (such as subdivision).
An ActionFixture is used to simulate workflow requirements. For example, a tabular ActionFixture could state that when a user enters a dwelling limit of $10k and presses “Continue”, a certain error message should appear; when s/he enters a dwelling limit of 300k and presses “Continue”, the system advances to the Quote Summary page; and if s/he enters a dwelling limit of 1100k, the system advances to the Qualification Questions page (due to consent to rate rules).

If we use the WinFitRunnerLite tool, a BA can construct the test data tables in Excel, which may be more intuitive than writing them in Word and saving as HTML.

A developer must write a test fixture in order to translate the test data into an actual test. The test fixture will link to the domain, data, and controller/workflow libraries of the system under test, pass data from the test document’s tables to the appropriate methods, and evaluate the results against the BA-supplied expectations. If we follow this approach, it will be impossible for a developer to embed workflow logic, rules, or domain logic in the UI (a big win!).

One of the other advantages of FIT is that a BA can “own” the generation of requirements and tests, since they are maintained in a single location. A BA can easily design the test scenarios that the system must pass; I’ve seen complex requirements in Excel spreadsheets plenty of times, so I have no doubt about the ability of our BAs to generate FIT scenarios. On the other hand, how many BAs could write a unit test?

Using FIT can help answer many project management questions:

Developer: How have requirements for the system changed? Answer: check the FIT document.
Developer: What are the requirements I should work on? Answer: see which FIT tests have not yet passed.
BA: How close are we to completing the latest project milestone? Answer: run the FIT tests and see how many tests have not yet passed.
BA: Do the latest changes contain any regressions? Answer: run the FIT tests and see if any tests that used to pass have started to fail.

It is true that the FIT tests do not run against the actual UI. I see this is a positive, as it will prevent the project team from falling into the “Smart UI” trap. However, it also means that FIT, however useful I think it will be, is not a silver bullet; testers will still have to interact with the system’s UI.

Nevertheless, I think FIT will prove very helpful for this project, and for our shop in general. And since BAs have to write requirements and perform testing, and developers have to translate requirements into testable code anyway, using FIT should not be burdensome.