Agile Meets The Recession

It's no secret to anyone about the state of the economy, and the issues organizations face in keeping their businesses stable, including cutting costs. This also leads to the "do more with less" syndrome that project managers are facing on their projects - assuming that they aren't being canceled wholesale along with other initiatives.

Lately, I have been hearing flack from clients and in my Intro to Agile course that I teach at the University of Wisconsin-Milwaukee about two agile methods, pair programming and refactoring with respect to cost and time.

Pair programming is germane to Extreme Programming (XP), but can be used in almost any situation or methodology as desired. The gist of the technique is that while one developer sits at the computer and codes, another developer is looking over his shoulder catching errors and brainstorming with the first developer as the code is being written. They switch roles after a time, and members of the project team pair up with other members after a few days or a week (roughly).

While I am not personally a fan of the practice, I have seen it used fairly successfully in the past on specific projects. The argument against it now, which has come through loud and clear in the past few months is simply this: "We cannot afford to pay two programmers to do the work of one." That pretty much sums it up - the budget is cut to the bone, and the project cannot pay for additional staff to adopt or continue the practice. Not having (or refusing to spend) the cash to support this technique makes all technical arguments in its favor moot.

Refactoring code is being scrutinized heavily as well, particularly if it's "do-over" code that optimizes the system, but provides no new functionality or capabilities for the business or end-users. The argument here is "We cannot afford to refactor working code to optimize it unless it can be shown that there are distinct and immediate advantages/benefits to the business in doing so." Can't say I blame the business and product owners here as well if there is only enough budget to take one pass (or maybe two) at development in each iteration.

There are a number of methods to mitigate such risks, and if you're told the team cannot pair program and/or to keep technical (not feature-related) refactoring to a minimum, you have some choices to make regarding the project.

The primary method to mitigate these risks is to do some design up front. Not Big Design Up Front (BDUF), where artifacts use lots of paper and diagrams to describe a system and take many months to produce (as well as having dubious value to the programming teams). Rather, we do enough design to enable single programmers to write code that requires minimal refactoring or tweaking down the road for purely technical reasons. The thought here is that the time spent on design pays for itself in two ways: reduced staffing cost; and the reduction of technical debt to a point that significant amounts of refactoring are not necessary.

The business may complain that time spent in useful (that is, useful to the development team) design inhibits getting started on development, and we're agile, and we need to get a system up and running quickly. However, they cannot have it both ways - we either spend some time and money on intelligent, useful design, or we spend them on refactoring and higher developer head count during development iterations. I think that some up-front design is a better investment of scarce time and funding than doubling programmer headcount and/or rewriting code to 'optimize' the system without much benefit to the business users.

This line of thought also doesn't address changing requirements, timeframes, and other project uncertainties that are faced every day by development teams and their sponsors. That is a topic for another day, but suffice it to say that as good as Agile methods are in addressing uncertainty through iterative development and small, focused teams, we don't get those benefits for free, and never did.

Comments

[Srishti Projects]

Agile means recession is intresting. I take in other way, Agile methodology came due to recession. People don't have money to spend on and they have to effectively use that

itprojectsforyou.com