Earlier this year, I had the privilege of co-presenting on Agile Software development to a group of computer engineering students at the University of Cincinnati with our Agile Padawan, Katie Dwyer. Walking through campus was a refreshing experience. Seeing all the young faces reminded me of my college days, and the level of optimism, energy, and hint of youthful rebellion that often pervades the student population of many college campuses. Yes, even in a time of great economic uncertainty, the spark is still there!
During our presentation, I talked about some of the weaknesses of the Waterfall model and contrasted those weaknesses with the strengths of Agile software development models. At one point, I talked about how Waterfall development includes a predictive model of requirements gathering—where all requirements are gathered up front, interaction with the customer is limited, and change control processes are formalized to limit changes throughout the project lifecycle. In contrast, Agile methods allow daily communication with the customer and frequent changes with minimal constraints.
This is where it got interesting. One of the students asked me why teams don’t extend the requirements phase, to make sure they capture “all the requirements.” A valid question and a seemingly logical one, especially from a college student with limited work experience. The short answer I gave was “change,” but I’ll explain that in more detail later.
What surprises me is that working professionals, whom I assume should know better, often propose such deceptively simple solutions. For example, conventional wisdom used to dictate that if a software development project is running behind, you put more people on it to get it back on track. However, in his classic 1975 book, The Mythical Man-Month, Fred Brooks made the observation that adding people to a late project actually makes it later. Yet, I still see this practice happen today and it serves as a reminder that I often need to better understand my audience and check my assumptions at the door.
I’ll expand on why it is often rare, if not impossible, to simply extend the requirements phase to capture all the requirements. Frankly, change is inevitable, and the four forces I see creating change for software systems the most include the following (in no particular order):
- Business processes change. Making processes more efficient is probably the most common business process change I see. For example, when a process goes from four steps to three, it often requires a change to software.
- Market forces. The emergence of new opportunities to meet a demand and/or become more competitive drive these changes. Many times, changes resulting from market forces necessitate a change sooner rather than later and the change must be made within the context of the current project.
- Compliance. Whether internal or external, compliance brings about change in two forms. One form includes traceability and persistence of artifacts in the system. The other is compliance to process, which is driven by a compliance mandate. Often compliance changes add “waste” or non-value added (NVA) work to a process, but are nevertheless necessary.
- Other unknowns. Here I lump together everything from, “the technology does not exist” to “I’ve changed my mind” and everything in between.
It is highly unlikely, if not impossible, to predict the above types of change over the course of a typical software development project. Which brings me back to the engineering student and his next (and last) question, “If this is true, then why not tell the customer no when they want to make a change?”
I can think of very few reasons why anyone would tell their customer “no”. Chief among them is when ethics are brought into question. Software development organizations, both internal and external, that embrace change instead of preventing change, delight their customers by giving them what they need, when they need it. Furthermore, organizations who are able to delight their customers in this way, stand to reap the financial rewards that come with it.
Agree or disagree? I’d like to know your thoughts.
Recent Comments