Iterative Application Development
I understand the Agile methodologies for rapid application development, and I also can appreciate how customers get better results when companies apply this approach, however there is one thing missing from many companies' implementation of Agile processes. That thing is to reform the business side of the equation so that developers have the ability to build appropriate systems to support the current as well as future business needs.
Since the rational development methodologies have come onto the scene, many companies have rushed to adopt many if not all of them. Rational in and of itself can save companies lots of money in wasted overhead and overcomplication of projects and project specifications. This is a good thing. The issues arise when the specifications are not properly drawn up, and the project is not given an appropriate timeline. Most of the time developers are as much to blame as the business people in that they are giving timelines that are way below what they should be. Another problem is that business people are so used to over-inflated estimates by engineers, they attempt to squeeze the engineer to give them the “real” time estimate. The engineer, fearing for their job gives the project manager an unrealistic estimate based on how long it will take for them to physically type up the code. The project manager goes away happy that theye can deliver the project early to the customer, while the engineer goes away feeling bitter and looking at extremely long nights. If the engineer is working on several projects, it is easy to see how that engineer can quickly become swamped. Once that happens, they will be writing spaghetti code, and cowboy coding to catch up. They will not consider possible enhancements, portablilty, and they may not consider incompatabilities that will arise when they attempt to connect the project to another project.
Those issues often lead to overstaffing of programmers and an ever-increasing mountain of inefficiencies. Inefficiencies that agile development is supposed to abolish. There are a few ways to help prevent this, while still using agile development.
Project managers should think about the future. If they were to consider synergies with other project managers' projects, or the company's priorities, they would be able to discuss this with their engineers, and build in time to ensure portability, compatibility, and scalability.
Directors, VP level executives, and the sales staff could stand to learn a little about the actual programming. Most developers would flame me for this, but if the “C” level staff were to attend some conventions concerning the technologies they are using, they could listen to what the project managers were saying and make more informed decisions about deliverables to their customers.
Project managers, architects, and developers should stay abreast of new frameworks, methodologies, and tools for their technologies of choice. These may help them meet aggressive deadlines that would have been impossible before. Training and education need to be budgeted for and required.
Most companies say that they want to innovate and break new ground in their industries, but most of this innovation will come from the engineers. If they are inundated with trying to read spaghetti, or refactor awful code that was written during 24 hour coding marathons, there will be no time for innovation or learning. These problems can cause a software house to crash under its own weight if left unchecked. Also, a little planning up front for the engineers can be well worth its weight in gold. Of course over analysis and trying to stick to every standard will cause more problems than it will solve. It is up to the project managers to keep this planning grounded and come up with solutions to the business needs that are forward thinking and will enable growth.