Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

June 28, 2002

Popularity Contest

Agile processes, although popular, don't address the needs of enterprise-level projects

by Michael J. Hudson

Continued from Page 1

A software engineering project should resemble a good civil engineering project: Building a bridge involves tried-and-true processes that help formalize design and documentation. Again, this documentation and design facilitates the necessary and vital communication needed among all team members — no matter what role they play in the process. In terms of labor, you still need skilled people, yet every construction worker doesn't also need to be an architect. And the process is extensible to hundreds of people, not just 10 or fewer. Bridge building is an enterprise-level endeavor. And like any software enterprise endeavor involving strategic business applications, you need forethought and analysis before you even begin to build a stable, nonwobbling structure. Agile processes might be good for a small sidewalk bridge over a road, but not a five-mile metal structure over water.

Problems with Nonagile Processes

Agile processes do have their merits. They are probably one of the first processes to pay a lot of attention to testing. They recommend testing that's both repeatable and sufficiently exercises all parts and levels of a system. Other processes may have similar testing standards, but not as heavily emphasized or as central to the process itself. Agile processes also utilize iterative development and customer feedback. These are definitely very good best practices, but again they also exist in most good nonagile processes, although possibly not as fervently embraced.

For agile developers, the biggest trouble with many nonagile processes is that they become very heavy, very fast. Workflows grow really large and require a lot of development and tracking. Because a lot of this takes time and effort to successfully execute, many projects tend to shortcut the steps, design, and documentation described in the process — especially when deadlines get tight. Project chaos ensues. When the process isn't followed, deadlines may still not be met, but even worse, no documentation or design analysis exists to show what happened. Although occasionally something might get produced and declared ready, it never holds up for long. When it's time to maintain or expand system functionality, existing documentation and design only describes the project status up to the point of process breakdown. All of a sudden your strategic business applications have lost all their strategy.

Thus, the problems with nonagile processes are they lack the ability to accurately coordinate all aspects of the process and strictly enforce the process itself. Time may be a factor, but more effectively coordinating the process would reduce the amount of time needed to execute it. In addition, in any project, you always need to be smart about only taking on the amount of work that can actually be done in the scheduled amount of time. On a software project, you always have to be open to moving some features to future releases. Also, most nonagile processes are very customizable. Many companies falsely conclude that they must implement everything specified in a process when most processes are supposed to be modified and cut down to meet the project's specific goals and needs.

Rate This Article

Comments:

Optional e-mail address:

In any case, coordination and enforcement are still the primary concerns, which means you'll have to devote at least two or three well versed, highly skilled developers to focus completely on the process itself. (However, this approach, unlike agile processes, doesn't mean every developer is at that same high skill level). The real solution to this problem, and possibly the more successful approach, is some kind of software tool that actually does the coordinating and enforcing for you. (See the sidebar, "Tools for Agile Processes.")

In the end, the more formal processes that are currently used in businesses are still necessary in corporate development circles. The only thing lacking is general coordination and enforcement of the process itself. The goal of software engineering in the future should be to be as successful and as repeatable as any other engineering science. Agile processes are a step in the wrong direction. Companies need a mechanism, an automated system of process control, which guarantees repeatability from one software project to the next. In some ways, pieces of that mechanism are currently available. However, the full picture of what can and should be done doesn't exist yet. I'm hoping that software tool vendors hear this cry and help push software development into a more stable future where the chances of a project's success greatly outweigh what is now all too familiar, a project's chance of failure.

Michael J. Hudson [mhudson@blueprinttech.com] is a framework engineer for Blueprint Technologies, a software architecture firm based in McLean, Va. His current work includes developing enterprise architectural solutions for clients such as NASA.

TOOLS FOR AGILE PROCESSES

Currently, a number of vendors are trying to create tools to coordinate and enforce processes. Several tools already perform some process coordinating for teams, but none seem to complete the full picture.

What is eventually needed is an enterprise-level tool that's easily configurable for any particular formal process that you can create — one that you can set up for every project that you're running. Different software processes would be applied to different projects across the enterprise, based on that individual project's schedule and needs.

The tool would be capable of installing dashboardlike controls on every developer's desktop. These controls would then automatically update the task list of each developer, as well as the design documents under each developer's responsibility. Once a task, piece of code, or documentation item was completed, the tool would automatically move each developer to the next step in the process. Throughout the whole process, the tool would also link the developer to the appropriate developer tool needed for certain jobs, as well as providing help and mentoring for each part of the process. All the while, it would be coordinating the state and release of various pieces of project documentation.

However, more important, this ultimate software development tool would measure the proverbial return on investment. Because it would watch and control all the aspects of the process, it could give a full and accurate picture about the amount of time being spent, the amount and quality of the code being written, the level of design being enforced, as well almost any other kind of project statistic that a project manager would need to carry out to help modify the schedules and expectations for each project plan.