Sometimes looking back is the best way to see ahead. Such is the case when examining methods for software engineering. With this in mind, I’ll take a backward glance at the more traditional software engineering approaches in order to illuminate why agile methods of development are vastly more preferable.

Catch up with our software development series

This article is the third in a series on the challenges of implementing current software development methodologies.

The allure of an engineering approach to development
The manager of a software development team is a breed apart from other managers and engineers. Working to blend and balance the two disciplines of managing and engineering is a difficult challenge. As defined by the IEEE, software engineering is “the application of a systematic, disciplined, quantifiable approach to development, operation and maintenance of software; that is, the application of engineering to software.” This definition reveals exactly why managing types are drawn to the discipline of software engineering. Note the key terms:

  • Systematic: You can define a process that will control all aspects of development. You will have step 1 followed by step 2, and so on.
  • Disciplined: If you faithfully and consistently execute the process, you will get the results you want.
  • Quantifiable: Every requirement articulated and design proposed can be related to a means of implementation.

But this definition, while having great theoretical appeal, is lacking in practice when it comes to software development. The creative work involved in software development often goes beyond the original scope of requirements, making systematic, disciplined, and quantifiable techniques difficult, if not impossible, to implement. Nevertheless, for certain types of projects and teams, a traditional engineering approach embodying these types of rigid techniques really can work. But this doesn’t change the fact that methods that worked in the past (and thus feel comfortable) for traditional client/server applications don’t often work as well for distributed software services deployed on a variety of platforms and delivered via a browser. This is where agile engineering can make a major difference in your success rate with these types of projects.

Learn to let go and accept change
Traditionally, engineering has placed an emphasis on controlling the development process with an iron fist, managing the process from the top down. This style reveals the classic waterfall scenario, where requirements flow from the business unit to the programming staff with little interaction between the two. To keep a tenuous hold on the order that this traditional method demands, many managers will try restructuring this same method again and again to build the code, despite changes that have occurred during the process. This iterative version of the waterfall approach allows for a small amount of flexibility, but, in the end, the project will suffer due to a lack of adaptability.

Agile methods, by contrast, ignore the top-down, full-scope management that traditionally has shaped engineering management. Instead, agile methods work to create a learning team that determines designs based on small units of development scope. These designs are then passed from the programming team upward to other relevant teams. Admittedly, no one wants to give up control, but a strict engineering approach is, by design, biased toward seeing change as unwanted and disruptive. Agile methods see change as expected and are poised to act and turn unplanned events (and knowledge) into opportunities to make the product conform to the most current understanding of the business needs.

To help you visualize the differences between how I view these methods and their success rates, note in Figure A how much you could gain by letting go of the traditional, control-heavy method.

Figure A

Learn from the engineers
Engineering has been around much longer than software development, and there is much we can learn from its methods. Being agile means becoming a learning organization. For example, a classic book on the management of engineering from the 1960s (Manage or Be Managed by Don Fuller) notes that the most common sources of errors in an engineering setting include:

  • Carelessness
  • Indifference
  • Ignorance
  • Incompetence
  • Confusion
  • Pressure

Are your programmers afflicted by these same maladies that were prevalent in the 1960s? Surely you and your team experience the “pressure” source daily. Carelessness, indifference, and incompetence can be dealt with through more traditional management methods, but then what do we do about ignorance and confusion? Here are my suggestions for how you can learn from the past and become equipped for the future:

  • Take the best parts of being an engineer, where ignorance and confusion are rigorously attacked each day, and tailor your development methods to weed out these two maladies.
  • Forge your team into constant learners who see business requirements as puzzles to be solved by programming rather than as interference from technical illiterates.
  • Don’t create a separation between those who generate the requirements and those who meet them.
  • Tear down the cube walls and build a team composed of business expertise and technical smarts that work together to produce a product.
  • Engineer your process to make feedback between the requirements and the implementation a daily affair.

Coping with shifts in your management experience
While “touchy-feely” issues might not seem relevant to managing the writing of code, they will have an impact on your performance as a team leader. As you shift from a strict engineering approach to one with more agility, you will find a level of discomfort. If you plot the spectrum of shifts in your perceptions, you’ll see a result like that displayed in Figure B.

Figure B
The spectrum of perceptions of management experience

Note the last two lines above, which apply to you directly as a team leader. The discomfort is necessary if you want to benefit from the gains expressed by the other dimensions. You can’t control from the top down and expect those “below” you to perform at their maximum level of competency. At the root of any discomfort you may feel as a manager is the issue of control. This is why engineering is so appealing: It seeks to gain control over every process. But it does it from the top down. Software development needs control where it counts, that is, in the domain where requirements and design are understood at the level of detail where actions can be taken to make a difference. No matter how many work breakdown structures you create as a manager, the programmer in the cube often finds a better way to get to the desired goal than you can foresee looking at the big picture. Trust is hard, but it’s even harder to rebuild a product the second time when your initial plans result in unusable software.


What do you think?

Share your thoughts on agile development in the discussion forum, or e-mail us.