Keep Your Methodologies Flexible
Software methodologies have their place and can be useful in the development process, but they need to be flexible to provide their maximum benefit.
Keep Your Methodologies Flexible
by Doug Thews
Posted May 21, 2004
|
Doug Thews |
Software methodologies have their place, and there are a lot of good ones to choose from, whether you prefer agile software development, extreme programming, or the old waterfall method. However, it is a mistake to become too tied to a particular software methodology for all circumstances and all customers.
An overly rigid and inflexible software methodology is worse than having no software methodology at all. Forcing your software teams to follow any methodology at all times can stifle creativity among your developers and worse, make your customers feel like the project team hides behind your set of rules and regulations when things go wrong. Customers can feel that the methodology is a giant club used to beat them over the head.
One of the worst mistakes a company can make is to attempt to implement a software methodology to the exact specification laid out by one or more of its proponents. For example, a book on extreme programming might assert you should get rid of offices and put the entire team in an open area. Some people will read this, then do exactly that. Never mind that the perk of an individual office can be one of the most significant productivity enhancers for some employees. The methodology says we do it this way, the reasoning goes, so do it this way we will. It's as if individual thought and creativity have been sucked dry. The qualities that allow a development team to build a great product are discarded in favor of a drone-like mentality.
The worst thing you can do as a project manager is to plop down a new manual on software development methodology and expect a group of intelligent and opinionated software developers to follow it exactly as specified. Instead, you need to let developers build their own methodology. You can't implement the right methodology until you work with a company and the customers that you serve. Reading about the successes of others in books and attending the Project Management Institute can take you only so far. Yes, such resources can be useful, but you should use them as a guideline of what's possible. You need to use common sense and implement the best practices that fit your company. Use the creativity and innovation that your team possesses to build the right methodology for you.
An inappropriate methodology can become an inflexible barrier to delivering your software. For example, assume you have a customer that needs a quick and dirty spreadsheet written over the weekend. Barring a compelling reason, you shouldn't tell your customer that he or she can't have the project because it lacks a set of specifications, a schedule, and a review of a prioritization committee. Big projects and small projects require different kinds of management—and different kinds of methodologies. A 16-hour project doesn't require a project schedule, so it's a waste of time to make your team build one. Don't make the methodology a stick that beats business away from your customer.
Your methodology must be adaptable to the types of projects you can expect to work on. There is going to be a small set of qualities that cannot be eliminated in a project, but the other deliverables can almost always be negotiated, as long as the customer agrees to the consequences. Yes, a customer might end up trying to turn that simple spreadsheet app into some enterprise application in the future. However, you can always ask the customer to agree to throw away a quick and dirty solution in favor of a brand-new project if the customer wants enhancements after the initial release. You should not use the methodology to force the customer into a set of rules and regulations that aren't necessary to deliver a quality product that fits the customer's needs.
We as developers need to tailor software development methodologies to each company and its employees. What can and cannot be negotiated depends on the company. It's important to build in a leeway so you can run various projects differently. It is crucial that you avoid treating your software development methodology as the Ark of the Covenant—a mysterious pillar of information to be followed blindly without question.
About the Author
Doug Thews is the director of software development for D&D Consulting Services in Dallas. Doug has more than 19 years of software-development experience in C/C++, VB/ASP, and VB.NET/C#. Reach him at [email protected].